Don’t know when they introduced this gem, but I have been SSHing into servers for years, but I had a need to use DSA keys to SSH into a F22 server from a F23 one, and dsa keys just refused to work from a F23 client.
The F22 target server was happily accepting DSA key logins from my F17 desktop, so the issue was not on the target server but on the F23 client. And I’m pretty sure before I upgraded the client machine from F22 to F23 it was working.
(yes I know F17 is obsolete, but changes to either mencoder or ffmpeg in F18 broke most of my key video capture scripts, I tried F19, F20, F21 and had to bare metal restore back to F17 in each case to keep working; so I gave up trying to upgrade, my main desktop will be F17 for life)
Anyway, after generating new DSA keys and still having it fail I ran the ssh connection in verbose mode and it came up with this little gem.
debug1: Next authentication method: publickey debug1: Skipping ssh-dss key /home/mark/.ssh/vmhost1_id_dsa for not in PubkeyAcceptedKeyTypes debug1: Next authentication method: password
Now the not so fun bit was deciding where the hell that lived, a “grep -i PubkeyAcceptedKeyTypes *” in the /etc/ssh directory on the client found no occurrences of it. Even though I had already decided the issue was on the client I repeated the grep on the target with no matches found there either.
The way to get it working
On the F23 client I was already using customised config files, for most of you the key thing to know is that if you have a file ~/.ssh/config (the default filename) parameter values in there can override the default values for the ssh client session. As it is clear an upgrade to F23 changed the behaviour of SSH it is probably best to use a customised config file anyway.
I added an extra line in the ~/.ssh/config file as below
[mark@vmhost1 .ssh]$ cat config IdentityFile ~/.ssh/vmhost1_id_dsa PubkeyAcceptedKeyTypes ssh-dss
And ssh using DSA keys started workibg again from the F23 client.
Notes
- Such a major behaviour change was probably documented somewhere, but who reads thousands of pages of package update notes
- There was probably a very good reason that change was done, although if so it was done in a stupid way…
- …if it was for any sort of security reason is would be done on the server side, not on a client
Perhaps this change is just an initial step to encourage people to change the target server configuration before the server defaults change to lockout DSA keys by default; which is unlikely to happen as there are probably thousands of client software packages that would break if that was done.
But the F23 ssh client default configuration has changed to prevent DSA keys being used for ssh-key logins, and the above will fix it. For F23 anyway, who knows what they will change next.
