You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are setting a maximum password age in /etc/login.defs. This automatically applies to all created users and also affects users without a password, eg. when creating a user to use for SSH key based login. The login will stop working afer the maximum password age has been reached.
user without password has a expiry date and SSH login will fail, once the date has been reached:
# chage -l testuser
Last password change : Jun 05, 2023
Password expires : Aug 04, 2023
Password inactive : never
Account expires : never
Minimum number of days between password change : 7
Maximum number of days between password change : 60
Number of days of warning before password expires : 7
Solution
Key based SSH login shoud keep working for all users. Currently we create the potential for our users to lock themselves out of their systems after the password expiry date is reached.
Alternatives
There are several possible solutions to this. The main Problem boils down to this being an issue with communication between PAM and OpenSSH. I see several courses of action:
use our variable os_users_without_password_ageing to actively disable password ageing for specific users. This may be missed and is hard to keep up-to-date
create some new tasks to unset password ageing for all users without password. This would only work when os_hardening is applied regulary. (similar to
use our variable os_users_without_password_ageing to actively disable password ageing for specific users. This may be missed and is hard to keep up-to-date
Agreed. We already have this and it didn't help.
create some new tasks to unset password ageing for all users without password
I think, we should implement this anyway. We may get in unexpected situations with that, when one user works and the other doesn't - but that's a trade-off I'd do.
make SSH ignore password expiry via PAM. This could create a security problem
When SSH only allows PubKey-Auth, I don't really see a security-problem here. What do you think? And according to one answer, the pam-functionality is not included in ubuntu 18.04 (we'd have to verify).
find some way to give users a clear feedback before the accounts are locked
I don't see a good way to do this.
Maybe add a task, that checks if users exist that have no password and then fail the play. But then again we could just change the expiry as expressed above.
My proposal:
Create the task to unblock users without password
Disable the expiry-check when logging in via ssh and with PubKey.
Description
We are setting a maximum password age in
/etc/login.defs
. This automatically applies to all created users and also affects users without a password, eg. when creating a user to use for SSH key based login. The login will stop working afer the maximum password age has been reached.see:
ansible-collection-hardening/roles/os_hardening/templates/etc/login.defs.j2
Line 107 in 0e173b4
Playbook for creating an affected user:
user without password has a expiry date and SSH login will fail, once the date has been reached:
Solution
Key based SSH login shoud keep working for all users. Currently we create the potential for our users to lock themselves out of their systems after the password expiry date is reached.
Alternatives
There are several possible solutions to this. The main Problem boils down to this being an issue with communication between PAM and OpenSSH. I see several courses of action:
os_users_without_password_ageing
to actively disable password ageing for specific users. This may be missed and is hard to keep up-to-dateansible-collection-hardening/roles/os_hardening/tasks/user_accounts.yml
Lines 34 to 45 in 0e173b4
Additional information
The interaction between PAM and OpenSSH is a bit complicated. A good and short explaination can be found here: https://unix.stackexchange.com/questions/160268/expired-password-and-ssh-key-based-login-with-usepam-yes/160321#160321
The text was updated successfully, but these errors were encountered: