Недавно, через некоторое время, я попытался войти на свой сервер SSH в локальной сети, и я получил это предупреждение:

$ ssh user@local.server.hostname
Warning: Permanently added the RSA host key for IP address '192.168.1.4' to the list of known hosts.

Я посмотрел следующий пост на SO: https://stackoverflow.com/questions/9299651/warning-permanently-added-to-the-list-of-known-hosts-message-from-git Но я не Не думаю, что это связано с тем, что клиент ssh не проверяет файл known_hosts (я полагаю, в моем случае это проверяется, и я не работаю с Windows).

Вот файл known_hosts , и я обнаружил, что у меня есть две строки одного и того же открытого ключа, но с разными именами хостов /IP:

$ cat ~/.ssh/known_hosts
local.server.hostname,192.168.1.3 ssh-rsa ...Here it goes the public key...
192.168.1.4 ssh-rsa ...Here it goes the same public key (as for the local.server.hostname,192.168.1.3 entry above)...

Я уверен, что два открытых ключа равны (я проверил отпечаток обоих с помощью команды echo "here I pasted the public key" | base64 -D | md5 , который я запускал для каждой записи known_hosts). В противном случае я бы увидел «ПРЕДУПРЕЖДЕНИЕ: УДАЛЕННАЯ ИДЕНТИФИКАЦИЯ ХОЗЯЙКА ИЗМЕНИЛАСЬ».

Теперь у меня есть локальная сеть с DHCP, поэтому серверу присваивается IP, а иногда ему может быть назначен другой.

Я предполагаю, что это основная причина, по которой у меня появилось это предупреждение: IP-адрес сервера изменился (с 192.168.1.3, первая строка known_hosts, на 192.168.1.4), но так как открытый ключ остался прежним, и открытый ключ уже был доверен моим Клиент ssh, так как уже была запись для local.server.hostname,192.168.1.3 в known_hosts , клиент ssh показал мне предупреждение, но добавил запись для 192.168.1.4 без запроса подтверждения.

Это верно? Единственное, что приходит на ум: почему тогда клиент добавил еще одну запись вместо того, чтобы просто изменить уже существующую, например, следующим образом:

local.server.hostname,192.168.1.3,192.168.1.4 ssh-rsa ...public key...

Почему две записи для одного и того же открытого ключа?

1 ответ1

2

Действительно, причина в том, что ваша среда DHCP присвоила вашему серверу новый IP-адрес.

Всякий раз, когда ssh подключается к IP-адресу, которого нет в его файле known_hosts он реагирует в соответствии с вашей конфигурацией StrictHostKeyChecking , смотрите man 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 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 con-
         firmed 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 не пытается сопоставить / обновить какие-либо известные ключи с новым IP-адресом (что, вероятно, будет рассматриваться как угроза безопасности). Отсюда разные строки, соответствующие разным IP-адресам одному и тому же ключу хоста.

Если DHCP-сервер теперь назначит старый адрес другому серверу, и вы попытаетесь подключиться к нему по ssh, он, скорее всего, будет иметь другой ключ хоста, и в ssh-соединении будет отказано. Чтобы избежать таких случаев, вы можете проверить, можете ли вы переключаться на статически назначенные IP-адреса (некоторые DHCP-серверы сами поддерживают статические сопоставления без изменений на клиентах).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .