¿Se revela su contraseña SSH cuando intenta conectarse al servidor incorrecto?

192

Cuando intenta conectarse accidentalmente al servidor incorrecto con credenciales de contraseña, ¿es posible que el administrador lea y registre la contraseña que utilizó?

ssh password

— vfclists
fuente

11

¿La autenticación de contraseña SSH proporciona al servidor la contraseña?

— jamesdlin

41

En un cliente ssh, primero autentica el servidor y al hacerlo dice "Confío en que puedo decirle mi contraseña a este servidor". La próxima vez, preste más atención al mensaje que vio primero: "No se puede establecer la autenticidad de X. La huella digital de la clave RSA es Y ¿Está seguro de Z? (Sí / no)" Esta pregunta molesta no se haría si supusiera para responder automáticamente sí cada vez.

— kubanczyk

66

Es posible establecer PasswordAuthentication node forma predeterminada en OpenSSH y solo habilitarlo (si es necesario) para servidores de confianza. En combinación con la comprobación estricta de la clave de host, esto debería protegerlo principalmente de exponer su contraseña, a un costo conveniente, por supuesto.

— hobbs

66

@kubanczyk, si quería SSH a "internal-www.my-company.com" pero accidentalmente escribió "ssh www.my-company.com", ese mensaje no lo protegerá, es probable que ambos servidores estén en su lista de confianza, es solo que uno de ellos es administrado por usted y el otro por un tercero.

— Mark

@hobbs, ChallengeResponseAuthentication notambién, creo

— ilkkachu

215

En pocas palabras: sí

Mas detalle...

Si se conecta a mi máquina, entonces no sabe si estoy ejecutando un sshservidor normal , o uno que haya sido modificado para escribir la contraseña que se está pasando.

Además, no necesariamente necesitaría modificar sshd, pero podría escribir un módulo PAM (por ejemplo, usando pam_script), al que se le pasará su contraseña.

Entonces sí. NUNCA envíe su contraseña a un servidor que no sea de confianza. El propietario de la máquina podría haberla configurado fácilmente para registrar todas las contraseñas intentadas.

(De hecho, esto no es raro en el mundo infosec; configure un servidor honeypot para registrar las contraseñas intentadas)

— Stephen Harris
fuente

13

Correcto. Por defecto, la norma sshdno no ingrese contraseñas. (Si ingresa su contraseña como nombre de inicio de sesión, se registrará, pero ese es otro problema). El estándar sshdes una herramienta de seguridad, por lo que no registrará credenciales como esta :-)

— Stephen Harris

116

Otra razón más para usar pares de claves públicas / privadas ...

— gerrit

3

Me he estado preguntando acerca de mi uso de contraseñas por un tiempo y recientemente me di cuenta de que intentar iniciar sesión en los servidores incorrectos sería una buena manera de revelar mi contraseña a un administrador de servidor malicioso.

— vfclists

10

@vfclists iniciar sesión en el servidor incorrecto también es exactamente la razón por la cual su cliente sshd almacena la huella digital para cada servidor. Cuando te conectas por primera vez, aceptas esa huella digital, luego, si no coincide, obtienes una advertencia gigante a la que debes prestar atención.

— Hometoast

44

Mejor consejo: nunca use la autenticación de contraseña para ssh. El protocolo tiene autenticación pubkey por muy buenas razones; úsalo!

— R ..

52

Si.

La contraseña se envía después de establecer la conexión cifrada, pero el servidor remoto obtiene la contraseña en texto sin formato.

Si le importa eso, la mejor y más fácil solución es usar claves SSH.

Si tiene máquinas que no pueden aceptar claves, entonces una solución sería crear una herramienta que almacene sus contraseñas de forma segura, y luego las use sshpasspara enviar siempre la contraseña correcta según el servidor al que se esté conectando.

Ahora, la razón por la que la contraseña se envía en texto sin formato, es que deja todas las decisiones de manejo y almacenamiento al extremo remoto, y el cliente puede ser totalmente tonto. Hay un par de formatos diferentes de hash de contraseña (almacenamiento) utilizados en sistemas Linux y BSD durante los últimos diez años más o menos ( crypt (3) ), ninguno de los cuales requiere soporte del cliente.

Aunque eso también se debe en parte a la historia (es decir, siempre ha sido así). Hay mejores protocolos de autenticación de desafío-respuesta que podrían usarse incluso con contraseñas. Por ejemplo , SRP , que proporciona a las partes un secreto compartido durante la autenticación. Se ha implementado para algunos servidores SSH, pero el parche para OpenSSH es para una versión (muy) antigua.

