Copie claves ssh de un servidor a otro servidor

Tengo un servidor (supongamos que su ip sea abcd) que permite a los usuarios iniciar sesión a través de ssh. Ahora quiero cambiar la máquina física manteniendo la ip igual. Para que un usuario como este pueda acceder a la nueva máquina

$ ssh abcd

El problema es que cada vez que un usuario intenta iniciar sesión, obtiene el siguiente error de falta de coincidencia de clave ssh.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@
@ ADVERTENCIA: ¡LA IDENTIFICACIÓN DEL HOSPED REMOTO HA CAMBIADO! @ @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@
¡Es posible que alguien esté haciendo algo desagradable!
¡Alguien podría estar escuchándote ahora mismo (ataque de hombre en el medio)!
También es posible que la clave de host RSA se haya cambiado.
La huella digital para la clave RSA enviada por el host remoto es
02: dc: c6: 18: 1b: 34: b7: 1d: fa: 90: ab: e1: 95: 48: 69: 84.
Por favor, póngase en contacto con el administrador del sistema.
Agregue la clave de host correcta en /home/user/.ssh/known_hosts para deshacerse de este mensaje.
Clave ofensiva en /home/user/.ssh/known_hosts:37
La clave de host RSA para ex alumnos ha cambiado y usted ha solicitado una verificación estricta.
La verificación de la clave del host ha fallado.

Sé que el usuario puede eliminar la línea # 37 del archivo ~ / .ssh / known_hosts y la próxima vez recibirá un mensaje de sí / no. Lo que quiero es que el usuario no se entere de todo este reemplazo de la máquina y solo solicite una contraseña.

¿Como hacer eso?

ssh

— Souvik Pal
fuente

¿Eres consciente de que esto derrotaría sshla única protección contra el hombre en los ataques intermedios y podría resultar en que envíes tu contraseña directamente al atacante en lugar de la máquina prevista? A menos que sepa con certeza que es invulnerable a los ataques activos (por ejemplo, está en la misma red interna segura que la máquina de destino), esto destruye sshel modelo de seguridad.

— David Schwartz

Si. Ambas máquinas están en las mismas redes internas. Incluso los usuarios están dentro de la misma red interna. Ante esta situación, ¿cuáles son mis opciones?

— Souvik Pal

Eso no es suficiente. Tienen que estar en la misma red interna segura . Es decir, deben confiar absolutamente al 100% en que ningún dispositivo está conectado a esa red interna que no es 100% segura, y deben confiar al 100% en todos los que tienen control sobre esos dispositivos o pueden conectar un dispositivo a esa red. En otras palabras, en casi cualquier escenario realista, esta es una mala idea.

— David Schwartz

Es una cosa perfectamente razonable de hacer. Estoy replicando las claves del servidor ssh en otro servidor para HA, de modo que cuando inicio sesión obtengo esos errores. Además recibo un correo electrónico en caso de falla.

— Matt H

Estoy de acuerdo con Matt Si tiene el control de ambas máquinas y, por lo tanto, es el propietario de las claves, mover la clave del host de una máquina a otra dentro de su control NO ES un hombre en medio de un ataque o riesgo. Si el usuario que se conecta confía en su clave de host, no debería importar.

— Ross

Respuestas:

Como mencionó Ethabell , puede copiar las claves de host actuales al nuevo servidor.

Puede encontrar sus claves de host abriendo su sshd_configarchivo (en mi cuadro Ubuntu 12.04 es /etc/ssh/sshd_config). En el archivo de configuración, busque las HostKeyentradas. Estas entradas le indicarán dónde se encuentran los archivos de clave de host. Debería poder copiar estos archivos al nuevo servidor y actualizar los nuevos servidores sshd_configpara que apunten a las claves copiadas (o simplemente sobrescribir los archivos que ya existen en el nuevo servidor).

Además, tenga en cuenta esta sección de la sshd_configpágina de manual, específicamente la parte sobre permisos:

Especifica un archivo que contiene una clave de host privada utilizada por SSH. El valor por defecto es /etc/ssh/ssh_host_keypara el protocolo de la versión 1, y /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_keyy /etc/ssh/ssh_host_rsa_keypara la versión del protocolo 2. Observe que sshd (8) se negará a usar un archivo si es grupo / mundo de ruedas. Es posible tener múltiples archivos de clave de host. Las teclas "rsa1" se usan para la versión 1 y "dsa", "ecdsa" o "rsa" se usan para la versión 2 del protocolo SSH.

— pesado
fuente

Si tuviera la clave de host original, podría restaurarla y esto detendría el error.

O bien, puede desactivar StrictHostKeyChecking en su archivo de configuración sshd.

... Hacer esto, sin embargo, es una idea horrible, horrible. Si hay una manera de que simplemente se ejecute ssh-keygen -R server.example.comen las máquinas cliente, esa sería la mejor manera, porque desactivar la comprobación de la clave del host es como decir: "Oye. Atácame". Me dan ganas de oscuridad cuando las cosas cambian, pero la seguridad debería ser la prioridad n. ° 1 sobre los cambios oscuros.

— Ethabelle
fuente

¿Puede explicar cómo restaurar las claves de host en una máquina más nueva?

— Souvik Pal

Puedes intentarlo así

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"'

Tenga en cuenta que si la carpeta .ssh aún no existe, el comando anterior fallará. Además, podría ser mejor al crear el archivo establecer un permiso mínimo posible (básicamente lectura-escritura solo para el propietario). Aquí hay un comando más avanzado:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys && echo "Key copied"'

Para obtener más información sobre este problema, debe acceder a este sitio web: Error de cambio de clave de host SSH

— Govind Karamta
fuente