Namaste misc, Overview: In -current (#625), the ssh client is asking the user to accept updated server host keys after every successful connection. No host keys have actually been updated at the server side.
Setup: Consider a server (-current #625) which uses host certificates. The server's ed25519 host public key is signed by a host certificate authority. Consider a client (-current #625) which is configured to use only ed25519-cert and ed25519 HostKeyAlgorithms. In its known hosts file, the client has @cert-authority <server> ssh-ed25519 <host_ca_public_key> <server> ssh-ed25519 <server_ed25519_host_public_key>. Bug: When the client connects to the server, they use the ed25519-cert to establish the connection. After the ssh session is established, the server sends the "hostkeys...@openssh.com" message with the server's ed25519 host public key. This results in the client looping over the keys in known hosts file, and deciding that the @cert-authority host certificate authority public key is "deprecated", because it was not sent by the server [1]. The client then informs the user: " The server has updated its host keys. These changes were verified by the server's existing trusted key. Deprecating obsolete hostkey: ED25519 SHA256:<host_ca_public_key_fingerprint> Accept updated hostkeys? (yes/no): " In reality, no host key has been added/removed on the server. Repeat. No host key has been added/removed on the server. Now, even when the user types yes in response to the above prompt, the user is presented with this prompt again after the next successful login. This is because when the user types yes, there is a check in the host_delete function in src/usr.bin/ssh/hostfile.c, which prevents the @cert-authority keys from being deleted [2]. goto Bug: after every successful login. And if I am not wrong, this "ask" happened due to the recent changes in the default setting of UpdateHostKeys option [3][4]. (It is only when users are repeatedly prompted with the same question by ssh, some get annoyed, few irritated, one complains. And because we had not changed any keys, and updated everyone+dog to the recent -current because of the smtpd CVE, it set alarm bells ringing so as to whether "someone" had actually changed the keys.) Dhanyavaad, ab [1] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c?rev=1.338&content-type=text/x-cvsweb-markup [2] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/hostfile.c?rev=1.77&content-type=text/x-cvsweb-markup [3] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.322&r2=1.323&f=h [4] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.323&r2=1.324&f=h ---------|---------|---------|---------|---------|---------|---------|--
