Topic: SSH problems

[toothandnail]

I manage a system which has two SME servers (one gateway, currently running SME 8, one internal file server recently updated to SME 9). This network also has what is effectively a NAS device running Slackware. A week or so ago, the NAS box had a hard drive fail. I've fixed the problem, but in doing so, I've updated to the  most recent version of Salckware. And I've now got a problem....

I had public keys set up between the SME servers and the NAS machine. I migrated the keys to the new Slackware install. However, attempting to login from the SME gateway machine (SME 8 ) resulted in this error:

Code: [Select]

[root@huntmaster ~]# ssh -v root@filestore.geminiprototyping.co.uk
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to filestore.geminiprototyping.co.uk [192.168.0.221] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 2 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7.1
debug1: match: OpenSSH_6.7.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
no matching cipher found: client arcfour256,blowfish-cbc,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
Further checking shows I have exactly the same problem logging in from the SME 9 server, so, even though I will be upgrading the gateway server to SME 9 in the near future, that isn't going to help.

So far as a I can determine, the version of  OpenSSH/OpenSSL installed in Slackware no longer supprts the *-cbc ciphers. By attempting to activate them in /etc/ssh/sshd_config on the NAS box, I've got it to fail back to using passwords, so at least I can access the machine from either of the SME servers. Not a very attractive answer, especially since I need script access to the NAS machine, which is not practical with password prompts.

After checking, I've found SME 8 has OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, SME 9 has OpenSSH_6.7.1p1, OpenSSL 1.0.1j 15 Oct 2014, and the Slackware NAS has OpenSSH_6.7.1p1, OpenSSL 1.0.1j 15 Oct 2014.

I really don't want to try downgrading the OpenSSH/OpenSSL versions in Slackware, so I'm wondering if there is any way of adding support for the more recent cipers to the versions installed in SME? Or any other way round my current problem?

Paul.

[stephdl]

Hi

I don't know if what I did is good, for now I have done like that

on the remote host (NOT SME Server)

Code: [Select]

vim /etc/ssh/sshd_configand add at the end

Code: [Select]

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
after that restart the ssh service or restart the remote host.

I have the same problem with fedora22 and debian8.1

[CharlieBrady]

Stephdl, I presume that you made those changes on the non-SME systems that you want to connect to from SME server.

Here is some background:

http://mgalgs.github.io/2014/10/22/enable-arcfour-and-other-fast-ciphers-on-recent-versions-of-openssh.html

The core issue is openssh removing a set of ciphers from the default set in version 6.7 as they are no longer considered sufficiently secure:

http://www.openssh.com/txt/release-6.7

[toothandnail]

Stephdl, I presume that you made those changes on the non-SME systems that you want to connect to from SME server.

Here is some background:

http://mgalgs.github.io/2014/10/22/enable-arcfour-and-other-fast-ciphers-on-recent-versions-of-openssh.html

The core issue is openssh removing a set of ciphers from the default set in version 6.7 as they are no longer considered sufficiently secure:

http://www.openssh.com/txt/release-6.7

Thanks for the reference. I've added the full set of ciphers to /etc/ssh/sshd_config on the Slackware box. However, it still doesn't seem to be using the older ciphers - it does allow the slackware SSH daemon to fall back to password authentication. Not an ideal option.

Is there any chance of a later version of OpenSSH for SME? I use SSH a lot with SME servers and would be much happier to have the more recent, more secure ciphers available for it.

Paul.

[Stefano]

Is there any chance of a later version of OpenSSH for SME? I use SSH a lot with SME servers and would be much happier to have the more recent, more secure ciphers available for it.

SME uses binaries coming from RH/CentOS.. so your best bet is to find an updated ssh version for CentOS6 and try..

please, be aware that doing so you're on your own since it's an unsupported option

in any case, let us know, thank you


[edit typo on CentOS version]

[toothandnail]

SME uses binaries coming from RH/CentOS.. so your best bet is to find an updated ssh version for centos9 and try..

please, be aware that doing so you're on your own since it's an unsupported option

in any case, let us know, thank you

CentOS 9? I've had a bit of a look through the listings, latest I can find is 7. Went to their repos and did a search for OpenSSH. Latest version listed is openssh-6.6.1p1-12.el7_1.x86_64. Which may not be much use - it seems that the change was made in 6.71.

