¿Una sesión de SSH a un sitio equivocado es una exposición de seguridad?

40

Hace unos minutos intenté conectarme a un servidor que tengo en mi oficina. Como es un servidor nuevo, mi clave pública no se ha configurado allí, por lo que tuve que escribir mi contraseña manualmente.

Después de tres intentos de iniciar sesión sin éxito, me doy cuenta de que había escrito mal el nombre de dominio: dos caracteres transpuestos. ¡El servidor en el que había estado intentando iniciar sesión no estaba en mi oficina sino en otro lugar!

Mi pregunta: ¿el protocolo SSH expone mi contraseña en tal situación? En otras palabras, si ese servidor se hubiera configurado deliberadamente de alguna manera para detectar un error como este, ¿podría hacerlo?

Voy a cambiar esa contraseña de todos modos, pero me gustaría saber si ese accidente es un riesgo real. Cualquier información bienvenida.

    
pregunta AlanObject 27.12.2013 - 01:06
fuente

3 respuestas

40

Sí, el servidor remoto ahora tendrá acceso a su contraseña. Y si la configuraron para registrar esa contraseña (que no es la predeterminada en ningún producto SSH que conozco), debe cambiar su contraseña aún más rápido de lo que ya lo está haciendo :)

    
respondido por el Dennis Kaarsemaker 27.12.2013 - 01:13
fuente
9

Sí. El paquete que contiene su contraseña está encriptado para que solo el servidor deseado pueda leer la contraseña entrante, sin embargo, una vez que el paquete se procesa, su contraseña quedará en blanco. El cliente ssh no está transmitiendo un hash de su contraseña (pensé que era así que revisé la fuente y encontré lo contrario), es su contraseña completa.

Por supuesto, ningún sshd legítimo registraría contraseñas, pero igualmente, por supuesto, nadie debería confiar en algún servidor desconocido al azar.

    
respondido por el blah44 27.12.2013 - 12:26
fuente
6

La documentación de referencia relevante es Sección 8 de RFC 4252: Protocolo de autenticación de Secure Shell (SSH) .

Las partes pertinentes de esto dicen:

  

La autenticación de contraseña utiliza los siguientes paquetes. Todos
  Las implementaciones DEBEN ser compatibles con la autenticación de contraseña.

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "password"
  boolean   FALSE
  string    plaintext password in ISO-10646 UTF-8 encoding [RFC3629]
     

Tenga en cuenta que a pesar de que la contraseña de cleartext se transmite en el   paquete, todo el paquete está cifrado por la capa de transporte.

Entonces, como otras personas aquí han observado: la buena noticia es que cualquiera que esté escuchando el intercambio no debería haber visto el texto simple de su contraseña; la mala noticia es que , mediante sus acciones, ha revelado su contraseña al servidor SSH en el que intentó iniciar sesión y le recomendamos que cambie esa contraseña. Mejor aún, use autenticación de clave pública en su lugar.

    
respondido por el sampablokuper 02.01.2014 - 20:54
fuente

Lea otras preguntas en las etiquetas