¿Puede un servidor SSH malicioso exitosamente * pretender * conocer la clave pública de un cliente?

Navega tus respuestas
0

Sí, sé que después de proporcionar una clave pública SSH a otra persona, siempre se debe asumir que podría haberse publicado rápidamente en algún lugar. (Por ejemplo, proporcione su clave pública SSH a GitHub, y GitHub la publicará. Por ejemplo, presumiblemente esta pertenece a @Jeff Atwood , también conocido como Coding Horror.) Esta pregunta trata sobre una excepción a esa regla general.

Supongamos:

  • El cliente SSH C está intentando iniciar sesión en un servidor SSH S por primera vez , como usuario u , a través de la autenticación de clave pública;
  • C no no conoce la huella dactilar de la clave pública SSH de S (es decir, la huella dactilar de la clave del host);
  • S tiene una copia de la clave pública de C en /home/u/.ssh/authorized_keys ;
  • nadie excepto C y S conocen la clave pública de C ;
  • M es un servidor malintencionado idéntico a S en todos los aspectos (por ejemplo, igual de capaz que S se presenta a C en la dirección IP donde C espera encontrar S ), excepto que M no sabe C ' s clave pública.

Pregunta: ¿Puede C distinguir entre M y S ?

    
pregunta sampablokuper 26.01.2018 - 23:37
fuente

3 respuestas

-1

En el caso más simple, un disparo, C podría distinguir entre S y M enviando una firma no válida al público Desafio Clave. S podría calcular que la firma no es válida porque tiene la clave pública correcta.

Algunos esquemas de firma de clave pública puede proporcionar a un observador la clave pública si pueden ver varias firmas correctas creadas por la clave privada.

    
respondido por el John Downey 27.01.2018 - 00:36
fuente
1

Entonces, si el cliente no tiene conocimiento de la clave pública del servidor y no tiene autoridad para verificar nada, entonces no hay manera de distinguir entre el servidor auténtico y un servidor malicioso. Debido a que el servidor malicioso solo generaría un nuevo par de claves públicas privadas y proporcionaría la clave pública correspondiente al cliente y todas las coincidencias se verificarían.

Sin embargo, la premisa del ataque "igual de capaz que S es de presentarse a C en la dirección IP donde C espera encontrar S" no es razonable porque todas las esperanzas deberían estar trabajando juntas para encaminar incorrectamente a una dirección incorrecta. por lo que el servidor malintencionado podría manipular los paquetes sin romper el túnel. No imposible, pero definitivamente un caso de vanguardia.

    
respondido por el noone392 27.01.2018 - 01:02
fuente
0

Si nunca se conectó previamente al servidor y no conoce la clave de host (o la huella digital del host) del servidor al que está intentando conectarse, un servidor ssh malicioso podría permitirle a un usuario ingresar una clave pública autenticación (o autenticación de contraseña).

De hecho, el servidor malintencionado puede hacer un intermediario entre el servidor ssh real y usted, para autenticarse con su conexión en tiempo real.

Pero esto se puede evitar agregando la clave de host pública del verdadero servidor a su archivo /etc/ssh/known_hosts o por usuario ~/.ssh/known_hosts , y no acepte ciegamente certificados de host desconocidos O ignore los errores cuando la clave de host no coincida.

    
respondido por el dr jimbob 27.01.2018 - 01:52
fuente

Lea otras preguntas en las etiquetas

Regedit muestra caracteres chinos extraños en mi sistema. ¿Debería preocuparme? Comprobación programada de certificados intermedios