☰

Что такое ключ хоста (тот, что используется в соединении SSH) и чем он отличается от пары открытого и закрытого ключей?

tag-icon • tag-icon ssh ssh-keys ssh-agent ssh-keygen known-hosts
Что такое ключ хоста (тот, что используется в соединении SSH) и чем он отличается от пары открытого и закрытого ключей?

Ситуация такова, что у меня был создан VPS ранее. Все было настроено, аутентификация по закрытому-открытому ключу, вход root отключен, вход по паролю отключен. Все было настроено.

Затем этот сервер уничтожается и создается новый сервер.

Итак, я использую его ssh -v root@new_server_ip_numberдля входа в этот недавно установленный экземпляр Linux и вот что я получаю:

PS C:\Users\roeslermichal> ssh -v [email protected]
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Reading configuration data C:\\Users\\roeslermichal/.ssh/config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 10.32.81.216 [10.32.81.216] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa_sk type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519_sk type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519_sk-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.32.81.216:22 as 'root'
debug1: load_hostkeys: fopen C:\\Users\\roeslermichal/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk
debug1: load_hostkeys: fopen C:\\Users\\roeslermichal/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ED25519 key sent by the remote host is
SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.
Please contact your system administrator.
Add correct host key in C:\\Users\\roeslermichal/.ssh/known_hosts to get rid of this message.
Offending RSA key in C:\\Users\\roeslermichal/.ssh/known_hosts:15
Host key for 10.32.81.216 has changed and you have requested strict checking.
Host key verification failed.

Что это за SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.строка? Что она означает?
Потому что очевидно, что этот SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.номер/идентификатор не тот же самый номер, который идентифицирует сервер Linux в моем known_hostsфайле Windows.

Я использую ноутбук Windows и PowerShell для входа на этот сервер. На этой машине Windows
есть C:\Users\roeslermichal\.ssh\known_hostsфайл, и я ожидал, что некоторые идентификаторы не совпадут, потому что старый сервер был уничтожен, а новый был создан. Я уже удалил ключ 10.32.81.216 ssh-rsaи заменил его этим 10.32.81.216 ssh-rsaключом недавно установленного сервера Linux.
Но ssh-клиент не пускает меня.
Вот как :\Users\roeslermichal\.ssh\known_hostsвыглядит мой текущий файл:

10.32.81.216 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGh8fEmrCov7TLbiKgGasUV3fxbrKmh4Ai/RWixt41Fl
10.32.81.216 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCr43mfkweJAaHQ4kw88b0y5OShnQl91jR1eoUIcnaMRvBEi3X7McVuA+cB+MWk4Rj9EX2hnq6tyB+26weQX0GXWf95CL/yqX5p39b+j8c43CR9/3gHbU5aV+exGBbj2rEL4JgmQD58fHHEsL1r6EMcpTUgY8JqfG0F52XUJrF7KdpxlW4vtgOaHdqooBMHuMi+bR7LRq/moAHLv3svB5PPhIfSbM5CW/Eke4H4qiAwKCVUjyXxKCoKkYVDyfQur+nBMxJssUHy03385hxV0gKo8WGQKlSNvI3B1vP85ij5zCYViYUfs05lXPkpsUqosGqHDOJhPnVRM4OacMQVkj2e0MKHs/cXA1GneBiY99tPMaEL2qZ0UJoaYcnG0krc0owKE6Ufx+84VVqLG7hJHPnNRI3UrFjG/C7lAzAogz5eDiYoQvkko7mLuwRob27fIB39oH2cbH4a4DCcIDekS0WwCPeA+uwaHrmhKJluqP8r7qvDluWax3cVzDGojD7I6cU=
10.32.81.216 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCMktfR/tBD8GYWRWpo8DsoIPPxos+Rt/C1Is04S0Dglm6UbQqQQUW9m9GfDWHZn3j37ZWPGeUwTcWEojKi70yk=

10.32.81.218 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFBuju3Gav0s6Uj8XFQToa/qU7gxsxvKqtUCctWaC4FC
10.32.81.218 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC6OCnBNeCfiLcYo7FAmopNBxWS5No+Locw+dxujELxhXn/zAEEnsMv+fZYP8JT8Jj+bYFX1jVAxBubqaz7swK3GCYkkL4C/dI2p7MV0E0ogznbZEZS0GHU3wA69R7s4F56oR3ZeCIas+gfe3mckB4i9UtZMy2IsGSVl974wletCXfdXxhkyRzHlgovoCnAYu9qOS/X2X2yuUNKKfL3VGQNkAih/Hjqh7Iwi36sLS8+WB/sYOk5cxJfycWewTEl1Wt5fB5bbc7Fu0Wmjn2IpMHspoR6YEw2lK/GuFIFjcVoHJ8+7JAuY9BnUdyuAbHLZ8vgrymcGw/ZP8GIhgRq1nOseAQrOzZMFtcGCS953a+L5gP9shX2ZwF/MS7h8+EYPxMNFZP6DbU++c4ZmOlb0lPkUJDhTnSbOoDZA+bfDl5jBlKtfF2V7n+V9Dwuwwbsp/qJyULIeMAdCrpjPhmKhnQASloZsEN5LLjh2gVN+YM7jACHe6ZyFD4/gpEE6N6MUG8=
10.32.81.218 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBonnCuOeQpc7CSRzbps8sLnPYMphNrfqs9h7Hz5I+Ml8QxPBUnlNw749EzqC29KFtyB8XE2SnbOK/CuUnghj5E=

