Comments
Но если вы уже аутентифицировали этот узел и подключались к нему прежде, то стоит задуматься: «Почему произошло изменение отпечатка?».

возможно, зависит от настроек, но по умолчанию SSH не подключается к узлам с изменившимся ключом, а сообщает об этом и предлагает всё проверить и предварительно удалить запись из файла known_hosts
да, можно настроить, чтоб не пускало. но для людей, которые даже пароли не меняют в готовых билдах-сборках, сменить настройки ссш — это из ряда фантастики
не-не, Вы меня не поняли
SSH по-умолчанию не пускает на узлы с изменившимся ключом (в контексте Вашего «если вы уже аутентифицировали этот узел и подключались к нему прежде»)
поэтому (при повторном подключении) процитированного сообщения уже не будет, будет другое:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for HOST has changed,
and the key for the corresponding IP address IPADDR
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/USER/.ssh/known_hosts:63
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:jYIS2egEyMoVveHLlR0......
Please contact your system administrator.
Add correct host key in /home/USER/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/USER/.ssh/known_hosts:48
ECDSA host key for HOST has changed and you have requested strict checking.
Host key verification failed.
«SSH по-умолчанию» это вы о каком клиенте?
На OpenSSH свет клином не сошелся. Тот же Putty, подозреваю, используется не менее часто.
Да и ssh_config в разных дистрибутивах никто не обязывает быть одинаковым, строго говоря.
давайте будем последовательны
Вы в статье цитируете сообщение
The authenticity of host '192.168.100.124 (192.168.100.124)' can't be established.
RSA key fingerprint is 56:ca:17:72:0b:d4:3c:fd:5e:23:fb:7b:9e:9a:c8:42.
Are you sure you want to continue connecting (yes/no)?

как раз OpenSSH, насколько я могу судить (+ судя по цитатам, из Ubuntu, в которой по умолчанию стоит OpenSSH)

а что касается Putty/Kitty: тот также «кричит» о потенциальной угрозе
---------------------------
KiTTY Security Alert
---------------------------
WARNING - POTENTIAL SECURITY BREACH!

The server's host key does not match the one KiTTY has
cached in the registry. This means that either the
server administrator has changed the host key, or you
have actually connected to another computer pretending
to be the server.
The new rsa2 key fingerprint is:
ssh-rsa 2048 b8:49:6d:1c:6b:55:5f:03:15:3c:92:a2:30:74:45:3d
If you were expecting this change and trust the new key,
hit Yes to update KiTTY's cache and continue connecting.
If you want to carry on connecting but without updating
the cache, hit No.
If you want to abandon the connection completely, hit
Cancel. Hitting Cancel is the ONLY guaranteed safe
choice.



что же до ssh_config, то строго говоря, Вы, конечно, правы: «ничто не обязывает»,

Но покажите мне дистрибутив, в котором
StrictHostKeyChecking=no

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 trojan horse 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 “no”, ssh will automatically add new host keys to the user known hosts files. If this flag is set to “ask”, 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. The argument must be “yes”, “no”, or “ask”. The default is “ask”.


к тому же Вы сами сказали:
но для людей, которые даже пароли не меняют в готовых билдах-сборках, сменить настройки ссш — это из ряда фантастики

давайте будем последовательны
Вы в статье цитируете сообщение
Вы меня с кем-то путаете, статья не моя.
Проблема, описываемая в статье не связана с конкретным SSH-клиентом. Какой-то из них должен был быть приведен для примера.

а что касается Putty/Kitty: тот также «кричит» о потенциальной угрозе
естественно кричит, но вместо correct host key in /home/USER/.ssh/known_hosts предлагает просто нажать кнопку «пофиг, пляшем». Знание человеческой натуры подсказывает, что большая часть пользователей нажмет ее до того, как обдумает текст предупреждения.
Вы меня с кем-то путаете, статья не моя.

опс, простите ))) что-то я забылся ))))
Во-первых, нельзя «подменить ключ». Воплей будет очень много. Можно только «прикинуться новым сервером».

Во-вторых, компрометация произойдёт только в случае использования парольной авторизации. При том, что все давно на ssh-ключах.

В третьих — да, свинство и непорядок. Обычно возникает из-за халтуры админов хостингов, которые не хотят в image'е инициализировать ключи для каждого нового инстанса.

Может я придираюсь, но интересно посмотреть статистику по таким коллизиям не в свете md5, а прямо по самим ключам. Изменится ли картина?


И второе — неплохо бы научиться различать два сервера с одним ключом и один сервер с двумя адресами (который слушает ssh на всех них) — в этом случае всё так же страшно или всё же паника в исследовании преувеличена.


P.S. У меня Shodan ключа нет, поэтому только идеи подкидываю.

Only those users with full accounts are able to leave comments. Log in, please.