Problems after updating openssh on 14.1

louigi600 · 01-19-2016, 10:01 PM

I just upgraded to openssh-7.1p2 on my router and I've noticed I can't login with root neither with a previously tested and working dsa public key or with password login.
By specifically allowing root login "PermitRootLogin yes" I can still login with a password but I've been unable to get the public key to work again.

Have dsa keys being disabled because of the 1024 bit fixed lenght problem ? (apparently anything shorter then 2048 bits is no longer considered secure) or is something else going on ?

louigi600 · 01-20-2016, 01:36 AM

I guess that most likely my problem is bound to DSA keys. Here's a snippet from the 14.1 changelog

Code:

  * Support for the 1024-bit diffie-hellman-group1-sha1 key exchange
    is disabled by default at run-time. It may be re-enabled using
    the instructions at http://www.openssh.com/legacy.html

As far as I know operssh only supports 1024 bit DSA keys so that would mean that DSA keys are disabled by default.
I'll confirm as soon as I get back home.

louigi600 · 01-20-2016, 03:19 AM

Unfortunately I cannot confirm ... as upgrading on a x86 machine I use for work caused problems even if I use RSA keys. The x86 machie is only used as client ... and it's a big problem on my work PC because I only use key auth.
The new 7.1 client seems to have trouble inter-operating with redhat based servers that run old version 4.3 ... while the debian based servers running version 5.9 or newer and even redhat servers using version 5.3 or newer seem to work.

I rolled back to the initial release and that seems to have settled the issue (at least on the servers I've checked so far) ... but the initiall release is going to have a lot of known vulnerabilities.
Damn it where can I get the last but latest version ?
I found the last but latest for x86 here http://slackware.laukas.lt/ ... it's still amongst the mirrors ... should be ok.

drmozes · 01-20-2016, 08:57 AM

Quote:

Originally Posted by louigi600

I found the last but latest for x86 here http://slackware.laukas.lt/ ... it's still amongst the mirrors ... should be ok.

I also had problems on x86 where OpenSSH was presenting a different server key despite me keeping the keys the same. It was definitely using the correct file name though. The key was created several years ago so I didn't look further into it.

The 6.1 ARM packages are here. Fortunately my rsnapshot config goes back for a few months!
http://armed.slackware.com/slackware...tuse/packages/

louigi600 · 01-20-2016, 01:41 PM

Quote:

Originally Posted by drmozes

I also had problems on x86 where OpenSSH was presenting a different server key despite me keeping the keys the same. It was definitely using the correct file name though. The key was created several years ago so I didn't look further into it.

The 6.1 ARM packages are here. Fortunately my rsnapshot config goes back for a few months!
http://armed.slackware.com/slackware...tuse/packages/

Er ... not sure on that
On my work pc the RSA key was created this morning distributed and tested with the old ssh prior to upgrading.
After the upgrade things broke on servers running older sshd and when I reinstalled the older version everything went back to normal and I could use both ond dsa key and new rsa key.

At home the dsa key was created 10 days ago.
Fortunately at home I've only Slackware so I don't need to inter-operate with older sshd servers allowing me to keep the new 7.1 version as long as I use only RSA keys.

In any case the previous version was openssh-6.7p1-arm-1_slack14.1 (or at least /var/log/removed_packages seems to suggest that).
In any case in the link you gave above you get 6.7p1 so maybe it was just a typo when you talk about 6.1.

I guess we could call this solved with exception for inter-operation with sshd versions prior to 5.3.

dowelld · 02-03-2016, 07:15 AM

I now find myself having to generate two different key types so that I can support access to a range of different ssh versions are different levels.

I have this script in /etc/profile.d, so it gets run on login of a user account.

Code:

#!/bin/sh
#
# If the .ssh directory does not exist then make it !
if [ ! -d $HOME/.ssh ]; then
  echo -n "Making the .ssh directory in $HOME "
  mkdir $HOME/.ssh
  echo "DONE"
fi
#
# If the id_dsa key does not exist in the $HOME/.ssh directory then make it !
if [ ! -f $HOME/.ssh/id_ed25519 ]; then
  echo -n "Generating a new ssh ed25519 key "
  /usr/bin/ssh-keygen -q -b 1024 -t ed25519 -N "" -f $HOME/.ssh/id_ed25519
  echo "DONE"
fi
if [ ! -f $HOME/.ssh/id_rsa ]; then
  echo -n "Generating a new ssh rsa key "
  /usr/bin/ssh-keygen -q -b 1024 -t rsa -N "" -f $HOME/.ssh/id_rsa
  echo "DONE"
fi

It generates me a set of ed25519 keys (that's the more secure cipher) and a set of rsa keys (that's the more portable cipher). I'm using the relevant public key for the version of ssh on the remote system. So on systems with ssh version 3 (yes I have to access systems running stuff that old) the rsa keys are the ticket, and on new installs the ed25519 keys will be my default choice.