LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 06-14-2015, 07:39 PM   #1
mdooligan
Member
 
Registered: Feb 2009
Location: Vancouver BC
Distribution: Mandrake10/ArchHackery/Gentoo
Posts: 179

Rep: Reputation: 22
sshd and kex algorithms


A Kex Algorithm is a Key Exchange algorithm. I won't bore you with the details, but they are crucial to sshd negotiations. Apparently this problem is so obscure it gets empty results pages from google.

I have 2 trusty old boxes with Mandrake10 installed in about 2005. They're beginning to show their age. I just acquired a newish box that I'm installing freshest and newest of everything.

Old boxes run sshd -V: OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090703f

New box runs sshd -V: OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015

A bit of a difference, huh? New box shells into old boxes fine. Not so the other way around.

Here's some lovely debug output of the situation:
Code:
[miven@timberwolf ~]$ ssh -vvv miven@cobra
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to cobra [192.168.1.66] port 22.
debug1: Connection established.
debug1: identity file /home/miven/.ssh/identity type 0
debug1: identity file /home/miven/.ssh/id_rsa type 0
debug1: identity file /home/miven/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_6.8
debug1: match: OpenSSH_6.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
no matching cipher found: client aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug1: Calling cleanup 0x80628b0(0x0)
After much learning about ssh in general, I discover the 2 versions of sshd cannot agree on which cipher to use. I think about it and come to this conclusion: why teach the old dog new tricks, when I can teach the new dog old tricks.

I find a tidbit on some site that says you can add a Ciphers line in /etc/sshd/sshd_config like this:
Code:
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-ctr,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
So I add it to new box sshd_config. Now my lovely debug output looks like this:
Code:
[miven@timberwolf ~]$ ssh -vvv miven@cobra
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to cobra [192.168.1.66] port 22.
debug1: Connection established.
debug1: identity file /home/miven/.ssh/identity type 0
debug1: identity file /home/miven/.ssh/id_rsa type 0
debug1: identity file /home/miven/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_6.8
debug1: match: OpenSSH_6.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-ctr,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-ctr,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-sha1
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug2: mac_init: found hmac-sha1
debug1: kex: client->server aes128-cbc hmac-sha1 none
no kex alg
debug1: Calling cleanup 0x80628b0(0x0)
"No kex alg"? Huh?

This is where I started getting empty google results. Finally, on this site, I found this tidbit:
Code:
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
Into my sshd_config it goes and Voila!
Code:
[miven@timberwolf ~]$ ssh miven@cobra
[miven@cobra ~]$
Now they agree on ciphers and kex algs. Perfect.

Peace and cheer.
 
Old 06-15-2015, 11:40 AM   #2
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,328
Blog Entries: 3

Rep: Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726
Quote:
Originally Posted by mdooligan View Post
Apparently this problem is so obscure it gets empty results pages from google.
...
I find a tidbit on some site that says you can add a Ciphers line in /etc/sshd/sshd_config like this:
It's not a problem it's supposed to be that way.

You're using 6.8 in the new machine. In 6.7 those old algorithms were removed because they are unsafe: http://www.openssh.com/txt/release-6.7

Adding them back in rather defeats the purpose of using SSH. Then there is the old unsupported OS there. So you might find it better to upgrade your systems to a maintained version of your distro with a recent implementation of SSH.
 
1 members found this post helpful.
Old 06-16-2015, 06:31 AM   #3
mdooligan
Member
 
Registered: Feb 2009
Location: Vancouver BC
Distribution: Mandrake10/ArchHackery/Gentoo
Posts: 179

Original Poster
Rep: Reputation: 22
Quote:
Originally Posted by Turbocapitalist View Post
It's not a problem it's supposed to be that way.

You're using 6.8 in the new machine. In 6.7 those old algorithms were removed because they are unsafe: http://www.openssh.com/txt/release-6.7

Adding them back in rather defeats the purpose of using SSH. Then there is the old unsupported OS there. So you might find it better to upgrade your systems to a maintained version of your distro with a recent implementation of SSH.
Indeed. I read some of that stuff about keeping ahead of the NSA. Hey, now they've infiltrated the kernel with SELinux. The great Kernel War is right around the corner . I can just see geeks with pocket protectors shivving each other in the dimly lit corridors of the CS Faculty building the night before a new release...

I kinda figured that there was a reason for dropping the older algorithms, thanks for the link. I wanted to put this here for the benefit of others who may encounter the same problem issue, however unlikely.

In my defence, all I do is shell into the various PCs on my LAN, so I could be using telnet, but now I know a lot more about a tool I take for granted. As a matter of fact, with all the trouble getting ssh working full duplex through a PC generation gap, I seriously thought about it. My router keeps all ports <10000 closed, so getting pounded by script kiddies is not an issue... well... I trust my router, and I watch my logfiles... occasionally... *shrug*

Yeah, if I needed to shell in from outside the LAN I would certainly make sure my ssh was new, clean and mean. This begs the question:

Any idea if there's a way in sshd_config to specify something like, eg:
Code:
if (client = 192.168.1.*) {
    KexAlogrithm blahblah
    Ciphers blahblah
}
?

Peace and cheer.
 
Old 06-16-2015, 08:19 AM   #4
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,328
Blog Entries: 3

Rep: Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726
Match would have been the way to do that, but neither KexAlogrithm nor Ciphers are in the subset of keywords that Match can modify. But one way around that would be to make a second sshd_config file set to listen on a different port but otherwise using the settings you want. You'd then need an init script to launch that second instance of sshd using that second sshd_config to make it automatic on boot like the other services.

Last edited by Turbocapitalist; 06-16-2015 at 08:20 AM.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Algorithms Amdx2_x64 Programming 7 08-09-2008 06:32 PM
Starting sshd: /etc/init.d/sshd: line 113: /usr/sbin/sshd: Permission denied sumanc Linux - Server 5 03-28-2008 04:59 AM
FC4-Starting sshd: Privilege separation user sshd does not exist FAILED kiranherekar Fedora 5 12-29-2005 02:22 PM
Enabling SSH in mandrake 9.2 - sshd vs. sshd-xinetd DogTags Linux - Newbie 7 11-25-2003 12:17 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 06:46 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration