This question has been archived.

SSH timing out + refusing keys

January 16, 2016 4.4k views
LEMP PHP Nginx Ubuntu

It all started when I ran a "reboot" command for the server while shelling in on PuTTY. SSH keys that were previously perfectly functional have stopped being accepted by the server. Have gone to control panel and verified private and public keys are matching, but server still refuses them.

The order of events changes seemingly at random. Sometimes it refuses what was once (and in theory should still be) a perfectly good key. Other times there is no attempt by the server to even authenticate with a key, instead asking for only user and pass (which, of course, fails). This occurs when both trying to login as a sudo-equipped user or as root.

That's if I get that far, which often I do not. Both PuTTY & WinSCP often end up with "Network error: Connection timed out" when attempting to shell into the droplet, even though the network ping for the IP from my computer is consistently around the 25ms mark.

Sometimes WinSCP will throw the error;
"Authentication failed. The server rejected SFTP connection, but it listens for FTP connections." However, this is at odds with, which confirms port 22 is open and listening, while plain FTP is being refused. I have also confirmed via the console access on DO that the ssh module is running, and have restarted it with no effect.

Everything was rosy and ticking over nicely until invoking "reboot" over SSH. So I imagine the cause has something to do with this. The server is now very slow and throwing semi-regular 502 errors too.

For reference, I am running LEMP with Ubuntu 14.04.

  • Are you able to log into the server over the remote console? From here, you should be able to check the syslog and see if there's errors being thrown in there? Maybe even a re-install of openssh-server should be performed.

    You could also try SSH'ing to the server using some verbose flags to get a better picture of what's going on when you try to log into the server although this will require a native SSH client capable of providing that output.

  • Yeah, this is what confused/worried me, I checked out the error log and found no explanation. There's nothing in the error log from after the reboot in question.

    I have reinstalled openssh over the remote console. No effect. I don't seem to be getting failing connections anymore, just the scenario where the server doesn't attempt to authenticate with my key, asking only for user/pass (which, despite inputting the correct user/pass combo, fails, whether attempting to login as root or my sudo user).

    I don't have access to a native SSH client - Windows user!

    Something else I tried was taking a snapshot, and using it to start a droplet with a new SSH key pair. This hasn't worked either - it refuses the key and asks for a user password instead of the key passphrase as it should.

    My server has also started to throw out regular 502 errors since these issues began. Could be completely unconnected, but the timing makes me wonder if it's connected somehow...

  • Update: Set PasswordAuthenticaion to "no" and this outputs a new error of;

    "Disconnected: No supported authentication methods available (server sent: publickey)"

    I have checked the authorizedkeys file and the string matches up to the private key pair being used. It's all one one line, I know to check for that! To be clear, this is a key pair that has been functioning perfectly on this server for months. I haven't changed the path for the authorizedkeys location in sshd_config. It must be "working", as the server refuses other keys I try that don't match the public one on the server.

  • I'm having the same issue. I tried FTP as well but I receive the same error or sometimes "No connection could be made because the target machine actively refused it. Connection failed." I'd appreciate a little guidance.

  • I never actually found a solution to this problem. Instead I resorted to backing up the important contents of the droplet, destroying it, and creating a fresh droplet in its place.

    In hindsight I think this was two separate issues;

    1. There really was an SSH issue that was causing authentication problems, that I never managed to work out the root cause of.
    2. I think the "difference in behaviour" was down to the droplet IP being on the receiving end of brute force attacks (that became an issue with the replacement droplet) that my server settings at the time weren't correctly optimised to deal with.

    If it's only the first issue you're experiencing, then I still have no insight as to what the real issue was. My only suggestion - not being particularly savvy with this stuff - would be to create a brand new public/private key pair, find a way to load the new public key into the authorized_keys file, and hope by using a brand new key pair you can regain FTP access. If not, I have no idea. Sorry!

Be the first one to answer this question.