¿Es seguro deshabilitar la verificación de la clave del servidor SSH si se usa la autenticación basada en la clave?

Navega tus respuestas
19

Tengo algunas tareas que van así:

  1. Gire algunas nuevas instancias de EC2 (Amazon Web Services)
  2. Haz que ejecuten una tarea
  3. Matalos

El problema es que se les asigna (aparentemente) aleatoriamente una dirección IP y, por casualidad, una nueva máquina reutilizó una dirección que se había utilizado anteriormente.

Esto obviamente provocó el siguiente error y mi secuencia de comandos falló: 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 RSA key sent by the remote host is 
Please contact your system administrator.
Add correct host key in /home/ec2-user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/ec2-user/.ssh/known_hosts:595
RSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

Estoy usando un par de llaves cuando me conecto a estas máquinas, en lugar de usar la autenticación de contraseña. ¿Esto evitaría un ataque de hombre en el medio, ya que un atacante no tendría el mismo par de llaves?

¿Puedo deshabilitar la verificación de la clave de host SSH?

    
pregunta Dean 03.08.2013 - 01:18
fuente

2 respuestas

14

Respuesta corta: Sí y no.

En primer lugar, aclaremos las cosas. ¿Cómo funciona la autenticación basada en clave en SSH de todos modos? Una vez que la conexión SSH llega a la fase de autenticación, el cliente firma una gran cantidad de datos (esto incluye el identificador de sesión) con su clave privada, y luego envía la firma al servidor para verificarla.

Pase de verificación de firma - > Autenticación exitosa.

¿Cómo ataque MiTM en este caso, entonces? El atacante se sienta entre usted y el servidor. Para un ataque exitoso, necesita que comiences una sesión con él, y necesita comenzar una sesión con el servidor. Cualquier cosa que envíe al servidor, realmente irá a él y él tendrá la capacidad de modificarlo y enviarlo al servidor, y lo que sea que el servidor le envíe, irá al atacante y el atacante podrá modificarlo y enviárselo. .

¿Has notado algo interesante? Aquí hay dos sesiones (tenga esto en cuenta). Cada sesión tendrá su propio identificador de sesión porque la generación del identificador de sesión no está determinada solo por el servidor o el cliente. En otras palabras, la firma que usa para autenticar al atacante será diferente de la firma que el atacante debe usar para autenticar al servidor real.

El atacante no tiene la clave privada del cliente, lo que significa que no podrá crear una firma que el servidor real acepte. Es por eso que este tipo de voluntad MiTM completa no es posible.

Porlotanto,essegurodeshabilitarlaverificacióndelaclavedelhost/huelladigital,¿verdad?Noexactamente.Esciertoquedebidoaqueelatacantenopodráautenticarseenelservidor,nopodráejecutarcomandosmaliciososenél.BUT

¿Recuerdascuandotehablédelasdossesiones?Elatacantenopodráestablecerunasesiónconelservidorreal,peropuedefácilmentehacerqueestablezcaunasesiónconél.Elatacantesimplementeaceptarálafirmaqueledesyloengañaráparaquepiensequeahoraestáconectadoalservidorreal.Leenviaráscomandos(yposiblementealgunascontraseñasespecíficasdelproceso)yconmuchogustoresponderáconloquetehagafeliz.

Porsupuesto,nohayningúnpeligrorealparaelservidoraquíyaqueesoscomandosnolleganrealmentealservidor.Essoloquenosesabequéenviarásalservidor(ahoraelatacante).Puedeenviarclaves,contraseñas(piense,cuandomodifiquesucontraseña,elservidorlesolicitarálacontraseñaactual)yotrainformaciónconfidencial.

Laconclusiónes:siestádispuestoaaceptarelriesgodeconectarseaunservidorfalsoquesabráloqueestáenviandoalservidorreal,desactivelaverificacióndelaclavedelhost/huelladigital.Delocontrario,manténgalohabilitado.

Referencias:

respondido por el Adi 03.08.2013 - 13:59
fuente
3

No sería seguro si tiene habilitado el reenvío de agente SSH en su configuración para el servidor en cuestión.

Si usa un agente SSH para administrar su autenticación basada en clave y usa ssh -A o si tiene algo como esto en su ~/.ssh/config : 

Host example.com
    ForwardAgent yes

o si tiene ForwardAgent habilitado globalmente, entonces no es seguro omitir o ignorar las comprobaciones de la clave del host.

La respuesta aceptada es excelente, pero omite esta advertencia tan importante.

Con el reenvío de agente habilitado, y suponiendo que su agente tenga la clave para que el servidor esté MITMed, entonces el atacante puede permitirle conectarse a él como se describe en la respuesta aceptada, luego realice una nueva conexión al servidor real usando el clave de su agente reenviado. La mayoría de los agentes (¿todos?) Lo permitirán silenciosamente. Y el resultado sería que ahora tiene una conexión totalmente MITMed al servidor real.

De alguna manera, esto es análogo al ataque MITM de autenticación de contraseña. En el escenario de autenticación de contraseña, el MITM roba su contraseña y la usa para autenticarse en el servidor para que usted no sepa nada. En el escenario de autenticación de clave pública (con reenvío de agente), el atacante hace uso de su agente para autenticarse. Entonces, aunque el atacante no tomaría posesión de su clave, el atacante podría usar su clave a través del agente para autenticarse como usted en el servidor, y también para hacerse pasar por otros hosts que aceptan su clave (pero solo durante la sesión). ).

Este escenario y el secuestro del agente SSH en el caso no MITM son las dos razones para ser MUY cuidadoso con los hosts a los que reenvía su agente. Piense en todo lo que un atacante podría hacer con el acceso a las claves que su agente ha cargado. Por ejemplo, si su estación de trabajo está configurada para aceptar una de las claves, el atacante podría volver a su estación de trabajo y recuperar la clave privada SSH. Y si la clave privada tiene una frase de paso, el atacante podría instalar un keylogger y esperar pacientemente hasta la próxima vez que lo descifre.

    
respondido por el joelsmith 12.01.2017 - 20:20
fuente

Lea otras preguntas en las etiquetas

¿Un marco de ORM como Hibernate mitiga completamente la inyección de SQL? ¿Por qué las extensiones de Chrome necesitan acceso a 'todos mis datos' y 'actividad de navegación'?