Но я на самом деле не знаю, что это за ключи хоста, потому что я не создал никаких ключей на этом новом сервере Linux. Подход к входу в систему как root был первым действием, которое я предпринял в отношении этого недавно созданного сервера Linux. И host_keysна этом сервере уже есть некоторые.??? И это не закрытые-открытые ключи ssh, потому что я их еще не создал, так что это за ключи, которые были сгенерированы и идентифицируют мой новый сервер Linux в файле Windows known_hosts.

я прочелэта темавнимательно несколько раз, но не совсем понимаю ответы, данные там, и почему они работают. Еще больше я не понимаю, почему я не могу войти в свой недавно созданный сервер linux, хотя я заменил старый ключ хоста rsa сервера на новый ключ хоста rsa сервера.

PS C:\Users\roeslermichal> ssh-keyscan -t rsa 10.32.81.216
# 10.32.81.216:22 SSH-2.0-OpenSSH_8.0
10.32.81.216 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCr43mfkweJAaHQ4kw88b0y5OShnQl91jR1eoUIcnaMRvBEi3X7McVuA+cB+MWk4Rj9EX2hnq6tyB+26weQX0GXWf95CL/yqX5p39b+j8c43CR9/3gHbU5aV+exGBbj2rEL4JgmQD58fHHEsL1r6EMcpTUgY8JqfG0F52XUJrF7KdpxlW4vtgOaHdqooBMHuMi+bR7LRq/moAHLv3svB5PPhIfSbM5CW/Eke4H4qiAwKCVUjyXxKCoKkYVDyfQur+nBMxJssUHy03385hxV0gKo8WGQKlSNvI3B1vP85ij5zCYViYUfs05lXPkpsUqosGqHDOJhPnVRM4OacMQVkj2e0MKHs/cXA1GneBiY99tPMaEL2qZ0UJoaYcnG0krc0owKE6Ufx+84VVqLG7hJHPnNRI3UrFjG/C7lAzAogz5eDiYoQvkko7mLuwRob27fIB39oH2cbH4a4DCcIDekS0WwCPeA+uwaHrmhKJluqP8r7qvDluWax3cVzDGojD7I6cU=

Хотя я не заменил ключ 10.32.81.216 ssh-ed25519nor 10.32.81.216 ecdsa-sha2-nistp256. Может ли это быть причиной того, что я не могу войти?

решение1

В SSH есть взаимная аутентификация.

Во-первых,клиентаутентифицирует сервер, который действительно тот, к которому он хотел подключиться. Для этого он запоминает публичную часть пары ключей хоста в файле ~/.ssh/known_hosts. Он узнает об этом либо во время первого подключения (это как раз та часть, где он просит вас ввести «да»), либо может узнать из DNS, содержит ли он запись SSHFP для хоста и защищена ли зона DNSSEC. Если клиент обнаруживает, что сервер представляет неправильный ключ, он обычно отказывается подключаться, заявляя о продолжающейся атаке MitM.

Вот для чего нужна пара ключей хоста SSH. Грубо говоря, это версия SSH инфраструктуры PKI, хотя и не на основе CA (или она использует DNSSEC для реализации цепочки доверия, подобной CA); это похоже на пару сертификат/ключ HTTPS (с целью «аутентификация веб-сервера») и служит той же цели. Этоявляетсяасимметричная пара ключей («открытый-закрытый»), принадлежащая серверу.

Во-вторых,сервераутентифицирует клиента, который действительно тот, за кого себя выдает. Для этого он может использовать пару имя пользователя/пароль или любую сложную аутентификацию на основе чата, или асимметричную пару ключей, хранящуюся на сервере в users ~/.ssh/authorized_keys. На этот раз пара ключей принадлежит пользователю. Опять же, традиционный PKI на основе CA имеет «аналог», клиентские сертификаты (с целью «аутентификация веб-клиента»).

Ну, вы видите эту строку в вашем выводе, Someone could be eavesdropping on you right now (man-in-the-middle attack)!? Вот как он сообщает об атаке MitM, которую он призван предотвратить. Возможно, он слишком осторожен, но это ваша безопасность.

Если выабсолютно увереннет никакой атаки и новый отпечаток правильный, просто удалите оскорбительную строку из файла known_hosts вашего клиента. Вы можете следовать
совету @JaromandaX в комментарии или вы можете удалить все оскорбительные записи чем-то вроде

ssh-keygen -R 10.32.81.216

Затем вам придется согласиться, набрав буквальное «да» на вопрос о том, уверены ли вы, или используя утилиту, ssh-keyscanкак описанов другом ответе. Обратите внимание, что хотя этот способ создания файла позволяет избежать интерактивного предупреждения о MitM,он все еще подвержен атакепо той же причине, которая также отмечена на странице руководства ssh-keyscan (а также многократно упомянута в комментариях к ответам по ссылке).

Связанный контент