Upgraded to 14.3 and unable to connect via ssh.

[byrnejb]

I upgraded a host system to 14.3 and it completed fine. No problems whatsoever. Well, other than it was a remote system and immediately following the second freebsd-update install the ssh session dropped and could not be re-established. Running ssh -vv revealed this:

debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug2: local client KEXINIT proposal 
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,. . .
. . .
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,. . .
. . .
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com 
debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none 
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Connection closed by 192.168.216.45 port 22

So the issue is sntrup761x25519-sha512. Given that the TCP connection succeeded and that the sshd daemon is obviously running on the upgraded host I tried this:

ssh -vv -oKexAlgorithms=curve25519-sha256 192.168.216.45

which worked.

This takes a lot less time to write in the morning after the fact than it did to experience finding out the facts late at night. What is going on? Is this a bug in sshd? Why did not the key exchange fallback on the remaining keys types rather than the server simply dropping the connection? This is a booby trap for people that have to maintain remote server hosts.

I would rather avoid having to configure .ssh/config for each of the hosts I plan to upgrade, but remembering to add
-oKexAlgorithms=curve25519-sha256 to ssh whenever I connect to a 14.3 host is a PITA and should not be necessary.

 

[VladiBG]

I never experience this after upgrading to FreeBSD-14.3R. Maybe check your ssh client or check your default sshd config.
Here how it looks from W11 ssh client to FreeBSD-14.3R

debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:*********

 

[mer]

That message/error is the server saying "this is what I expect, this is what you gave me". Recently (past year or so) some algorithms have been deprecated in OpenSSH. This is a good thing, because security.

Now it sounds like you were upgrading the "server" side, so it wound up with newer preferences and your client may have been trying to use deprecated algorithms.

Problem becomes when you ssh to an older server because server expects something deprecated.
Older server may not have support for the newer algorithms or they are lower in the preference list; it's a pain, but the best thing (my opinion) is to configure your client side .ssh/config to explicitly pass the server supported pieces.

This may also show up on an scp command: there was a change in "how" the scp took place. The error message shows up on the client side as roughly "far side closed connection". If you see this try adding the "-O" (that's a dash capital letter O) to the scp command.