¿Es posible evitar el siguiente mensaje sobre: (LA IDENTIFICACIÓN DEL HOST REMOTO HA CAMBIADO)
Cuando se usa solo esta sintaxis de conexión
ssh xxx.xxx.xxx.xxx ejemplo de mensaje de advertencia:
ssh 10.19.11.1 CentOS release 5.8 (Final) Kernel 2.6.18-308.el5 on an i686 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is dd:6f:32:8f:8f:8c:70:9c:95:f1:48:83:60:97:cc:ed. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:7 RSA host key for 10.19.11.1 has changed and you have requested strict checkin. Host key verification failed. cada vez que recibo este mensaje, limpio /root/.ssh/known_hosts
como
cp /dev/null /root/.ssh/known_hosts Yo también estaba pensando en configurar el comando cp / dev / null /root/.ssh/known_hosts en el crontab,
para que todos los días a las 24:00 limpie el archivo known_hosts (esta solución disminuyó este problema pero no lo resolvió )
así que esta solución no es tan buena porque el usuario puede recibir el mensaje de advertencia a pesar de que limpiamos el archivo known_hosts cada día
tal vez podamos hacer algo en / etc / ssh / ssh_config para evitar la comprobación de la clave de host SSH?
comentario:
No quiero usar el siguiente método para pr event la comprobación de la clave de host SSH (porque uso reflexión / masilla)
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Insisto en usar solo esta sintaxis como
ssh xxx.xxx.xxx.xxx para la conexión
Comentarios
- En pocas palabras: don ' t hazlo. ¿De verdad leíste esa advertencia? Hay una razón para esta advertencia. Y es para protegerte del daño de un ataque MitM y otras cosas malas.
Responder
Actualización: Hoy en día puede usar certificados SSH , similar a TLS Certificados. Luego, puede agregar una entrada known_hosts para confiar en el certificado en lugar de en las claves individuales, y nunca volverá a recibir este mensaje.
¡Preste atención a la @ 0xC0000022L «s advertencia !
Si sabe que la clave de host ha cambiado , puede eliminar esa entrada específica del archivo known_hosts:
ssh-keygen -R xxx.xxx.xxx.xxx Esto es mucho mejor que sobrescribir el hosts (que se puede hacer con solo > /root/.ssh/known_hosts).
Si no desea utilizar ssh opciones de línea de comandos, creo que la única otra forma de hacer esto sería modificar el código SSH y volver a compilar. Lo que realmente no quiero hacer!
Comentarios
- pero quiero hacer esto de manera automática, cuando el usuario se queja de esto, no No quieres hacerlo manualmente
- No ' no quieres hacerlo manualmente (eliminando g
known_hostsentradas), y no ' t desea hacerlo automáticamente (usandosshopciones). ¿Cómo quiere hacerlo entonces? - @ l0b0 Al dar una opción de línea de comandos para suprimir la función. En algunos entornos, como los entornos de máquinas virtuales y otras configuraciones muy dinámicas (especialmente los entornos de prueba), estas claves de host cambian con frecuencia y, debido a que están en una red aislada, hay poca seguridad que ganar haciendo la verificación. Tener que hacer un
ssh-keygen -Rcada vez es molesto. Supongo que se podría escribir un shell para ssh, un script de shell que analiza la dirección de destino y elimina previamente la clave antes de pasar las opciones a ssh, pero esto parece excesivo.
Respuesta
paso 1: eliminar la clave defectuosa
ssh-keygen -R 192.168.1.1 paso 2: agregar una nueva clave
ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts o dependiendo de su situación
> ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts Comentarios
- -1 por proporcionar una pistola sin una advertencia.
- @ l0b0 ¡Es justo su señoría!
Responder
Al conectarse a máquinas virtuales desechables o similares, es mejor que no almacene las claves en primer lugar.
Cree un ssh0 alias o función con el siguiente contenido:
alias ssh0="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR" De esta manera, no «contaminarás tu ~/.known_hosts archivo con basura, y dado que estás usando un comando diferente, habría un límite entre el ssh «real» y el que se usa para instrumentar algún widget local.
Otro alias útil es
alias sshy="ssh -o CheckHostIP=no" para cuando «se está conectando a un dispositivo que cambia su IP con frecuencia, como por ejemplo. un enrutador doméstico al que el ISP asigna una IP diferente cada vez que se apaga y enciende.
Comentarios
- ¡La respuesta perfecta a esto!