Como usar o servidor ssh com PAM, mas não permitir a autenticação de senha?

Muitos tutoriais dizem para você configurar seu servidor ssh assim:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no 

mas com essa configuração, você não pode usar o PAM, pois pretendo usar a autenticação de 2 fatores com o Google Authenticator (senha única do OTP), preciso do PAM.

Então, como configurar um novo debian jessie ssh deamon, se eu quiser impedir o login com a senha normal, mas ainda permitir o uso do PAM.

talvez a pergunta exata seja como configurar o pam para não permitir senhas?

Detalhes sobre autenticação PAM

Desabilitar a autenticação de senha baseada em PAM não é intuitivo. É necessário em praticamente todas as distribuições GNU / Linux (com a exceção notável do Slackware), juntamente com o FreeBSD. Se você não tomar cuidado, pode ter o PasswordAuthentication definido como 'no' e ainda fazer login com apenas uma senha através da autenticação PAM. Acontece que você precisa definir 'ChallengeResponseAuthentication' como 'no' para realmente desativar a autenticação do PAM. As páginas do manual do FreeBSD têm a dizer, o que pode ajudar a esclarecer um pouco a situação:

Observe que se ChallengeResponseAuthentication for 'yes', e a política de autenticação PAM para sshd incluir pam_unix (8), a autenticação de senha será permitida através do mecanismo de desafio-resposta, independentemente do valor de PasswordAuthentication.

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

talvez a pergunta exata seja como configurar o pam para não permitir senhas?

Corrigir. Você já se deparou com o fato de que a configuração UsePAM nogeralmente é um mau conselho. Além de impedir qualquer forma de autenticação baseada em PAM, também desativa accounte sessionmodula. Controle de acesso e configuração de sessão são coisas boas.

Primeiro, vamos criar uma lista de requisitos:

• OTP via pam_google_authenticator.so. Isso requer UsePAM yese ChallengeResponseAuthentication yes. Você está solicitando uma credencial, afinal!
• Nenhuma outra forma de autenticação de senha via PAM. Isso significa desativar qualquer authmódulo que possa permitir que uma senha seja transmitida por keyboard-interactivelogins. (que precisamos deixar habilitado para o OTP)
• Autenticação baseada em chave. Precisamos exigir publickeyautenticação e, talvez, gssapi-with-micse você tiver o Kerberos configurado.

Normalmente, a autenticação com uma chave ignora completamente a autenticação baseada em PAM. Isso teria nos parado em nossas trilhas com versões mais antigas do openssh, mas o Debian 8 (jessie) suporta a AuthenticationMethodsdiretiva. Isso nos permite exigir vários métodos de autenticação, mas funciona apenas com clientes que implementam SSHv2.

configuração sshd

Abaixo estão as linhas que eu sugiro /etc/ssh/sshd_config. Certifique-se de ter uma maneira de acessar este sistema sem sshdquebrar alguma coisa!

# 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

Não se esqueça de recarregar sshddepois que essas alterações forem feitas.

Configuração do PAM

Ainda temos que configurar o PAM. Assumindo uma instalação limpa do Debian 8 (de acordo com sua pergunta):

• Comentário @include common-authde /etc/pam.d/sshd.
• Revise /etc/pam.d/sshde confirme se nenhuma linha que começa com authestá presente. Não deveria haver uma instalação limpa, mas é melhor estar seguro.
• Adicione uma authentrada para pam_google_authenticator.so.

Lembre-se de que as senhas locais ainda funcionam.

Não fizemos nenhuma alteração que impactasse os logins por meio de um console local ou impedisse que os usuários usassem senhas para atualizar seus privilégios via sudo.Isso estava fora do escopo da pergunta. Se você decidir levar as coisas adiante, lembre-se de que sempre deve ser permitido ao root fazer login localmente via senha. Você corre o risco de se bloquear acidentalmente do sistema.

proibir a solicitação de senha

comente esta linha

#auth       substack     password-auth

em /etc/pam.d/sshd

e certifique-se de não ter nullok no final desta linha, a menos que seja bom autenticar via ssh sem usar o OTP

auth required pam_google_authenticator.so