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

¿Qué pasa si enviamos el hash?

Si el hash fuera el parámetro de autenticación, y no la contraseña, entonces el hash sería el parámetro de autenticación.

Para explicar más a fondo esa tautología: una contraseña está oculta de modo que si el almacén de datos de las contraseñas se ve comprometido, uno no tiene una credencial de autenticación funcional. Por ese motivo, es la contraseña que se envía al servidor donde el servidor realiza el trabajo para calcular el hash. Enviar el hash de una contraseña sería exactamente lo mismo que usar un generador de contraseñas sin hash.

¿Están sus contraseñas comprometidas si alguien tiene el control del servidor?

Todavía pueden robar contraseñas, ya sea por fuerza bruta que obliga al almacén de autenticación a generar la contraseña sin formato, o de manera más eficiente modificando el código daemon del servidor para registrar sus intentos de contraseña.

  

¿Podría alguien aclarar si esto es correcto?

Sí , es correcto que el servidor conozca la contraseña en texto sin formato. RFC 4252, sección 8 especifica la "Autenticación de contraseña" para SSH, y escribe (se cita libremente):

Tenga en cuenta que la [...] contraseña de cleartext se transmite en el paquete [...].

También quería proporcionar una respuesta, no sobre la pregunta en sí, sino sobre

  

¿Puede diseñar un protocolo que no envíe al servidor la contraseña o los valores iguales a la contraseña?

La respuesta es Sí .

Debes asegurarte de que tu protocolo haga lo siguiente:

1. (más parte de la implementación) El usuario debe tener algunos medios para confirmar que no están diciendo la contraseña al servidor. El protocolo más inteligente no tiene sentido si el servidor puede omitirlo al mostrar una entrada de texto de la que puede obtener el contenido. Esto es un problema si su aplicación es solo un terminal remoto y la autenticación ya se está realizando durante este "modo de terminal remota", o si el servidor puede "aceptar de forma falsa" la conexión sin una entrada de contraseña y luego mostrar la suya. Otro ejemplo sería un sitio web con un formulario html. El "diálogo emergente de ventanas emergentes de autenticación de http" está diseñado con este problema en mente.
2. Debería usar un protocolo de respuesta de desafío como SCRAM o SRP . Si su inscripción de contraseña está diseñada de una manera que no proporciona una clave para el servidor (o confía en el servidor en el momento de la inscripción, como en su ejemplo), ambos no dan valores al servidor que pueden usar para iniciar sesión en otros servidores con la misma contraseña. Para SCRAM, sus sales tienen que ser únicas por servidor, SRP lo libera de ese deber.
3. Debería usar el cifrado junto con Enlace de canal entre su capa de encriptación y su capa de respuesta de desafío. Esto hará que los servidores infectados no tengan la capacidad de jugar "man in the middle" en un servidor específico para la parte de autenticación de la conexión, y luego hacer su negocio malvado. SRP admite esto por su naturaleza, ya que es un protocolo de intercambio de claves, y el RFC oficial de SCRAM también admite el enlace de canales.

Sin embargo, esta es una discusión mayormente teórica. Debes usar las teclas ssh siempre que sea posible , ya que ofrecen una protección de fuerza bruta mucho mejor.

  

¿Podría alguien aclarar si esto es correcto?

Eso es un problema relativo. Quiero decir que depende de la naturaleza del control que la persona infame tiene sobre el servidor. Si tiene la habilidad suficiente para modificar / atrapar el demonio SSH (ubicado en el lado del servidor), podría obtener su contraseña. Pero eso es menos práctico en realidad porque hay maneras más fáciles de obtener su contraseña para un pirata informático obstinado por fuerza bruta forzando tu contraseña .

Pero aún así, la forma más segura de conectarse al servidor mediante SSH es usar el uso de pares de claves públicas / privadas para la autenticación en lugar de las contraseñas porque forzarlos de forma brutal es simplemente imposible .