¿Alguien puede explicar la 'Autenticación de contraseña' en el archivo / etc / ssh / sshd_config?

28

En esta página , la explicación dada es:

La opción Autenticación de contraseña especifica si debemos usar autenticación basada en contraseña. Para una seguridad sólida, esta opción siempre debe establecerse en sí.

Pero no proporciona ningún escenario de casos de uso que aclare cuándo un Sí o un no sería apropiado. ¿Puede alguien por favor elaborar más?

linux ubuntu security openssh Zeta2
fuente

Respuestas:

21

Su enlace apunta a la documentación con 10 años de retraso.

SSH admite múltiples formas de autenticar a los usuarios, la más común es solicitar un inicio de sesión y una contraseña, pero también puede autenticar al usuario con un inicio de sesión y una clave pública. Si configura PasswordAuthentication en no, ya no podrá usar un inicio de sesión y una contraseña para autenticarse y, en su lugar, deberá usar un inicio de sesión y una clave pública (si PubkeyAuthentication está configurado en yes)

radio
fuente
está bien, solo para autorizado_key2: (1) comente el AuthorizedKeysFile (2) PasswordAuthentication no (3) PubkeyAuthentication yes (4) ChallengeResponseAuthentication no (5) pruébelo ... si todavía acepta contraseñas, también agregue UsePam no
YumYumYum el
Use esta configuración: fpaste.org/114544/04202660 cuando solo permita el inicio de sesión SSH a través de ~ / .ssh / certified_keys2 pero no con nombre de usuario / contraseña
YumYumYum
1
¿Y cuál es el valor POR DEFECTO? Quiero decir, ¿qué pasa si no especifico ninguna "Autenticación de contraseña"?
Riccardo SCE
@TSERiccardo: ¿Nadie respondió tu pregunta? Es una lástima, ¡culpa!
Timo
1
@RiccardoSCE Según la página de manual de sshd_config, el valor predeterminado para PasswordAuthentication es 'yes'.
Starfish
53

Tenga en cuenta que la configuración de Autenticación de contraseña no controla TODAS las autenticaciones basadas en contraseña. ChallengeResponseAuthentication generalmente también solicita contraseñas.

PasswordAuthentication controla la compatibilidad con el esquema de autenticación de 'contraseña' definido en RFC-4252 (sección 8). ChallengeResponseAuthentication controla la compatibilidad con el esquema de autenticación 'interactivo con el teclado' definido en RFC-4256. El esquema de autenticación 'interactivo con el teclado' podría, en teoría, hacerle al usuario cualquier cantidad de preguntas multifacéticas. En la práctica, a menudo solo solicita la contraseña del usuario.

Si desea deshabilitar por completo la autenticación basada en contraseña, configure AMBAS contraseña de autenticación y ChallengeResponseAuthentication en 'no'. Si eres de la mentalidad de cinturón y tirantes, considera configurar UsePAM en 'no' también.

La autenticación basada en clave pública / privada (habilitada por la configuración de Autenticación Pubkey) es un tipo separado de autenticación que no implica enviar contraseñas de usuario al servidor, por supuesto.

Algunos argumentarán que usar ChallengeResponseAuthentication es más seguro que PasswordAuthentication porque es más difícil de automatizar. Por lo tanto, recomiendan dejar PasswordAuthentication deshabilitado y dejar ChallengeResponseAuthentication habilitado. Esta configuración también fomenta (pero no necesariamente impide) el uso de la autenticación de clave pública para los inicios de sesión automatizados del sistema. Pero, dado que SSH es un protocolo basado en la red, el servidor no tiene forma de garantizar que las respuestas a ChallengeResponseAuthentication (también conocido como 'teclado interactivo') sean realmente proporcionadas por un usuario sentado en un teclado siempre que el (los) desafío (s) siempre y solo consiste en pedirle al usuario su contraseña.

Izzy
fuente
77
Agradecería alguna explicación de lo que UsePAMhace ...
Alexey
3

PasswordAuthentication es la implementación más fácil, ya que no hay nada que hacer. La contrapartida es que envía su contraseña, a través de una conexión cifrada, al servidor. Esto puede ser un problema de seguridad si el servidor se ha visto comprometido, ya que la contraseña podría ser capturada.
Con la clave pública, su contraseña no se transmite al servidor, es más segura pero necesita más configuración.

kaklon
fuente
Esta respuesta es un poco antigua, pero me gustaría agregar algo: lo mejor de la autenticación de Pubkey es que no se transmiten secretos al servidor. La clave privada permanece secreta en su computadora, es decir, no puede transmitir accidentalmente ningún tipo de secreto a un servidor comprometido o MITM. Entonces Pubkey es definitivamente favorable sobre la autenticación de contraseña. Pero de todos modos, sí, la autenticación de contraseña es mucho más fácil de implementar.
Jan D
No sería una molestia configurarlo, solo a la par de ser perezoso para no hacerlo.
sudo
0

Puede establecerlo en no cuando use las teclas o forzar su uso.

Ignacio Vazquez-Abrams
fuente