What are the restrictions to ssh StrictHostKeyChecking=no?

Question

When running ssh with StrictHostKeyChecking=no, it should always accept CHANGED keys. However it does not in my case. This is documented in the man page (ssh-config):

 StrictHostKeyChecking
         If this flag is set to yes, ssh(1) will never automatically
         add host keys to the ~/.ssh/known_hosts file, and refuses
         to connect to hosts whose host key has changed.  This
         provides maximum protection against man-in-the-middle
         (MITM) attacks, though it can be annoying when the
         /etc/ssh/ssh_known_hosts file is poorly maintained or when
         connections to new hosts are frequently made.  This option
         forces the user to manually add all new hosts.

         If this flag is set to “accept-new” then ssh will
         automatically add new host keys to the user's known_hosts
         file, but will not permit connections to hosts with changed
         host keys.  If this flag is set to “no” or “off”, ssh will
         automatically add new host keys to the user known hosts
         files and allow connections to hosts with changed hostkeys
         to proceed, subject to some restrictions.  If this flag is
         set to ask (the default), new host keys will be added to
         the user known host files only after the user has confirmed
         that is what they really want to do, and ssh will refuse to
         connect to hosts whose host key has changed.  The host keys
         of known hosts will be verified automatically in all cases.

This section is relevant: If this flag is set to “no” or “off”, ssh will automatically add new host keys to the user known hosts files and allow connections to hosts with changed hostkeys to proceed, subject to some restrictions.

What are the mentioned restrictions?

Answer 1

I can only speak from experience. You won't be able to open a remote tunnel with the connection. This happens regardless of setting the ExitOnForwardFailure=no option, which when set to yes will terminate the connection immediately in this situation. So it appears that the SSH client still handles an offending known_host entry as an error.

If there are more restrictions, I can not tell.

Answer 2

Looking at the output of SSH in this case (see below), there seem to be at least three limitations:

1. Password/keyboard-interactive authentication is disabled. Key authentication is enabled as normal.
2. Port forwarding is disabled as mentioned by Destroy666.
3. Updating hostkeys in the known_hosts files (UpdateHostKeys config, normally used for key rotation by letting a server specifying multiple host keys) is disabled.

I've observed 1. and 2. in practice, have not looked at 3.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:key_here.
Please contact your system administrator.
Add correct host key in /home/nuttssh/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/nuttssh/.ssh/known_hosts:2
  remove with:
  ssh-keygen -f "/home/nuttssh/.ssh/known_hosts" -R "[hostname]:1878"
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Port forwarding is disabled to avoid man-in-the-middle attacks.
UpdateHostkeys is disabled because the host key is not trusted.