Objetivo
Para dispositivos móveis, desejamos adicionar uma camada extra de segurança exigindo um código PIN no login do ssh. O acesso móvel é apenas um serviço de conveniência (os usuários podem sempre retirar seus laptops) e as contas devem ser bloqueadas permanentemente após três tentativas no código PIN (os administradores podem desbloquear uma conta). Os administradores gerarão um novo PIN aleatório ao desbloquear.
Método
Para solicitar uma senha após a autenticação de chave pública, adicionei o seguinte a /etc/ssh/sshd_config :
Match Group RequireSSHPassword
AuthenticationMethods publickey,password
Qualquer usuário que esteja no grupo RequireSSHPassword será solicitado por uma senha além da autenticação de chave pública. UsePAM está definido como yes anterior no arquivo de configuração. A tentativa de adicionar isso ao Match resulta em sshd falha ao iniciar ("Diretiva 'UsePAM' não é permitida dentro de um bloco de Correspondência").
Para o bloqueio, o módulo PAM pam_tally2 parece ser o caminho a percorrer.
Isso é o que não funciona.
De acordo com esta pergunta no Superusuário , Adicionei as seguintes linhas a /etc/pam.d/common-password :
auth required pam_tally2.so file=/var/log/tallylog deny=3 onerr=fail
account required pam_tally2.so
Eu também tentei adicionar apenas a linha auth , ou adicionar uma ou ambas a /etc/pam.d/sshd , ou adicionar a linha account a /etc/pam.d/common-account , ou embaralhar a ordem das linhas, tudo sem sucesso. O ambiente é o Debian Stretch (teste).
O arquivo /var/log/tallylog não é criado ao tentar efetuar login com uma senha incorreta. Depois de usar o comando pam_tally2 --user=test , o arquivo é criado e vazio. Depois de usar o comando pam_tally2 --user=test --reset=3 , o arquivo é preenchido com dados binários de 64K. A utilização de pam_tally2 --user=test mostra agora 3 tentativas falhadas sem origem (conforme esperado).
Ao tentar efetuar login enquanto a contagem é definida como 3 (para que o usuário seja bloqueado), não posso. Nenhum erro é dado, apenas diz que a tentativa de login falhou (como se eu tivesse usado uma senha inválida). Então parece que realmente funciona. No entanto, ao redefinir a contagem para 0, posso fazer 3 tentativas com senha incorreta e ainda fazer o login em uma quarta tentativa. Usando pam_tally2 --user=test , o número de falhas ainda é 0, mesmo que eu faça 1 tentativa com uma senha incorreta e feche a conexão ssh.
A limitação parece estar em vigor quando eu atualizar manualmente o contador de registro, mas o contador de registro não parece ser atualizado, se eu interpretar eventos corretamente.
Em /var/log/auth.log , posso ver as tentativas de login com falha para o usuário. De todos os testes, houve duas mensagens em auth.log do registro:
Mar 6 11:36:17 HOST sshd[18906]: pam_tally2(sshd:auth): user test (1xxx) tally 4, deny 3
Mar 6 12:49:40 HOST sshd[20392]: pam_tally2(sshd:account): option deny=3 allowed in auth phase only
O último veio quando tentei especificar as opções na linha account (adicionalmente à linha auth ). O primeiro provavelmente veio de tentar efetuar login depois de manualmente ter resetado logins com falha para 3.
Alterando o modo de tallylog para 0777 , erros sobre a possibilidade de gravação global. Alterar o proprietário para sshd no modo 0774 não altera nada (apenas no caso de o ssh não ter permissões de gravação para tallylog , que por padrão estava no modo 0600 com proprietário e grupo root ).
Por causa das mensagens de log e por causa do bloqueio após usar --reset=3 , acredito que o módulo está sendo usado. Por algum motivo, parece não notar logins com falha ou não conseguir atualizar o tallylog . Como eu poderia depurar isso? Ou devo usar outra coisa em vez disso?
A propósito, fail2ban é outra solução comum que revi. No entanto, o manual para a versão mais recente (0.8) menciona que funciona varrendo os arquivos de log a cada segundo. Como diz o manual, "Muitos daemons do syslog armazenam em buffer suas saídas". Além disso, muitas tentativas de login podem ser realizadas em um único segundo por paralelização. O Fail2ban não é adequado neste caso, em que o objetivo não é bloquear tentativas de força bruta em contas normais, mas bloquear um atacante especializado que já tenha minha chave privada e precise agora de brutar alguns dígitos.