1

Here is the execution:

$ ssh -o StrictHostKeyChecking=no root@10.1.1.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ECDSA key sent by the remote host is
SHA256:2ypJ7ea5D0iqFy5PzHVgHV7p6jX5ONSTGXZGf9KqF6A.
Please contact your system administrator.
Add correct host key in /home/peng/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/peng/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f "/home/peng/.ssh/known_hosts" -R "10.1.1.1"
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
UpdateHostkeys is disabled because the host key is not trusted.
root@10.1.1.1: Permission denied (publickey,password,keyboard-interactive).

Why is ssh ignoring my option?

tribbloid
  • 131
  • 2
    You've provided no OS/release details; but root is a disabled account thus inability to login using root@ on a Ubuntu system is expected ! – guiverc Apr 05 '23 at 05:51

1 Answers1

2

If you look closely at your output the host key mismatch does not stop the connection. However, because of the possible man-in-the-middle attack there are authentication types that get disabled and the login fails (root@10.1.1.1: Permission denied ...).

Typically, you will see StrictHostKeyChecking=no combined with something like UserKnownHostsFile=/dev/null. Try

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@10.1.1.1
Andrew Lowther
  • 7,286