Lancé una novedad /etc/ssh/sshd_configcon Puppet en un servidor de prueba Ubuntu 12.04. La configuración era exactamente la misma que la configuración anterior, excepto que se había eliminado la siguiente línea:
HostKey /etc/ssh/ssh_host_ecdsa_key
Me di cuenta de que recibía muchos errores similares pero variables al intentar conectarme al cuadro a partir de ese momento, como por ejemplo: "La clave de host RSA para%nombre de host%ha cambiado y la clave para la dirección IP correspondiente%dirección IP% no ha cambiado."
Supuse que esto se debía a que mi computadora anteriormente usaba la clave ECDSA de forma predeterminada y ahora no estaba disponible. Así que agregué esa línea nuevamente sshd_configy reinicié SSH.
No resolvió el problema por completo y desde entonces tengo problemas constantes. Podré conectarme al servidor sin problemas varias veces, tal vez incluso durante varios días seguidos. Luego, de repente, empiezo a recibir errores de que la clave del host ha cambiado y el servidor deja de aceptar mi clave pública para la autenticación.
Siempre parece que una vez que juego con él por un tiempo y me conecto desde una ubicación diferente, de repente podré conectarme con mi clave pública nuevamente y ya no recibo el error sobre un posible intermediario. ataque.
Intenté regenerar las 3 claves de host hace varios días (las eliminé y ejecuté dpkg-reconfigure openssh-serverel proceso que las regeneró). Como era de esperar, tuve que quitar las claves antiguas y aceptar las nuevas antes de poder conectarme. Pensé que tal vez ya se había solucionado, pero ahora el problema ha vuelto.
Nada ha modificado ninguna de las claves de host /etc/ssh/desde que las regeneré por última vez, entonces, ¿qué podría causar que no pueda conectarme con frecuencia, que mi clave pública no funcione y que finalmente acepte la nueva clave y que todo comience a funcionar bien nuevamente? ¿por un momento?
Cuando las cosas no funcionan (cuando aparece el error sobre el cambio de la clave del host y luego el servidor deja de aceptar mi clave pública), no se escribe nada en el archivo /var/log/auth.log. Esto me lleva a pensar que tal vez de alguna manera esté afectando a una máquina diferente a veces, pero tampoco sé cómo es posible, ya que la entrada DNS es correcta y siempre devuelve la misma dirección IP.
Respuesta1
Hay tres razones comunes por las que recibirías ese mensaje.
En orden aproximado de probabilidad son:
Usted mismo cambió las claves del host y no las borró ni actualizó en sus máquinas cliente.
Esta es la situación más común. Verifique la suma de los archivos clave y asegúrese ABSOLUTAMENTE de que no hayan cambiado.Ha cambiado su configuración SSH para presentar (o solicitar) un tipo de clave diferente al anterior.
por ejemplo, antes quería claves RSA o DSA, ahora usa ECDSA; eso es un "cambio de clave".
Si este es el caso, verifica y acepta las nuevas claves (o si esto no es lo que querías, deshace el cambio).
(Parece que está en la situación n.° 2: deshaga los cambios, reinicie sshd y verifique que todo funcione como se esperaba. Si no ha aceptado las nuevas claves en ningún lugar, deshacer el cambio debería hacer que el error desaparezca).ALGUIEN ESTÁ HACIENDO ALGO DESAGRADABLE
El ataque Man-in-the-Middle sobre el que SSH le advierte ha asomado su fea cara. Alguien está intentando activamente interceptar su comunicación para robar su clave privada o hacer algo que usted seguramente no quiere que haga.
Si ha eliminado 1 y está seguro de no haber eliminado 2, le corresponde asumir 3 hasta que pueda demostrar lo contrario. Eso significaNo inicies sesión. -- Toda la seguridad SSH del mundo no ayuda cuando los usuarios ignoran el gran cartel de advertencia gigante y entregan sus claves a los atacantes.
Investigue el canal entre usted y su servidor, verifique los registros de conexión del servidor (desde una terminal en buen estado) mientras intenta iniciar sesión, etc. Hay tantas formas de ejecutar un ataque aquí que no puedo enumerar todas las posibles contramedidas y estrategias de detección, pero la gente deSeguridad informaticaSeguramente tendría algunas ideas.
Respuesta2
si es posible/para probar/depurar:
- use IP en lugar de nombres de host (solo para asegurarse)
- ¿Hay varias máquinas que tienen la misma IP (DHCP proporcionó la IP que fue utilizada por otro host con IP fija) en la red?
- Si las máquinas usan DHCP, sus IP pueden cambiar en momentos aleatorios (orden de inicio, etc.). Tal vez ahora esté intentando conectarse a un host diferente: habilite la autenticación de contraseña y vea dónde llega.
- en el cliente cat /home/username/.ssh/known_hosts busque líneas con claves duplicadas pero diferentes ips/nombres de host
Por ejemplo:
192.168.56.3 ecdsa-sha2-nistp256 AAAAE2...fPfFAyoGSVAvs=
192.168.56.4 ecdsa-sha2-nistp256 AAAAE2...fPfFAyoGSVAvs=