Como usar o PAM para gerenciar a política de bloqueio dos métodos de autenticação de chave pública ssh

Question

Eu segui as instruções no redhat sobre como endurecer a autenticação em um servidor linux, mas só usamos SSH com autenticação de chave pública. De acordo com estas instruções: link

Aqui estão meus arquivos /etc/pam.d/system-auth e /etc/pam.d/password-auth, na verdade são os mesmos:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_faillock.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Com esta configuração, eu esperava conseguir algum tipo de mensagem de bloqueio se o usuário tentasse autenticar com a chave errada após 3 tentativas, por exemplo. Mas nenhuma mensagem sobre bloqueio aparece, e não tenho como saber se a política de bloqueio está funcionando ou não. Existe também o módulo pam_tally2, mas não vejo a diferença que faria com o módulo pam_faillock.

Os registros não mostram nada, exceto a permissão raiz negada:

[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/some_user
[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/root 
cat: /var/run/faillock/root: Permission denied

E eu tentei usar a chave errada para ssh para some_user , e isso não parece me bloquear porque eu não vejo nada nos logs faillock ou qualquer mensagem ssh de onde eu tento ssh.

    

Answer 1

O problema é que você está tentando impor essas políticas dentro da pilha de autorização.

auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_faillock.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

Autenticação de chave pública implementada no próprio daemon SSH ignora a pilha de autenticação. (não há nenhum módulo de autenticação do PAM sendo chamado para validar a chave enviada, por isso tem que funcionar dessa maneira). A única exceção é quando você está executando uma configuração personalizada que requer sucesso dentro do teclado interativo também. Como esse não é o padrão, sua pilha de autenticação quase certamente está sendo ignorada durante essas autenticações.

Embora a pilha account seja geralmente onde você impõe restrições nos logins apenas de chave pública, não acredito que funcionem aqui como você teria primeiro que ter sucesso na autenticação para que o Módulo PAM a ser chamado. Se o seu módulo PAM não está sendo chamado, não é possível incrementar uma contagem a cada login com falha.

A única maneira de ver isso funcionando é ajustar a configuração do sshd para exigir autenticação interativa com teclado além da autenticação de chave pública. (você pode usar este Q & A como ponto de partida) Dito isso, como JohnA aponta, é discutível se isso realmente forneceria algum valor.

    

Answer 2

Tenho certeza de que você não poderá usar o PAM nessa capacidade. Se o usuário não tiver a chave privada ssh que corresponde à chave pública ssh no servidor, ela não poderá se autenticar.

O objetivo do bloqueio de falha de senha é impedir a força bruta da senha em uma conta de usuário. Se a autenticação da chave ssh for aplicada, não haverá senha da conta do usuário para levar em conta.

No caso da senha que é solicitada para a chave de autenticação ssh, esta é a senha da chave privada. A falha na autenticação em relação à chave privada não resulta em qualquer falha de autenticação no servidor.