¿Cómo usar el servidor ssh con PAM pero no permitir la autenticación de contraseña?

Muchos tutoriales le dicen que configure su servidor ssh de esta manera:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no 

pero con esta configuración no puede usar PAM, ya que planeo usar 2 Factor Auth con Google Authenticator (OTP Onetime Password) necesito PAM.

Entonces, cómo configurar un nuevo debian jessie ssh deamon, si quiero evitar el inicio de sesión con la contraseña normal pero aún así permitir el uso de PAM.

tal vez la pregunta exacta es ¿cómo configurar pam para no permitir contraseñas?

Detalles sobre la autenticación PAM

Deshabilitar la autenticación de contraseña basada en PAM es bastante poco intuitivo. Se necesita en casi todas las distribuciones de GNU / Linux (con la notable excepción de Slackware), junto con FreeBSD. Si no tiene cuidado, puede configurar PasswordAuthentication en 'no' e iniciar sesión con solo una contraseña a través de la autenticación PAM. Resulta que necesita establecer 'ChallengeResponseAuthentication' en 'no' para deshabilitar realmente la autenticación PAM. Las páginas de manual de FreeBSD tienen esto que decir, lo que puede ayudar a aclarar un poco la situación:

Tenga en cuenta que si ChallengeResponseAuthentication es 'yes', y la política de autenticación PAM para sshd incluye pam_unix (8), la autenticación de contraseña se permitirá a través del mecanismo de desafío-respuesta, independientemente del valor de PasswordAuthentication.

http://www.unixlore.net/articles/five-minutes-to-more-secure-ssh.html

tal vez la pregunta exacta es ¿cómo configurar pam para no permitir contraseñas?

Correcto. Ya te has topado con el hecho de que la configuración UsePAM nogeneralmente es un mal consejo. No solo evita cualquier forma de autenticación basada en PAM, sino que también deshabilita accounty sessionmodula. El control de acceso y la configuración de la sesión son cosas buenas.

Primero, construyamos una lista de requisitos:

• OTP vía pam_google_authenticator.so. Esto requiere UsePAM yesy ChallengeResponseAuthentication yes. ¡Les estás pidiendo una credencial, después de todo!
• Ninguna otra forma de autenticación de contraseña a través de PAM. Esto significa deshabilitar cualquier authmódulo que pueda permitir que se transmita una contraseña a través de keyboard-interactiveinicios de sesión. (que tenemos que dejar habilitado para OTP)
• Autenticación basada en clave. Necesitamos requerir publickeyautenticación, y tal vez gssapi-with-micsi tiene Kerberos configurado.

Normalmente, la autenticación con una clave omite la autenticación basada en PAM por completo. Esto nos habría detenido en nuestras pistas con versiones anteriores de openssh, pero Debian 8 (jessie) es compatible con la AuthenticationMethodsdirectiva. Esto nos permite requerir múltiples métodos de autenticación, pero solo funciona con clientes que implementan SSHv2.

sshd config

Debajo están las líneas que sugiero /etc/ssh/sshd_config. ¡Asegúrate de tener una forma de acceder a este sistema sin tener sshdque romper algo!

# Require local root only
PermitRootLogin no

# Needed for OTP logins
ChallengeResponseAuthentication yes
UsePAM yes

# Not needed for OTP logins
PasswordAuthentication no

# Change to to "yes" if you need Kerberos. If you're unsure, this is a very safe "no".
GSSAPIAuthentication no


# Require an OTP be provided with key based logins
AuthenticationMethods publickey,keyboard-interactive

# Use this instead for Kerberos+pubkey, both with OTP
#
#AuthenticationMethods gssapi-with-mic,keyboard-interactive publickey,keyboard-interactive

No olvide volver a cargar sshduna vez que se hayan realizado estos cambios.

PAM config

Todavía tenemos que configurar PAM. Asumiendo una instalación limpia de Debian 8 (según su pregunta):

• Comentar @include common-authpartir /etc/pam.d/sshd.
• Revise /etc/pam.d/sshdy confirme que no haya líneas que comiencen con auth. No debería existir si se trata de una instalación limpia, pero es mejor estar seguro.
• Agregar una authentrada para pam_google_authenticator.so.

Recuerde que las contraseñas locales aún funcionan.

No hicimos ningún cambio que pudiera afectar los inicios de sesión a través de una consola local, o evitar que los usuarios usen contraseñas para actualizar sus privilegios a través de sudo.Esto estaba fuera del alcance de la pregunta. Si decide ir más allá, recuerde que siempre se debe permitir que root inicie sesión localmente mediante contraseña. De lo contrario, corre el riesgo de bloquearse accidentalmente del sistema.

para no permitir la solicitud de contraseña

comenta esta línea

#auth       substack     password-auth

en /etc/pam.d/sshd

y asegúrese de no tener nullok al final de esta línea a menos que esté bien autenticarse a través de ssh sin usar OTP

auth required pam_google_authenticator.so