We currently implement the StrictHostKeyChecking=no in a user account's ~/.ssh/config file, to ensure that automated backups aren't affected by a change of the ssh host key across cisco switches & firewalls, and netscaler load balancers. Recently one of these devices had its SSH host key change. The ssh client connecting to it (ubuntu 18.04, running openssh 7.6p1) failed to automatically accept and store the new key, preventing the backup from working. My investigation has identified that the ssh client would fail to automatically accept and store a changed SSH host key when it is of type 2048bits RSA, but will successfully accept and store a changed host key if it is of type 1024bits RSA. I have recreated this problem using a CentOS 7.6 server running openssh 7.4p1, acting as the SSH server, and a Ubuntu 18.04 server running openssh 7.6p1. Testing first with a 1024 bit RSA host key on the SSH server, I do an initial connection from my SSH client and accept the new key. I then made a single character change to the key stored in the ssh client's known hosts file and repeated the ssh connection. It successfully accepted the modified key and stored it. I then repeated the test but with a 2048 bit RSA host key on the SSH server, but after modifying the key, the second connection failed to accept and store the host key. I have had the same results when using the "-o StrictHostKeyChecking=no" on the command line, rather than relying on the ~/.ssh/config file.
Could you please attach a debug trace ("ssh -vvv ...") from a client experiencing this problem?
Created attachment 3352 [details] SSH debug connection output as requested The debug output (ssh -vvv….) if from a ubuntu ssh client, connecting to a CentOS ssh server. For this capture, the SSH server has a 2048bit RSA host key. The client started with an empty known_hosts file, and made a first connection. It accepted and stored the SSH servers host key. I then modified the stored key in the clients known hosts file, and repeated the SSH connection , this time with the "-vvv" option . The connection failed with a warning about a MITM attack, i.e. despite the "StrictHostKeyChecking=no" set in the config file it did NOT accept the changed key. However, if I repeat this test with a 1024bit RSA key on the SSH server and no MITM attack is reported Regards, Andy
This is the intended behaviour. StrictHostKeyChecking controls whether ssh accepts a *new* hostkey automatically. It is not intended to disable host key checking entirely. I'd generally recommend against doing that, because an on-path attacker can trivially MITM your connections. If you really want to do this, then the easiest way is to pass "-oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no" to ssh.
closing resolved bugs as of 8.6p1 release