☰

¿Cómo actualizar SSHD sin cambiar la clave del servidor?

tag-icon • tag-icon sshd
¿Cómo actualizar SSHD sin cambiar la clave del servidor?

Entonces... necesitamos actualizar el SSHD. ¿Cómo podemos hacer esto sin tener el problema de que las personas (que inician sesión a través de ssh) vean el mensaje?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
0e:a1:b1:40:85:a2:a7:03:17:1b:52:8f:10:c7:b3:d0.
Please contact your system administrator.
Add correct host key in /home/USERNAME/.ssh/known_hosts to get rid of this message.
Offending key in /home/USERNAME/.ssh/known_hosts:13
RSA host key for [192.168.1.1]:22 has changed and you have requested strict checking.
Host key verification failed.

Respuesta1

Por lo general, simplemente actualizar sshd no reemplazará la clave de host. Así que sí, simplemente actualízalo y debería estar bien.

Nota: Normalmente no necesitarás esto, pero si quieres estar seguro, puedes crear una copia de seguridad de las claves del host ssh y copiarlas nuevamente después de actualizar tu sistema. Normalmente tendrías que hacer una copia de seguridad /etc/ssh/ssh_host*. Si algo salió mal, puedes restaurar los archivos más tarde.

Respuesta2

Me doy cuenta de que esta es una pregunta antigua, pero creo que es una adición válida para búsquedas futuras. Actualizar su sshd no debería provocar que se vuelva a crear la clave de host, por lo que está bien con una actualización. Sin embargo, actualizar su servidor puede provocar que se cree una nueva clave de host. El mensaje que estás describiendo aparece cuando el cliente ssh no reconoce la clave de host del servidor, por lo que cualquier cosa que cambie la clave de host causará este problema.

Una forma de solucionar esto es remodelar su uso de ssh para usar certificados en lugar de contraseñas y claves. Si bien esto requiere algo de trabajo y un poco de remodelación, vale la pena si desea firmar mejor sus servidores. Hay una muy buena guía aquí:

http://neocri.me/documentation/using-ssh-certificate-authentication/

Básicamente, lo que debe hacer es crear una CA para los servidores y una CA para los usuarios, y luego usarlas para autenticar a los clientes y servidores respectivamente. Aún verá el mensaje anterior si inició sesión con nombre de usuario/contraseña, pero para cualquiera que inicie sesión con certificados, lo único que importa es que el certificado del host del servidor esté firmado por la CA del servidor.

información relacionada