☰

¿Cuál es la clave de host (la de la conexión ssh) y en qué se diferencia del par de claves pública-privada?

tag-icon • tag-icon ssh ssh-keys ssh-agent ssh-keygen known-hosts
¿Cuál es la clave de host (la de la conexión ssh) y en qué se diferencia del par de claves pública-privada?

La situación es que ya tengo un VPS creado anteriormente. Estaba todo configurado, autenticación de clave pública-privada, inicio de sesión de root desactivado, inicio de sesión con contraseña desactivado. Todo estaba preparado.

Luego, este servidor se destruye y se crea un nuevo servidor.

Así que estoy usando ssh -v root@new_server_ip_numberpara iniciar sesión en esta instancia de Linux recién instalada y esto es lo que obtengo:

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.

¿Qué es esta SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.línea? ¿Qué significa?
Porque claramente este SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.número/id no es el mismo número que identifica al servidor linux en mi Windowsknown_hosts archivo de Windows.

Estoy usando una computadora portátil con Windows y PowerShell para iniciar sesión en este servidor.
Hay un C:\Users\roeslermichal\.ssh\known_hostsarchivo en esta máquina con Windows y esperaba que algunas ID no coincidieran, porque el servidor antiguo se destruyó y se creó el nuevo. Ya eliminé la 10.32.81.216 ssh-rsaclave y la reemplacé con esta 10.32.81.216 ssh-rsaclave del servidor Linux recién instalado.
Pero el cliente ssh no me deja entrar.
Así es como :\Users\roeslermichal\.ssh\known_hostsse ve mi archivo actual:

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=

Pero realmente no sé cuáles son esas claves de host, porque no he creado ninguna clave en este nuevo servidor Linux. El inicio de sesión como root fue la primera acción que realicé con respecto a este servidor Linux recién creado. Y ya hay algunos host_keysen este servidor.??? Y estas no son claves ssh públicas y privadas, porque aún no las he creado, entonces, ¿cuáles son esas claves que se generaron e identifican mi nuevo servidor Linux en Windows?known_hosts archivo de Windows?

he leídoeste hilocuidadosamente algunas veces, pero no entiendo del todo las respuestas que se dan allí y por qué funcionan. Aún más, no entiendo por qué no puedo iniciar sesión en mi servidor Linux recién creado, aunque reemplacé la antigua clave de host del servidor rsa con una nueva clave de host del servidor 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=

Aunque no he sustituido la llave 10.32.81.216 ssh-ed25519ni 10.32.81.216 ecdsa-sha2-nistp256. ¿Puede ser esta la razón por la que no puedo iniciar sesión?

Respuesta1

Hay una autenticación mutua en SSH.

Primero elclienteautentica que el servidor es efectivamente el que quería conectarse. Para ello, recuerda la parte pública del par de claves del host en el ~/.ssh/known_hostsarchivo. Lo aprende durante la primera conexión (esta es exactamente la parte donde le pide que escriba "sí"), o puede aprender del DNS si contiene el registro SSHFP para el host y la zona está protegida por DNSSEC. Si el cliente descubre que el servidor presenta la clave incorrecta, normalmente se negará a conectarse alegando un ataque MitM en curso.

Para esto sirve el par de claves de host SSH. En términos generales, es la versión SSH de la infraestructura PKI, aunque no está basada en CA (o utiliza DNSSEC para implementar una cadena de confianza similar a una CA); es como un certificado HTTPS/par de claves (con el propósito de "autenticación del servidor web") y tiene el mismo propósito. Élesel par de claves asimétricas ("pública-privada") que pertenece a un servidor.

En segundo lugar, elservidorautentica que el cliente es realmente quien dice ser. Para eso, puede usar un par de nombre de usuario/contraseña o cualquier autenticación compleja basada en chat, o el par de claves asimétricas almacenadas en el servidor en usuarios ~/.ssh/authorized_keys. Esta vez, el par de claves pertenece a un usuario. Nuevamente, la PKI tradicional basada en CA tiene certificados de cliente "analógicos" (con el propósito de "autenticación de cliente web").

Bueno, ¿ves esta línea en tu salida Someone could be eavesdropping on you right now (man-in-the-middle attack)!? Así informa sobre el ataque MitM que pretendía prevenir. Probablemente sea demasiado cauteloso, pero esta es tu seguridad.

Si eresabsolutamente segurono hay ningún ataque y la nueva huella digital es la correcta, simplemente elimine la línea ofensiva del archivo conocido_hosts de su cliente. Puedes seguir el
consejo de @JaromandaX en el comentario o puedes eliminar todos los registros ofensivos con algo como

ssh-keygen -R 10.32.81.216

Luego tendrás que aceptar escribiendo literalmente "sí" a la pregunta sobre si estás seguro o usando una ssh-keyscanutilidad como se describe.en la otra respuesta. Tenga en cuenta que, si bien esta forma de crear el archivo evita la advertencia interactiva sobre MitM,todavía es susceptible al ataquepor la misma razón, que también se indica en la página del manual de ssh-keyscan (y también se menciona muchas veces en los comentarios a las respuestas debajo del enlace).

información relacionada