SSH keys are no longer working after upgrading to Ubuntu 16.04.LTS – Help!

I recently upgraded one of my laptops to Ubuntu 16.04.LTS (going from 14.04.LTS). The upgrade went very smooth and I have no issues with the resulting operating environment 🙂 Having said that, I quickly discovered a quite serious issue for me when I attempted connecting to one of many servers I need to get into. All of a sudden, my SSH key was no longer accepted by the server, and I was prompted for a password! WTF!?

I immediately feared the worst and started looking at the server(s), tailing log files, enabling debugging, etc. No trace was to be found other than that no key was presented by the client. The servers were intact, the authorized_keys had not been compromised, and vanilla ice cream was still the number one flavor. The problem is not with Ubuntu 16.04.LTS. The problem is with my SSH key, as well as a recent change in “acceptable keys” by OpenSSH, version 7.

Doing “ssh -vvv user@server.com” told me that the SSH client couldn’t find an acceptable key to present to the server. After having figured that out, and facepalming for a few seconds, I added this to my /etc/ssh/ssh_config file:

PubkeyAcceptedKeyTypes=+ssh-dss

Saved the file and tried again. Voila! One could say many things about using this type of SSH key, but rest assured I will change mine. You should too if you run into this problem. This is a workaround, not a fix or a solution. So sit down with some vanilla ice cream (with actual vanilla) and something nice to drink and go through the process of replacing your public SSH keys everywhere.

16 thoughts on “SSH keys are no longer working after upgrading to Ubuntu 16.04.LTS – Help!”

    • It’s not really the Ubuntu distribution that causes the problem, it’s which keys are by default supported by the SSH server. I didn’t have any issues after upgrading to 14.04. My problems with SSH keys started after the 16.04 upgrade.

      Reply
  1. I don’t have /etc/ssh_config file.
    Did you mean /etc/ssh/ssh_config perhaps?
    I have the latter, but the settings in that file seem to have a different format, without the = character.

    Reply
  2. Thank you! I updated a couple of days ago and every time using Unison, SVN, etc… I’ve had to introduce the password.

    One positive thing from this issue… I’m going to remember very well for a long time my pass 🙂

    Reply
    • Glad it worked out for you. Keys are (of course) a much beter mechanism than passwords, until you misplace them or something else happens 🙂

      Reply
  3. You saved my life.
    I have 160 VPS boxes that all are only accessible through public key. I was banging my head on the table for hours until I found your solution.
    And yes – I will certainly change the keys against something more solid but that’s going to take days….. 🙂

    Reply
  4. After reading your posts, I hoping you might be able to explain what I am experiencing.
    I have a test software on a windows machine accessing a linux box (Ubuntu 14.04). The linux would then ssh into remote unit running linux.
    The command was sshpass -p “password” ssh “user”@xxx.xxx.xxx.xxx
    this was working just fine but now for some reason the remote box is rejecting access.
    The only way to access now is by dropping the “user@”. Then everything works.
    I’m trying to understand what happened as I don’t want to change code in all the various test software.
    Hope you can help
    Tony

    Reply
    • Have you tried enabling debug logging on all sides to see what’s going on? It sounds like a key/user mismatch issue, or possibly a key algorithm issue.

      Reply
  5. Thank you for facepalming and this workaround!
    Additionally I had to insert PubkeyAcceptedKeyTypes=+ssh-dss
    into /etc/ssh/sshd_config and restart sshd in order to connect again into my Ubuntu 16.04 server using PuTTY on Windows witrh my old private key.

    Reply

Leave a Comment

Notify me of followup comments via e-mail. You can also subscribe without commenting.