☰

¿Inicio de sesión SSH en la misma dirección IP pero en un sistema operativo diferente?

tag-icon • tag-icon ssh
¿Inicio de sesión SSH en la misma dirección IP pero en un sistema operativo diferente?

Conecté Raspberry Pi con el sistema operativo Raspbian a la red local y configuré el inicio de sesión SSH usando claves ssh. Inicié sesión correctamente con solo (IP estática asignada a Raspberry Pi).ssh [email protected]

Ahora quité el sistema operativo Raspbian e inserté una tarjeta SD con Ubuntu Server (sin cabeza).

Encendí la Raspberry Pi e intenté iniciar sesión, pero apareció el error:

ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:asfasfdasdfasfdasfdasdfasdfasdfasdfasfasdf.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /home/joedoe/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /home/joedoe/.ssh/known_hosts:13
ERROR:   remove with:
ERROR:   ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"
ERROR: ECDSA host key for 192.168.5.163 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Continué y agregué a mi .ssh/config:

host 192.168.5.163
    StrictHostKeyChecking no

pero ahora lo entiendo

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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:asdfasdfasdfasdfasdfasdfasdfasdfasdf.
Please contact your system administrator.
Add correct host key in /home/joedoe/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/joedoe/.ssh/known_hosts:13
  remove with:
  ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
[email protected]: Permission denied (publickey,password).

Claramente, el problema es que quiero iniciar sesión en dos sistemas operativos diferentes con la misma dirección IP, pero el nuevo sistema operativo Ubuntu no activa la configuración de inicio de sesión SSH y no me permite iniciar sesión de ninguna manera.

¿Cómo debo proceder para poder utilizar ambos sistemas operativos indistintamente?

Respuesta1

Hay varias soluciones potenciales.

La solución más sencilla es la que propuso Davidgo en su respuesta, que, como él menciona, lo deja expuesto a un ataque MitM (poco probable, pero es bueno practicar una buena seguridad incluso en situaciones privadas).

  Host 192.168.5.163
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null

Una solución ligeramente mejor sería, como propuso Eugen Rieck, sincronizar los /etc/ssh/ssh_host_*key*archivos entre ambos sistemas operativos de destino.

Un método más confiable sería decidir específicamente a qué sistema operativo conectarse, de modo que reciba un error si se conecta al sistema operativo incorrecto. Eso permitiría, por ejemplo, que los scripts que usan ssh fallen si apuntan al sistema operativo incorrecto.
Puedes hacerlo usando efectivamente un Alias ​​en el archivo ~/.ssh/ssh_config.

Host raspbian-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_raspbian

Host centos-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_centos

Luego puede conectarse ssh <your_user>@raspbian-pipara recuperar la clave del sistema operativo Raspbian, luego cambiar a CentOS en su Raspberry Pi y hacer lo mismo ssh <your_user>@centos-pipara obtener la clave CentOS. Luego, en el futuro, cada vez que se conecte al sistema operativo incorrecto, obtendrá el error de clave de host. Asegúrese de usar el sistema operativo correcto la primera vez que use el comando SSH, para no almacenar accidentalmente la clave de host de CentOS en el archivo de hosts conocidos de Raspbian.

Descargo de responsabilidad: nunca he usado esta solución y no estoy en condiciones de probarla, pero debería funcionar correctamente según mi entendimiento y la documentación de ssh.

Respuesta2

Puede solucionar el problema inmediato siguiendo las instrucciones del error (debe hacer esto cada vez que cambie de casilla):

ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"

El problema con el que se encuentra es que su computadora ha detectado que el sistema en el que inicia sesión es diferente al visto anteriormente, y la advertencia está ahí para evitar ataques de intermediario.

Hay varias maneras de abordar esto adecuadamente. Incluyen:

  1. Configurar nombres para cada cuadro /etc/hostsy luego hacer referencia a la conexión SSH por nombre en lugar de IP. De esta manera SSH asociará diferentes huellas digitales del servidor con cada nombre.

  2. Ignorar la verificación (esto lo abre a ataques mitm, así que hágalo solo si comprende y se siente cómodo con los riesgos). Puede ignorar esta verificación agregando -o UserKnownHostsFile=/dev/nulla su comando ssh o-o StrictHostKeyChecking=no

    2a. Puede crear una configuración que solo ignore la verificación de clave para una IP colocando lo siguiente en~/.ssh/config

    Host 192.168.5.163 StrictHostKeyChecking no UserKnownHostsFile=/dev/null

  3. No lo recomendaría a menos que las máquinas cumplan la misma función, pero podría hacer que las claves de host sean /etc/sshlas mismas en ambos servidores (y restart sshden el que cambió). De esta forma ambos servidores le aparecerán iguales al cliente.

Respuesta3

La forma más sencilla de hacer esto es copiar /etc/ssh/ssh_host_*_key*de una instalación a otra; esto le dará a ambos sistemas operativos las mismas claves de host y, por lo tanto, la misma huella digital.

Respuesta4

Yo personalmente uso una autoridad de certificación OpenSSH para todos mis servidores Linux. Esto me ahorra muchos problemas al configurar uno nuevo y organizar mis dispositivos terminales (computadoras de escritorio, portátiles y hosts de salto), que anteriormenteblogueó sobre.

Si bien esta característica no está diseñada originalmente para este caso de uso (inusual), proporciona una solución alternativa al problema. Simplemente firme ambas claves de host con la clave privada de su CA y agregue la parte pública a su known_hostsarchivo, y su cliente SSH confiará automáticamente en ambos conjuntos de claves de host sin gritarle sobre las discrepancias. Sin embargo , es posible que aún tengas que eliminar las claves de host recordadas de ssh-keygen -Rantemano.

Esto tiene la ventaja de que ambos sistemas pueden mantener sus claves de host separadas y diferentes, lo que le brinda la posibilidad de distinguirlas por claves de host (y certificados; hay un campo de "identidad" que puede personalizar al firmar los certificados). Esto también es seguro porque no es necesario confiar ciegamente en un host arbitrario que aparece en esa dirección IP específica.

Incluso si desea protegerse contra claves filtradas, puede agregar "nombres permitidos/direcciones IP" como "principales" al firmar los certificados, por ejemplo:

ssh-keygen -s my_ca -I "RaspOS on RPi" -h -n 192.0.2.0 ssh_host_rsa_key.pub

El certificado seránoser confiable a menos que se presente desde el host en 192.0.2.0, a menos que un atacante de alguna manera se apropie de su tráficoademás delas claves y los certificados del host.

Bueno, ahora tengo que admitir que es más fácil copiar las claves de host entre ambos sistemas operativos ya que, después de todo, están en la misma máquina física.

información relacionada