sshd shuts down with "No supported key exchange algorithms" error

Question

sshd

$ /usr/sbin/sshd -f testconfig -p 22025 -d

debug1: sshd version OpenSSH_5.2p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-f'
debug1: rexec_argv[2]='testconfig'
debug1: rexec_argv[3]='-p'
debug1: rexec_argv[4]='22025'
debug1: rexec_argv[5]='-d'
debug1: Bind to port 22025 on 127.0.0.1.
Server listening on 127.0.0.1 port 22025.
Generating 1024 bit RSA key.
RSA key generation complete.
debug1: fd 4 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 58477
debug1: Client protocol version 2.0; client software version OpenSSH_5.5
debug1: match: OpenSSH_5.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: privsep_preauth: successfully loaded Seatbelt profile for unprivileged child
debug1: list_hostkey_types: 
No supported key exchange algorithms
debug1: do_cleanup
debug1: do_cleanup
debug1: audit_event: unhandled event 12

ssh

$ ssh dgl@127.0.0.1 -p 22025 -i ./id_rsa.pub -v
OpenSSH_5.5p1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /Users/dgl/.ssh/config
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22025.
debug1: Connection established.
debug1: identity file ./id_rsa.pub type 1
debug1: identity file ./id_rsa.pub-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 127.0.0.1

ssh_config

Protocol 1,2
ListenAddress 127.0.0.1
HostKey ./ssh_host_key
HostKey ./ssh_host_rsa_key
HostKey ./ssh_host_dsa_key
RSAAuthentication yes
PubkeyAuthentication yes

What is the contant of testconfig? Hostkey and such do not belong into ssh_config. — ott--, Oct 11 '11 at 17:48
I forgot to use sudo when starting it with -d, gave me the same error... — Jim W, Apr 13 '17 at 19:43

John Elliot V · Answer 1 · 2015-06-29T20:31:33.633

18

I ran into this problem on Fedora. Eventually I noticed:

root@wisdom:/etc/ssh# ll
total 268K
drwxr-xr-x.   2 root root     4.0K Jun 30 06:06 ./
drwxr-xr-x. 128 root root      12K Jun 30 05:15 ../
-rw-r--r--.   1 root root     237K Jun  8 23:30 moduli
-rw-r--r--.   1 root root     2.2K Jun  8 23:30 ssh_config
-rw-------.   1 root root     4.3K Jun 30 06:03 sshd_config
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_ecdsa_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_ecdsa_key.pub
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_ed25519_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_ed25519_key.pub
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_rsa_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_rsa_key.pub

The key files are zero length! I generated new key pairs and it fixed the problem:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

edited Jun 29 '15 at 20:31

answered Jun 29 '15 at 20:26

John Elliot V

333
2
10

Thanks, this worked for me. I experienced the same on a CentOS 7.1 minimal installation. – Torsten Aug 07 '15 at 17:34
Got exactly the same thing on a minimal Fedora 22 installation. Thanks for the hint. – Lefteris Jan 19 '16 at 22:08
Perhaps it goes without saying, but you'll get this if the keys are invalid in any way (e.g. you have a public key in a private key filename) – MatrixManAtYrService Mar 29 '18 at 15:10
worked for me as well on a fresh Ubuntu server 18.04.1 – godzillante Sep 19 '18 at 21:17
This helped on newly installed raspberry pi zero with rasbian-stretch-lite image. Thanks! – J-ho Jan 18 '19 at 16:42

score 6 · Accepted Answer · answered Feb 17 '11 at 02:06

6

I just hit the same issue, solved it by turning my relative HostKey path into an absolute one, i.e. instead of

HostKey ./ssh_host_key

put:

HostKey /home/dmitry/ssh_host_key

or wherever it is.

That error isn't very helpful is it?

answered Feb 17 '11 at 02:06

Matthew Bloch

1,074
8
11

score 4 · Answer 3 · answered Oct 11 '11 at 17:32

FWIW, I just ran into the same error message, but with a different cause. In my case the problem turned out to be that my host private key files were mode 640 instead of 600. A quick chmod and sshd restart solved the problem. I guess the common theme here is sshd not loading the host keys for one reason or another.

score 3 · Answer 4 · answered Feb 19 '12 at 20:12

3

I've just had this issue hacking around with cloud-init. In my case, the cause was that the host keys had not been generated, and dpkg-reconfigure openssh-server (Debian/Ubuntu -specific) fixed it.

answered Feb 19 '12 at 20:12

Robie Basak

201
2
2

I was getting the same issue with host keys being stripped by `virt-sysprep` - Since my guests are debian based I added the command line option `--firstboot-command "dpkg-reconfigure openssh-server"` – marsbard Nov 18 '16 at 15:50

score 2 · Answer 5 · edited Aug 09 '13 at 14:34

2

I actually ran into this problem...and it was our good old friend SELinux.

Running setenforce 0 proves that it worked but this isn't a good solution. However, as soon as that helped to make the ultimate solution more clear.

$ cd /etc/ssh
$ restorecon -Rv *

Re-enabling SELinux (setenforce 1) ... and all is well.

edited Aug 09 '13 at 14:34

slm

7,615
16
56
76

answered Aug 09 '13 at 11:14

Mark Waterhouse

31
1

score 1 · Answer 6 · answered Mar 07 '13 at 20:43

1

I ran into this error message and solved it by setting:

UsePAM yes

It only happened with passwordless accounts (like root).

answered Mar 07 '13 at 20:43

jippie

163
8

score 0 · Answer 7 · answered Aug 22 '16 at 18:13

To me what fixed was to add this lines do /etc/ssh/sshd_config:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192
-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

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-group-exch
ange-sha1,diffie-hellman-group1-sha1

HostkeyAlgorithms +ssh-dss

score 0 · Answer 8 · answered Sep 18 '16 at 02:37

In my case, the issue was an over-enthusiastic apparmor profile.

I was also receiving the following message in my /var/log/auth.log file:

fatal: linux_audit_write_entry failed: Permission denied

Resolved by running:

aa-complain /etc/apparmor.d/usr.sbin.sshd

Petras L · Answer 9 · 2019-08-08T10:46:00.383

0

In my scenario it was wrong permissions for private keys:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0444 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
Could not load host key: /etc/ssh/ssh_host_rsa_key

edited Aug 08 '19 at 10:46

answered Jun 05 '19 at 12:02

Petras L

1
1

This answer has already been given 8 years ago. – Gerald Schneider Jun 05 '19 at 13:58

score -1 · Answer 10 · answered Feb 12 '18 at 16:51

-1

I wasted 6 hours on this! I tried all of the solutions here plus so many more! to no avail! then purged openssh-server and reinstalled it and it worked great and I reconfigured everything which took about 15 minutes! And I learned a great lesson!

Never waste your time on debugging something that you can get back to work be resetting it!

There is no gain in dealing with every bit of every config file and debug info of every application!

answered Feb 12 '18 at 16:51

yukashima huksay

111
8

But what if resetting didn't solve your issue? Perhaps you could've tried to reset at the beginning, or tried setting this up on another new box. – oxr463 Jun 05 '19 at 15:30

sshd shuts down with "No supported key exchange algorithms" error

10 Answers10

Never waste your time on debugging something that you can get back to work be resetting it!