DigitalOcean Droplets are Linux-based virtual machines (VMs) that run on top of virtualized hardware. Each Droplet you create is a new server you can use, either standalone or as part of a larger, cloud-based infrastructure.
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. This troubleshooting series covers some of the most common issues you may encounter with SSH, how to address them, when to consider re-deploying, and how to get further support.
This tutorial specifically covers two important prerequisites to troubleshooting your SSH issues:
The other parts of this series cover how to identify and resolve specific SSH errors, and are broken down by which phase of a successful SSH connection you need to debug.
In some cases, such as an accidental recursive
chmod command, issues with the SSH service cannot be resolved. Other issues may appear at the outset as SSH connectivity issues, but reveal much deeper issues with no clear resolution. This includes:
To get your deployment back online quickly, determine if trying to revive the SSH service 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 Recovery Console startup output. Issues pertaining to the file system or any startup failures that prevent a working console login session are signs that troubleshooting SSH 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, you’ll need to know a few things before you dive in.
To get familiar with SSH, you can read up on how to connect to your Droplet with SSH and how to use SSH keys with your Droplet. These guides can add some clarification to your setup process to help you avoid or understand some issues.
Many of the steps outlined in the detailed troubleshooting articles need to be completed from within the running Droplet. While SSH is down, the Recovery Console is an alternative way to gain access, provided your Droplet is running and you have a working root password.
If you do not have the current root password, reset it using the reset root password function in the control panel.
The level of detail a client provides about the SSH session is generally quiet by default. When you run into an issue, however, this relative silence can hide insight into the problem.
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.
In these articles, references to the current user’s home directory is listed
~. For the username sammy, the path
~/.ssh would usually translate to
/home/sammy/.ssh. The root user path is typically found at
Once you can get into the Droplet, the system typically has logs available that can shed more light on the situation you may be facing on the server. It’s a good idea to look at log files to begin identifying what the error is so you can then look up a solution.
Now that you’ve decided if you should troubleshoot and you’re familiar with the skills you’ll need to do so, you can begin to resolve any SSH errors by following the appropriate tutorial: