Question

SSH not working

I’m having a problem using SSH to connect to any new droplets I have been spinning up. I am using a one-click app to create a Ubuntu Wordpress 4.7 on 16.04 droplet. When the droplet is first created, I can SSH using Mac’s Terminal successfully. However, once I log out and try to log in either with Terminal, or to use Sequel Pro, or Transmit to SSH into the server, the connection is refused.

Using Terminal to try to SSH in, here is the error log: OpenSSH_6.9p1, LibreSSL 2.1.8 debug1: Reading configuration data /Users/ameerbacchus/.ssh/config debug1: /Users/ameerbacchus/.ssh/config line 3: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 138.197.154.119 [138.197.154.119] port 22. debug1: connect to address 138.197.154.119 port 22: Connection refused ssh: connect to host 138.197.154.119 port 22: Connection refused

Using Sequel Pro, I get this error message:

The SSH Tunnel could not authenticate with the remote host. Please check your password and ensure you still have access.

Used command: /usr/bin/ssh -v -N -S none -o ControlMaster=no -o ExitOnForwardFailure=yes -o ConnectTimeout=10 -o NumberOfPasswordPrompts=3 -o TCPKeepAlive=no -o ServerAliveInterval=60 -o ServerAliveCountMax=1 root @138.197.154.119 -L 52774:127.0.0.1:3306

OpenSSH_6.9p1, LibreSSL 2.1.8 debug1: Reading configuration data /PATH/.ssh/config debug1: /PATH/.ssh/config line 3: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Control socket " none" does not exist debug1: Connecting to 138.197.154.119 [138.197.154.119] port 22. debug1: fd 3 clearing O_NONBLOCK debug1: Connection established. debug1: identity file /PATH/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /PATH/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 138.197.154.119:22 as 'root ’ debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:hl+ZkCGXBbWJUlKWyf2uWhLR3XcENlVSAi3TibfvDHU Warning: Permanently added ‘138.197.154.119’ (ECDSA) to the list of known hosts. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /PATH/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /PATH/.ssh/id_dsa debug1: Trying private key: /PATH/.ssh/id_ecdsa debug1: Trying private key: /PATH/.ssh/id_ed25519 debug1: Next authentication method: password debug1: read_passphrase: can’t open /dev/tty: Device not configured debug1: permanently_drop_suid: 501 debug1: Authentications that can continue: publickey,password Permission denied, please try again. debug1: read_passphrase: can’t open /dev/tty: Device not configured debug1: permanently_drop_suid: 501 debug1: Authentications that can continue: publickey,password Permission denied, please try again. debug1: read_passphrase: can’t open /dev/tty: Device not configured debug1: permanently_drop_suid: 501 debug1: Authentications that can continue: publickey,password debug1: No more authentication methods to try. Permission denied (publickey,password).

Subscribe
Share

Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

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.

@ktottenATG

I just installed Sequel Pro back on my MBP and setup a stock installation of MariaDB (MySQL) using a bind address of 0.0.0.0 on a demo Droplet.

So bind-address looks like bind-address = 0.0.0.0.

I setup the same ufw rules that I provided you with:

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

I then added the IP-Specific rule to only allow my IP to connect on port 3306.

ufw allow from MY_IP to any port 3306

Where MY_IP is my IP address (that of my VPN, so that I have a static IP).

When connecting to MySQL through Sequel Pro, my configuration looks like this:

http://oi68.tinypic.com/309seop.jpg

When testing the configuration, I get a success message. When trying to log in and out via SSH and using Sequel Pro over SSH, I’m not seeing any blocks occur, nor denial of access. I am using an SSH Key to login, though it prompts me for the key passphrase as expected and logs me in without any issues.

If you’re not using Sequel Pro via SSH, and instead using Sequel Pro’s Standard Connection method, you will need to add another user.

For example, if I’m connecting from my VPN IP, it’s not allowed to connect, so I need to give access to my IP by creating a second user.

grant all on dbname.* to 'dbuser'@'MYIP' identified by 'mypass';

Where MYIP is my VPN IP. So I end up with two users.

'dbuser'@'localhost'

and

'dbuser'@'MYIP'

The two logs (terminal and sequence-pro) look quite different to me.

The connection refused message by the destination in the Terminal attempt indicates that SSH isn’t even running (or configured for a different port) on port 22. I.e. nothing is serving that port.

With the other you are getting a connection (i.e. the ssh server answers), but the authentication fails.

What do you see if you telnet to the machine on port 22?

telnet 138.197.154.119 22

Ideally you should see a prompt saying OpenSSH and the version number. You can’t do more with Telnet but it indicates that the server is at least up and answering.

@ktottenATG

connect to address 138.197.154.119 port 22: Connection refused

Normally boils down to the firewall blocking your connection. This can happen for a few reasons, one of which is excessive login failures.

From what I recall, most of the one-click images for Ubuntu are setup with ufw, a firewall that acts as an overlay to iptables and simplifies the process of setting up most rule types.

If you’re blocked, the only way to get back in is via Console which you can access from the DO CP.

Click on the name of the Droplet in question. From the left side menu, click Access. Now click on the button that says Launch Console.

You’ll need your root password to login. If you only deployed with SSH Keys, the root password is disabled – in such a case, you’re effectively locked out of the server as the Console doesn’t allow pubkey authentication.

If you do have a root password set, you’ll be prompted to enter it in. You won’t see anything when entering the password, so you’ll need to type it in carefully. Once you have, hit enter.

Once logged in, you can run:

ufw disable

That’ll turn ufw off. Keep in mind, it’s not really recommended to run without a firewall active, so the best thing to do would be to simply reset the firewall and then setup new rules.

Once the firewall is disabled, try to login via SSH once again. If you’re able to login, I would use the following to setup the firewall.

Double-Check ufw is disabled:

ufw disable

Reset the rules:

ufw reset

Setup Default Policies:

ufw default deny incoming && ufw default allow outgoing

We’re setting the default policy to deny any incoming connection. This is preferred as we want to setup a deny all, except what we explicitly allow type policy. This is the first part.

Now, we’ll add rules for SSH (Port 22), HTTP (Port 80), and HTTPS/SSL (Port 443). These are the ports we want to allow connections on. This ensures that only these three ports are open, no more, no less.

ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp

Now, I noticed that you’re using Sequel Pro, which means we need to open another port, and that’d be 3306 as that’s the port MySQL/MariaDB communicate on by default. The issue here is that with the base configuration for MySQL (which is what DigitalOcean uses), remote access to MySQL is not enabled, so you need to enable it.

You should have this file:

/etc/mysql/my.cnf

We need to open that file using nano and find bind-address. Normally this is set to 127.0.0.1, which is localhost. If you try to connect with bind-address set to that IP, it’ll fail.

You need to change bind-address to either 0.0.0.0 or the IP address of your Droplet (the IPv4 IP) and then restart MySQL.

service mysql restart

To add MySQL to the firewall, we’d issue one more allow command, like so:

ufw allow 3306/tcp

With SSH, HTTP, HTTPS, and MySQL now added, we can enable ufw using:

ufw enable

It’ll ask you to confirm – do so – and logout, then try to login again. Then try to login with Sequel Pro, etc.

Note: It’s really not a good security practice to allow open access to port 3306 as is being done in the above guide. Ideally you would restrict access to a single IP, or set of IP’s (if multiple people need access). Allowing open access, such as what is being done here allows anyone to attempt to login to MySQL on your server, whether the user(s) exist or not.