You are not logged in.
From reading https://wiki.archlinux.org/title/Securi … n_attempts I can see that my system isn't behaving the way it should by default. I can attempt to log in as many times as I want with being locked out. Tested with GDM, and sudo below :
$ sudo ls
[sudo] password for bob:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
[sudo] password for bob:
Sorry, try again.
[sudo] password for bob:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Password incorrect or not sufficient for authentication of user bob.
Sorry, try again:
Too many unsuccessful login attempts for user bob, refusing.
[sudo] password for bob:
Sorry, try again.
[sudo] password for bob:
..Something apparently is different after 4 attempts, because the messages are different, but there is no lockout and I can keep on trying passwords.
I'm using systemd-homed, can it be related ? I haven't touched anything related to PAM and /etc/security/faillock.conf is the default original file. What else can be wrong here ?
Thanks for your help !
Last edited by Cvlc (2022-07-30 21:04:57)
Offline
As of pambase 20200721.1-2, pam_faillock.so is enabled by default to lock out users for 10 minutes after 3 failed login attempts in a 15 minute period (see FS#67644). The lockout only applies to password authentication (e.g. login and sudo), public key authentication over SSH is still accepted.
You are interpreting that as meaning login will be refused without prompting for a password once faillock has been activated while it will reject any login after a password has been supplied.
Last edited by loqs (2022-07-02 22:28:16)
Offline
Thanks for your answer, but I don't quite understand. I understand from the wiki quote that I should be locked out after 3 unsuccessful attempts, but I'm not. I can try as many times as I want, and as soon as I enter the right password login works.
Offline
After three failed login attempts does
faillock --user $YOURUSERNAMEContain three valid entries?
Last edited by loqs (2022-07-02 22:36:48)
Offline
No, up to 4 attempts, it's empty :
$ faillock --user bob
bob:
When Type Source ValidAt the 5th, when I get "Too many unsuccessful login attempts for user bob, refusing", then it prints one line :
faillock --user bob
bob:
When Type Source Valid
2022-07-03 00:38:24 TTY /dev/pts/0 VAnd after 8 failed, the second line :
faillock --user bob
bob:
When Type Source Valid
2022-07-03 00:38:24 TTY /dev/pts/0 V
2022-07-03 00:39:10 TTY /dev/pts/0 Vand a valid password anytime resets it
Last edited by Cvlc (2022-07-02 22:54:20)
Offline
Is this with sudo? If you create a user that does not use systemd-homed is the result the same?
Offline
this is with sudo, but login from GDM seems to be the same, I can try and try and I'm never locked out. I'll try with a new user and report back
Offline
OK interesting !
So the sudo prompt I was using timed out because I was writing here, with :
[sudo] password for bob:
sudo: timeout while waiting for password
sudo: 2 unsuccessful login attempts on another terminal I typed sudo useradd archie and before I couldtype a password it printed out three lines of "sorry try again" then another which said "3 unsuccessful attempts"
sudo: délai d'attente dépassé durant la lecture du mot de passe
sudo: 2 saisies de mots de passe incorrectes
$ sudo useradd archie
[sudo] Mot de passe de bob :
Désolé, essayez de nouveau.
Désolé, essayez de nouveau.
sudo: 3 saisies de mots de passe incorrectes
$ sudo useradd archie
[sudo] Mot de passe de bob :
Désolé, essayez de nouveau.
Désolé, essayez de nouveau.
sudo: 3 saisies de mots de passe incorrectes
$ sudo ls
[sudo] Mot de passe de bob :
Désolé, essayez de nouveau.
Désolé, essayez de nouveau.
sudo: 3 saisies de mots de passe incorrectesSo I was locked out. but only for a minute or so, now it works again
Offline
Tried with a regular user, I get nothing at all in faillock after unsuccessful attempts (it doesn't even print out the table like above) :
$ sudo useradd archie
$ sudo pwd archie
$ su archie
Password:
su: Authentication failure
$ su archie
Password:
su: Authentication failure
$ su archie
Password:
su: Authentication failure
....Last edited by Cvlc (2022-07-02 23:11:49)
Offline
Sanity check what is the output of
pacman -Qikk pam pambase
cat /etc/pam.d/system-authOffline
$ pacman -Qikk pam pambase
Name : pam
Version : 1.5.2-1
Description : PAM (Pluggable Authentication Modules) library
Architecture : x86_64
URL : http://linux-pam.org
Licenses : GPL2
Groups : None
Provides : libpam.so=0-64 libpamc.so=0-64 libpam_misc.so=0-64
Depends On : glibc libtirpc pambase audit libaudit.so=1-64 libxcrypt libcrypt.so=2-64
Optional Deps : None
Required By : apparmor cifs-utils freerdp gnome-keyring kbd libcap libpwquality oath-toolkit openssh polkit
qemu-img qemu-pr-helper qemu-system-x86 shadow sudo systemd util-linux
Optional For : snapper
Conflicts With : None
Replaces : None
Installed Size : 2.69 MiB
Packager : Levente Polyak <anthraxx@archlinux.org>
Build Date : Wed Sep 8 23:18:52 2021
Install Date : Wed Sep 22 18:54:02 2021
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
backup file: pam: /etc/environment (Modification time mismatch)
backup file: pam: /etc/environment (Size mismatch)
backup file: pam: /etc/environment (MD5 checksum mismatch)
backup file: pam: /etc/environment (SHA256 checksum mismatch)
pam: 555 total files, 0 altered files
Name : pambase
Version : 20211210-1
Description : Base PAM configuration for services
Architecture : any
URL : https://www.archlinux.org
Licenses : GPL
Groups : None
Provides : None
Depends On : None
Optional Deps : None
Required By : pam
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 2.68 KiB
Packager : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date : Fri Dec 10 14:53:02 2021
Install Date : Mon Dec 13 11:34:44 2021
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
pambase: 8 total files, 0 altered filescat /etc/pam.d/system-auth
#%PAM-1.0
auth required pam_faillock.so preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
auth optional pam_permit.so
auth required pam_env.so
auth required pam_faillock.so authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.
-account [success=1 default=ignore] pam_systemd_home.so
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so
-password [success=1 default=ignore] pam_systemd_home.so
password required pam_unix.so try_first_pass nullok shadow sha512
password optional pam_permit.so
-session optional pam_systemd_home.so
session required pam_limits.so
session required pam_unix.so
session optional pam_permit.soThanks for your help. There's stuff about pam_systemd_home.. Reading into it now
Offline
systemctl status systemd-tmpfiles-setup.service
ls -la /run/faillock/Offline
$ sudo systemctl status systemd-tmpfiles-setup.service
[sudo] password for bob:
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
Active: active (exited) since Sat 2022-07-02 16:18:45 CEST; 10h ago
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Process: 497 ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=0/SUCCESS)
Main PID: 497 (code=exited, status=0/SUCCESS)
CPU: 19ms
Jul 02 16:18:45 systemd[1]: Starting Create Volatile Files and Directories...
Jul 02 16:18:45 systemd[1]: Finished Create Volatile Files and Directories.ls -la /run/faillock/
total 0
drwxr-xr-x 2 root root 60 2 juil. 16:18 .
drwxr-xr-x 28 root root 640 2 juil. 16:18 ..
-rw-rw---- 1 bob root 0 3 juil. 02:36 bobOffline
What if you #comment the pam_systemd_home.so lines in /etc/pam.d/system-auth (PSA: always keep a root shell open while messing with PAM)
Online
Well the man page says that this is what enables login with systemd homed so not sure I would want to mess with the defaults.
Offline
You also want to know what's messing w/ pam_faillock.
Since pam_homed is reasonably suspected, taking it out of the equation will clarify whether the problem lies there.
Once you know where the problem is, you can focus on how to solve it.
Online
Ok, commenting out the lines reverts to the standard behaviour, I was able to lock myself out after three attempts and then had to unlock myself with faillock --reset
I wonder what the consequences of leaving the comments can be on systemd-homed though. And why the lines are there in the first place
Offline
You need the pam_systemd_home.so entries in order to login with systemd-homed.
What if you change
-auth [success=2 default=ignore] pam_systemd_home.soto
-auth [success=2 default=bad] pam_systemd_home.soAs before keep a root terminal open so you can revert the change after testing and avoid locking yourself out.
Offline
Setting
-auth [success=2 default=bad] pam_systemd_home.so reverts back to the original behaviour (I am not locked out after 3 attempts)
By the way I was apparently able to log in with the lines commented out. Unsure if everything was ok in the background though.
Last edited by Cvlc (2022-07-03 15:07:02)
Offline
Did you set "default=bad" for all three pam_systemd_home.so entries?
Edit:
https://man.archlinux.org/man/core/syst … ESCRIPTION
in sub-sessions it's hopefully idempotent in its core function.
Last edited by seth (2022-07-03 15:20:10)
Online
Wait a second, pam_systemd_home.so jumps "pam_faillock.so authfail" on "success" and it likely "succeeds" all the time.
…
-auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
…=> don't let it skip pam_unix and pam_faillock (the manpage example doesn't have pam_systemd_home.so preceeding pam_unix.so, so I'm not sure why we have it jump it - and faillock)
…
-auth [default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
…disclaimer: pam_systemd_home is and will remain commented here, I don't really care about this … well, "it"
Online
The use of jump is because only one of pam_systemd_home.so and pam_unix should succeed and on that success skip overfaillock which records the failed attempt and die returns immediately.
The alternate structure would be to use a substack e.g.
-auth sufficient pam_systemd_home.so
auth sufficient pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
-account sufficient pam_systemd_home.so
account sufficient pam_unix.so
account required pam_deny.so
-password sufficient pam_systemd_home.so
password sufficient pam_unix.so try_first_pass nullok shadow
password required pam_deny.so#%PAM-1.0
auth required pam_faillock.so preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
auth substack system-auth-substack
auth required pam_env.so
account required pam_faillock.so authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.
account substack system-auth-substack
account required pam_time.so
password substack system-auth-substack
session required pam_limits.so
-session optional pam_systemd_home.so
session required pam_unix.soLast edited by loqs (2022-07-03 15:56:26)
Offline
Ah, the homed wiki mentions some ~/.identity which can function as authenticator.
But doesn't that mean that once the $HOME is mounted, pam_systemd_home.so will succeed no matter what and *anyone* can subsequently "authenticate" as that user?
I'm not sure how this can be at the "sufficient" top of the stack?
(Again: not gonna use that, so please excuse if I'm asking dumb questions)
Online
The ordering of the entries was reversed for https://bugs.archlinux.org/task/72967
Edit:
See also https://github.com/systemd/systemd/issu … -889130469
Last edited by loqs (2022-07-03 19:38:14)
Offline
@Cvlc, you're aware of https://man.archlinux.org/man/community … mount.8.en are you?
Online