SSH es fácil de usar y generalmente no presenta problemas. Pero, hay este pequeño archivo en su directorio de inicio que puede convertirse en un punto de dolor raro para este protocolo y herramienta ubicuos. La entidad infractora es ~/.ssh/known_hosts expediente. Si no lo sabías, deberías familiarizarte ahora. Este archivo aparecerá en algún momento de su carrera.
Si alguna vez has visto el siguiente mensaje, puedes asustarte de que alguien esté intentando hackearte, o puedes darte cuenta de que DHCP o alguna otra anomalía ha hecho algo sucio y barato contigo:
$ ssh 192.168.1.84
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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:I02UyJs2vS0ym4jWn5upAWZDqwu5RjMg4aM9hPq8G1k.
Please contact your system administrator.
Add correct host key in /Users/khess/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/khess/.ssh/known_hosts:4
ECDSA host key for 192.168.1.84 has changed and you have requested strict checking.
Host key verification failed.
Lo que sucedió aquí es que intentó conectarse a un sistema que ya no tiene la dirección IP 192.168.1.84. Un sistema diferente tiene esa dirección IP y SSH se queja de que podría estar siendo pirateado. La realidad es a menudo mucho menos emocionante. Tus known_hosts Es posible que el archivo no se sincronice con la realidad real del host.
Múltiples cosas pueden causar este juego de sillas musicales con dirección IP. Uno de los sistemas podría haber estado inactivo durante un período de tiempo prolongado y, cuando finalizó el arrendamiento de otro, tomó la siguiente dirección IP disponible. Un evento de aplicación de parches y el posterior reinicio provocaron que algunos de sus sistemas adquirieran direcciones IP diferentes. El sistema podría haber sido reinstalado y generado una nueva identidad, o tal vez alguien se dio cuenta y le dio direcciones IP estáticas a sus sistemas de servidor. (Es mi opinión que todos los servidores deben tener direcciones IP estáticas. Lo mismo ocurre con cualquier componente de soporte, como enrutadores, conmutadores, puntos de acceso, dispositivos IoT, cámaras, sistemas de salas de conferencias e incluso impresoras. Solo los dispositivos de usuario final deben tener el dudoso privilegio de adquirir direcciones IP aleatorias. Tengo mis razones para esta fuerte opinión, que compartiré en otro artículo más adelante).
Independientemente de cómo sucedió, el sistema al que estaba interesado en conectarse tiene una nueva dirección IP. Uno que también es conocido por su sistema, pero con una huella digital diferente.
Los known_hosts antes mencionados es un archivo de texto simple que vive dentro de un directorio oculto (.ssh ) en su directorio de inicio. Para ver su contenido, ingrese el siguiente comando:
$ cat .ssh/known_hosts
192.168.1.97 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMJWpXf8Ou/XJ1Q5YcIS5Me4GgN1F7AYHbvIPayfGqwd90kvhQygrPCYEqVdw44lEOIZe+DEKP4F6Otdt38yf68=
192.168.1.101 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJRNTZm8M9IYYN3uJL/yCPv4EJRMDZkkcnt1CY8L6OR84wstYdhqtNqV0v/LQiz/AoRbHKxPTdjXfIOrc1vYDHc=
ken,192.168.1.69 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBB53lh2RyFiMfJFKBkLa643lS4GGILG6oVGq33KyBSgaDU2ZHryYak1FU1HcPa6Xb/xYqEUugv9cOXFRwajbrmg=
192.168.1.84 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMGjMsJPX4bfdEnVy59Uf2VhH1oAt7Zemd5bfSoSGxX69HBcjkekO/LkEZUlhVplBlHFqJBqs2gWYp3zVDCTwr4=
192.168.1.64 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIkK9WylcZcgjT7gUz9DMLehUBApION1CLiBVc3Pa/YfAbIDUlIWta12zL5B12RmBXgoYvntdW5rcowPiqjL0/o=
La solución fácil a este problema es eliminar los known_hosts y permitir que se generen nuevas claves para cada host al que se conecte. Para esta demostración, elimino el 192.168.1.84 entrada de known_hosts y luego conéctese al nuevo host en esa dirección, para que pueda ver una comparación de lo que sucede en el proceso. Primero, elimine un known_hosts entrada con ssh-keygen comando:
$ ssh-keygen -R 192.168.1.84 -f .ssh/known_hosts
Host 192.168.1.84 found: line 4
.ssh/known_hosts updated.
Original contents retained as .ssh/known_hosts.old
La entrada original se guarda en .ssh/known_hosts.old en caso de que sea necesario en el futuro.
Después de eliminar el 192.168.1.84 entrada de known_hosts archivo, intenté la conexión nuevamente para alojar 192.168.1.84 :
$ ssh 192.168.1.84
The authenticity of host '192.168.1.84 (192.168.1.84)' can't be established.
ECDSA key fingerprint is SHA256:I02UyJs2vS0ym4jWn5upAWZDqwu5RjMg4aM9hPq8G1k.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.84' (ECDSA) to the list of known hosts. Puede ver que la clave que agregué ahora coincide con la que aparece en el error al principio del artículo. Para verificar la clave de un host, emita el siguiente comando en el host remoto:
$ ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
256 SHA256:I02UyJs2vS0ym4jWn5upAWZDqwu5RjMg4aM9hPq8G1k no comment (ECDSA) Terminando
A menos que use direcciones IP estáticas y sus sistemas nunca cambien, tendrá este problema en algún momento de su carrera. Me pasa todo el tiempo porque creo y destruyo máquinas virtuales varias veces al mes. De hecho, sucede con tanta frecuencia que ahora debería tener un script que elimine los known_hosts archivo al principio de cada mes.
Idealmente, nunca tendría que eliminar una entrada de known_hosts archivo (o todo el archivo). Pero si tienes que hacerlo, acabas de aprender cómo hacerlo.
Conclusiones:known_hosts , ssh-keygen
[¿Quiere probar Red Hat Enterprise Linux? Descárguelo ahora gratis.]