I'll give it a try, but I'm going to wait until I can do it from the site - I'd hate to kill my access to the system and not be able to get back in. Means it probably won't be until next week. In the meantime, I'm going to have to live with the lack of automatic logins.

Thanks for the suggestion.

Paul.

[Stefano]

sorry, typo.. CentOS 6, obviously.

[CharlieBrady]

Thanks for the reference. I've added the full set of ciphers to /etc/ssh/sshd_config on the Slackware box.

I think that is likely the wrong approach. I think you should try adjusting the ssh client configuration on SME, until you find a cipher set which allows you to connect to the default configuration on the Slackware box.

[toothandnail]

I think that is likely the wrong approach. I think you should try adjusting the ssh client configuration on SME, until you find a cipher set which allows you to connect to the default configuration on the Slackware box.

You're probably correct. At least, adding all of the ciphers hasn't done much other than force the SSH daemon on the Slackware box to revert to password authentication.

I'll have to wait until I'm on site - taking the cipher list out remotely might well lose me the access I have now. Can't afford to do that....

Paul.

[CharlieBrady]

What happens if you try:

 ssh -c aes256-ctr -v root@filestore.geminiprototyping.co.uk

Anything from this list is worth trying (according to https://bbs.archlinux.org/viewtopic.php?id=188613):

aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

[toothandnail]

What happens if you try:

 ssh -c aes128-ctr -v root@filestore.geminiprototyping.co.uk

Still get to a password prompt:

Code: [Select]

[root@huntmaster ~]# ssh -c aes128-ctr -v root@filestore.geminiprototyping.co.uk
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to filestore.geminiprototyping.co.uk [192.168.0.221] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 2 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7.1
debug1: match: OpenSSH_6.7.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'filestore.geminiprototyping.co.uk' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
root@filestore.geminiprototyping.co.uk's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US
Last login: Tue Jul  7 19:40:28 2015 from huntmaster.geminiprototyping.org
That may be confused by the full list of ciphers that I've already put into /etc/ssh/sshd_config on the Slackware box, something I don't want to undo until I can physically access the machines if I need to....

Paul.

[CharlieBrady]

You have two problems to solve, one is the cipher negotiation, and the other is the RSA key authentication.

Looks like installing the latest version of Slackware without regression testing your systems first was a bad idea...

[toothandnail]

You have two problems to solve, one is the cipher negotiation, and the other is the RSA key authentication.

I think the two are either the same or very closely related. Prior to adding the cipher list to the SSH daemon on the slackware box, I couldn't log in at all (sorry, not entirely accurate - I could log in directly from my laptop, which runs Arch and the most recent version of OpenSSH). It was only after I added the cipher list and restarted the SSH deamon on the Slackwer box that it started reverting to password authentication.

Looks like installing the latest version of Slackware without regression testing your systems first was a bad idea...

Wouldn't be the first time. Unfortunately, I didn't have an option - had to do the repair/install in a hurry and the later version was all I had...

If I get really stuck, I'll see if I can revert to an older version of OpenSSH on the Slackware box, though I'd prefer not to have to do that.

Paul.

[CharlieBrady]

I think the two are either the same or very closely related.

I don't.

It was only after I added the cipher list and restarted the SSH deamon on the Slackwer box that it started reverting to password authentication.

It reverted to password authentication because publickey auth isn't configured correctly.

[stephdl]

Stephdl, I presume that you made those changes on the non-SME systems that you want to connect to from SME server.

yes, added in my post

[Xavier.A]

@toothandnail :
maybe you should fix your authentication but i think you should have a look at the OpenSSH man page and the OpenSSL man page.

First try on your SME:

Code: [Select]

ssh -V

on your Slackware :

Code: [Select]

ssh -V

and on both :

Code: [Select]

ssh -Q cipher ; ssh -Q cipher-auth
openssl ciphers -v
openssl list-cipher-algorithms
what do you notice ? Do you make a difference between OpenSSL and OpenSSH?

Many ciphers are deactivated by openSSH, to test a cipher, you can try :

Code: [Select]

ssh $USER@$SERVER -p $PORT -C -c $CIPHER

ssh $USER@$SERVER -p $PORT -C -c blowfish
ssh $USER@$SERVER -p $PORT -C -c chacha20-poly1305@openssh.com

The cipher algorithms are just algorithms for cryptography so now you can read this page and this page, to understand what you are trying to do.

A+

PS : french developers should read this page