I cannot connect (ssh) to my droplet.

Posted April 20, 2017 7.3k views

I all of a sudden cannot connect to my droplet via ssh through Mac terminal. I ran the following:

ssh -vv root@my_ip

And get the following:

MacBook-Pro:~ myname$ ssh -vv root@myip
OpenSSH6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh
debug1: /etc/sshconfig line 20: Applying options for *
debug1: /etc/ssh
config line 102: Applying options for *
debug2: sshconnect: needpriv 0
debug1: Connecting to my
ip [myip] port 22.
debug1: Connection established.
debug1: identity file /Users/my
name/.ssh/idrsa type 1
debug1: identity file /Users/my
name/.ssh/idrsa-cert type -1
debug1: identity file /Users/my
name/.ssh/iddsa type -1
debug1: identity file /Users/my
name/.ssh/iddsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH
sshexchangeidentification: read: Connection reset by peer

Any ideas?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer


How was the Droplet setup? – A one-click image, manually, etc?

Are you using a firewall such as ufw or an IPS such as fail2ban?

If so, you may have been blocked in which case you’d need to login using console and check the logs, and/or disable the firewall or service to see if that’ll allow you back in.

You can access DigitalOcean’s console by logging in to the DigitalOcean Control Panel, clicking on the name of the Droplet, then from the left side menu, click on Access. You’ll see a big blue button that says Launch Console. You’ll need your root password to login.

ufw can be disabled using ufw disable. Once disabled, I normally recommend resetting the rule set and starting fresh. If you’re able to login using Terminal once ufw is disabled, do so, and then run the following (you should be able to copy and paste to Terminal):

ufw reset

Followed by:

ufw default deny incoming \
&& ufw default allow outgoing \
&& ufw allow 22/tcp \
&& ufw allow 80/tcp \
&& ufw allow 443/tcp

Followed by:

ufw enable

The above will reset ufw to a barebones configuration, setup default policies, and then only allow a connection on ports 22, 80, and 443.

  • I cannot even login to console, so I cannot try any of the above commands. All it says is “Failed to start login to default iSCSI targets…”
    It was running perfectly and just stopped. How is anyone supposed to rely on a droplet if this can just happen?

    • @doctormcluvin

      If you’re using SSH Keys as your default (which is what happens if you deploy with an SSH key), you won’t be able to login to console. Console doesn’t accept SSH keys like Terminal (MacOS) or PuTTy (Windows/Linux).

      The only way to login to console is with the root user and the password associated. If the root user is locked, you’re effectively locked out, though this isn’t limited to Droplets. The same could happen elsewhere.

      That said, beyond hardware and platform-specific issues, DigitalOcean is an unmanaged provider, which means you’re responsible for knowing how to manage your Droplet (i.e. server). Support is limited to hardware, network, and platform (such as the main control panel and API) – scope that falls outside those things is the responsibility of the end-user.

      You’re also responsible for troubleshooting software-specific issues, such as firewall, web server, application issues, etc. That’s all part of being unmanaged, though a lot of people don’t realize that, even though the vast majority of providers are unmanaged or require that you pay for support – that includes Linode, Vultr, Amazon AWS, Google GCP, etc.

      Managing a server is a lot like going out and buying the parts to build a computer or server. You can do it yourself by reading guides and learning how, or you can pay someone to do it for you.

      I say this not to discourage others, but to put it in to perspective.

      I’ve been working with servers for about 16-17 years now. Many make the assumption that when they deploy a server and install WordPress (or any application), all they need to focus on is WordPress (or the app) security and install a ton of plugins/modules.

      They forget about the server side, end up getting hacked, then wonder what happened because those plugins were supposed to keep them secure. It just doesn’t work like that :-). When you deploy an unmanaged server, it’s all on you or the person(s) you’re paying to handle it.