SSH Troubleshooting Support Articles
SSH is the primary method available for managing DigitalOcean Droplets. Dealing with SSH errors or failures can be frustrating because the errors themselves often prohibit you from accessing your servers.
There are two prerequisites to troubleshooting SSH issues:
- Should I troubleshoot SSH? Determine whether troubleshooting is the right decision or if migration/redeployment is more appropriate.
- What should I do before troubleshooting SSH?. Make sure the issue is truly with SSH, then review the information and skills necessary to resolve SSH issues, like having root access to the server and understanding how to access and edit files.
This article covers these two prerequisites. The other parts of this series cover how to identify and resolve specific SSH errors.
When to Consider Migration or Redeployment
In some cases, such as an accidental recursive rm or chmod command, or incorrect network configurations can lock you out of the Droplet permanently. Other issues may appear as connection issues, but reveal much deeper issues with no clear resolution. This includes:
- Corrupted file systems
- Erroneous file system permissions and file ownership
- Broken system packages and required libraries
To get your deployment back online quickly, determine if trying to troubleshoot the connection is the right solution for your problem or if you should begin focusing on recovering your data for redeployment.
You can typically identify boot-up errors through the Droplet console startup output. Issues pertaining to the file system or any startup failures that prevent a working console login session are signs that troubleshooting your network configuration may not be the better option. In situations like this, the best approach is to salvage what you can. In some cases, a good backup or snapshot strategy can permit a more rapid recovery of a previous working environment, or DigitalOcean Load Balancers may make spinning up a new Droplet and re-deploying that faster solution to getting your deployment running again.
What to Do Before Troubleshooting
If you’ve decided that troubleshooting is right for your situation, go through the following steps:
-
Check the control panel. Before anything else, make sure there are no ongoing issues, like an outage in the region impacting your Droplet.
-
Check if Droplet is disabled because of abuse. Droplets are sometimes disabled due to the detection of abusive activity. If your Droplet has been disabled, an email has been sent to the email address linked to your DigitalOcean account with the title
Networking Disabled: <your-droplet-name>. You can also log in to the support portal to see if any support tickets have been created for your resources.If your Droplet has been disabled due to suspected abuse, contact our support team for further information.
-
Recover root access. If you do not have the current root password, reset it using the reset root password function in the control panel.
-
Access the Recovery Console. If you cannot log in to the Droplet, the Recovery Console is another way to gain access (as long as your Droplet is running and you have a working root password).
-
Reboot your Droplet. Many connectivity problems can be resolved after a reboot. If you’re experiencing connectivity issues, try rebooting the Droplet and see if this resolves the issue.
Before rebooting your Droplet, we highly recommend taking a snapshot of it. This allows you to redeploy your Droplet in its current configuration if rebooting the Droplet causes more serious problems.
To reboot your Droplet, log in to it and run the following command:
sudo reboot -
Review file management and permissions. Some of these solutions may require you to review or edit files on the system or manage permissions.
-
Check logs. Once you can get into the Droplet, check the system’s log files for more information to identify the error so you can then look up a solution.
You can learn more about the logs on your server with this Linux logging tutorial and this journalctl and systemd logging tutorial.
-
Use verbose SSH output. The level of detail an SSH client provides about the SSH session is generally quiet by default. It’s helpful to have more information when debugging an issue.
For the OpenSSH client, you can use the
-voption with multipleventries to increase the verbosity of the output, as inssh -v [email protected]. While most issues are revealed with a singlev, some issues may benefit from-vvv.The PuTTY client supports an Event Log accessible from the context icon in the application window bar. There’s also an option for configuring session logging from the settings page when initiating the connection.
Next Steps
After you decide to troubleshoot an SSH issue instead of migrating or redeploying, you can identify and resolve specific SSH errors based on which phase of a successful SSH connection you need to debug:
