Restrict account login attempts

Rocky Linux Help & Support
7

With caveats…

modify /etc/security/faillock.conf (contains explanatory comments)

then run the command

authselect enable-feature with-faillock

…and that should be it.

You may get the message:

Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.

…but I found sssd wasn’t necessary for faillock to take effect - on ssh or cockpit at any rate (problems with recent fedora releases mean sssd may not be running)

Caveats:

  1. As far as I can gather, for faillock to be comprehensively applied, all access brokering code on the system needs to be PAM compliant.
  2. Faillock does not work/ has no effect on ssh where PubkeyAuthentication yes in /etc/ssh/sshd_config (verified on fedora server 35).

Notes:

I didn’t see any difference in output with/without the faillock silent option.

Thanks

  • @nazunalika for mentioning system-auth and password-auth (one-stop config points)
  • @jlehtone for mentioning authselect (to manage one-stop config points) and trying to explain why things are as they should be.
  • @sweh for mentioning the sshd PubkeyAuthentication exception to the rules and trying harder to explain why things are as they should be.

See also man pages on

  • authselect system-wide, profile-based auth-profile and authentication-feature management
  • faillock to reset user or list the failed logins just prior to account lock
  • pam_faillock faillock configuration
  • lastb failed logins except for sshd with PubkeyAuthentication
  • pam “intended to offer a quick introduction to Linux−PAM”
  • pam.conf “pam.conf, pam.d − PAM configuration files”

Why things are (mostly) as they should be:

It turns out (I wasn’t aware) that responsibility for ensuring that security and system access is implemented in a coherent and sensible manner lies in the first instance with the Distro - it is outside of what the kernel covers.

Thereafter any related changes are the responsibility of the system administrator.

So, there shouldn’t normally be any non-PAM compliant access brokers on a PAM enabled system (ssh with PubkeyAuthentication being the obvious rule breaker).

(This is why the man page for pam.conf reading “When a PAM aware privilege granting application is started…” doesn’t imply that there might as a matter of course be applications running that weren’t PAM aware.)