
He seguido las instrucciones de Redhat sobre cómo reforzar la autenticación en un servidor Linux, pero solo usamos SSH con autenticación de clave pública. Según estas instrucciones: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-hardening_your_system_with_tools_and_services
Aquí están mis archivos /etc/pam.d/system-auth y /etc/pam.d/password-auth, ambos son iguales en realidad:
#%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
Con esta configuración, esperaba lograr algún tipo de mensaje de bloqueo si el usuario intenta autenticarse con la clave incorrecta después de 3 intentos, por ejemplo. Pero no aparece ningún mensaje sobre el bloqueo y no tengo forma de saber si la política de bloqueo está funcionando o no. También existe el módulo pam_tally2, pero no veo qué diferencia haría con el módulo pam_faillock.
Los registros no muestran nada excepto que se denegó el permiso de root:
[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
Y he intentado usar la clave incorrecta para ssh some_user
y no parece bloquearme porque no veo nada en los registros de bloqueo de fallas ni ningún mensaje ssh desde donde intento realizar ssh.
Respuesta1
El problema es que estás intentando hacer cumplir estas políticas dentro de la pila de autenticación.
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
La autenticación de clave pública implementada dentro del propio demonio SSH omite la pila de autenticación. (no se llama a ningún módulo de autenticación PAM para validar la clave enviada, por lo que tiene que funcionar de esa manera) La única excepción es cuando ejecuta una configuración personalizada que también requiere éxito dentro del teclado interactivo. Dado que este no es el valor predeterminado, es casi seguro que su pila de autenticación se ignora durante estas autenticaciones.
Mientras la account
pila estágeneralmentedonde impone restricciones a los inicios de sesión solo con clave pública, no creo que eso funcione aquí, ya que primero tendría que autenticarse correctamente para poder llamar al módulo PAM. Si no se llama a su módulo PAM, no podrá incrementar un recuento con cada inicio de sesión fallido.
La única forma en que puedo ver que esto funcione es si ajusta su configuración sshd para requerir autenticación interactiva con el teclado.además deautenticación de clave pública. (puedes usarestas preguntas y respuestascomo punto de partida) Dicho esto, como señala JohnA, es discutible si esto realmente proporcionaría algún valor.
Respuesta2
Estoy bastante seguro de que no podrás utilizar PAM en esta capacidad. Si el usuario no tiene la clave privada ssh que corresponde a la clave pública ssh en el servidor, no podrá autenticarse.
El propósito del bloqueo por falla de contraseña es evitar la fuerza bruta de la contraseña en una cuenta de usuario. Si se aplica la autenticación de clave ssh, no hay ninguna contraseña de cuenta de usuario que deba tenerse en cuenta.
En el caso de la contraseña que se solicita para la autenticación de clave ssh, esta es la contraseña de la clave privada. No autenticarse con la clave privada no produce ningún error de autenticación en el servidor.