— ilkkachu
fuente

1

El problema con los protocolos de desafío-respuesta para la autenticación de contraseña es que algunos de ellos requieren que el servidor almacene la contraseña en texto sin formato. Si el protocolo desafío-respuesta permite que el servidor almacene una contraseña hash, entonces lo más probable es que requiera un algoritmo hash muy específico.

— kasperd

8

Las contraseñas generalmente se envían en "texto sin formato" (es decir, en realidad no en claro, sino solo con la protección que el SSH | TLS | subyacente sea cual sea la conexión). Si un sistema solicitara que las contraseñas se cifren en el lado del cliente y que se envíe el hash, los servidores no tendrían forma de obtener la contraseña real y , en cambio, otorgarían acceso a cualquiera que pudiera proporcionar el hash de la contraseña , haciendo que dicho hash sea equivalente a la contraseña .

— Blacklight Shining

1

@BlacklightShining Existen pruebas de contraseña de conocimiento cero, pero no se usan en SSH porque no hay forma de usar la base de datos de contraseñas estándar para ellas y no hay un punto real para usarlas en lugar de la autenticación basada en claves.

— Random832

¿Dónde puedo ver esas contraseñas utilizadas para autenticar? No están en /var/log/auth.log, ¿dónde, entonces?

— アレックス

OpenSSH no registrará las contraseñas, fallidas o no. (No estoy muy familiarizado con otros servidores SSH). En casi todas las instalaciones legítimas, cualquier valor que esto pueda proporcionar sería compensado por el riesgo inherente a registrar contraseñas intencionalmente, algunas de las cuales podrían haber sido proporcionadas por usuarios legítimos que cometieron un error tipográfico o probé una contraseña incorrecta pero correcta para otra cosa, en texto sin formato. Sin embargo, si tiene una buena razón para hacer esto, sería fácil parchear OpenSSH.

— musicinmybrain

10

Para construir sobre la respuesta de Stephen Harris, aquí hay una vista en tiempo real que creé que muestra lo que un script de autenticación PAM modificado podría capturar cuando se conecta a un cuadro a través de ssh (una especie de honeypot). Yo uso una versión modificada de la biblioteca PAM lib-storepw.

https://livesshattack.net

https://livesshattack.net/about

— Willie S.
fuente

44

Las respuestas que son principalmente enlaces están mal vistas en caso de que el enlace no esté disponible (parece que mantiene este sitio personalmente, pero aún así). Debería describir un poco cómo logró esto con su script de autenticación para lectores.

— Centimane

ya no funciona, envié una cadena enorme como contraseña, creo que podría haberla roto, lo siento: - /

— scottydelta

@scottydelta Aunque no lo he investigado, puede haber un límite de búfer en el tamaño de la contraseña que el módulo PAM o el demonio SSH pueden aceptar en un intento de autenticación. El sitio todavía funciona como lo pretendía, aunque manejará hasta el límite del búfer aceptado por el sshd o el módulo PAM si este es el caso.

— Willie S.

¿Está la fuente de su lib-storepw modificado disponible para que otros la usen?

— Tim Fletcher

2

SSH es un protocolo que requiere confianza mutua. Esa es la razón por la cual el cliente OpenSSH mantiene un archivo conocido_hosts, para implementar su confianza en el esquema de primer uso.

Cuando intenta iniciar sesión en un servidor SSH, independientemente de quién suministró el software o qué datos está configurado para iniciar sesión, está participando en algún procedimiento de autenticación. Cuando usa la autenticación de contraseña, está transmitiendo su contraseña a ese servidor. Esta es una razón por la cual se recomienda la criptografía asimétrica (clave pública, certificados): la criptografía de clave pública reduce en gran medida el riesgo de revelar sus credenciales. (Aunque eso puede no protegerlo de un ataque MitM si utiliza el reenvío de agente ssh o algún esquema similar).

— jvoorhis
fuente

SSH no requiere confianza mutua, o al menos no confianza simétrica. Es importante ser preciso: known_hosts se trata de autenticidad, no de confianza. Como señala, colocar una clave pública en un host menos confiable es seguro. De hecho, el uso de una contraseña para iniciar sesión también es "seguro", suponiendo que no reutilice esa contraseña. (Es tan seguro como el grado en que confía en el servidor, por supuesto). Incluso los inicios de sesión ssh basados en host dependen de la confianza asimétrica.

— markhahn