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:
This article covers these two prerequisites. The other parts of this series cover how to identify and resolve specific SSH errors.
In some cases, such as an accidental recursive
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:
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.
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:
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.
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
-v option with multiple
v entries to increase the verbosity of the output, as in
ssh -v [email protected]. While most issues are revealed with a single
v, some issues may benefit from
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.
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: