Thanks to the answers to this question, I've been happily generating Kickstart files for Scientific Linux 6 and 7 for the past 5 years. However, we're now starting to build out some test systems with CentOS 8 and running into some issues.
Despite using the same method for generating hashes (or indeed, reusing the very same hashes) the passwords for the users are not being set correctly. I've been unable to find any documentation suggesting there's been a change between EL 7 and 8.
Here's a test user I'm creating in the Kickstart file:
user --homedir=/var/ftp --name=A3857275828 --password=$6$J52QJaSjIt8GGqRS$4YyusOJ5EtpikCdwgXJrorW7XyiLRCT.jjRZsHLv04ZV7ng8wTdrwFUF2u5QXGWiEmDgu/g9RpXxLKPoRD4Kh0 --iscrypted --shell=/usr/sbin/nologin --uid=5001 --gid=5001
The password should be 9282759601013452 but logins are failing until I manually change the password using the passwd utility. I'm seeing the same failures on all non-privileged accounts created but the root password works fine. Password-based logins have been tested using both SSH and FTP (vsftpd backed by PAM.)
/var/log/anaconda/journal.log shows nothing interesting during the setup process:
Jun 26 20:52:17 test.test.local anaconda[1946]: program: Running... useradd -R /mnt/sysimage -g 5001 -d /var/ftp -M -s /usr/sbin/nologin -u 5001 A3857275828
Jun 26 20:52:17 test.test.local useradd[35591]: new user: name=A3857275828, UID=5001, GID=5001, home=/var/ftp, shell=/usr/sbin/nologin
The entry in /etc/shadow has the same hash specified in the Kickstart file:
A3857275828:$6$J52QJaSjIt8GGqRS$4YyusOJ5EtpikCdwgXJrorW7XyiLRCT.jjRZsHLv04ZV7ng8wTdrwFUF2u5QXGWiEmDgu/g9RpXxLKPoRD4Kh0::0:99999:7:::
And after updating with passwd, it's still a valid SHA-512 hash:
A3857275828:$6$SP6IoLdZemXHZbxp$E3/Owe7mciCkeuHdiX4ZnZDUWmTz3nDqa885Rnc3rHMZcPharyX0QSdsUTq3gMneSNsmD1V.FmRf5HCY.uZqH0:18452:0:99999:7:::
The only other file that's touched during a password update is /var/lib/sss/mc/passwd. However, I'm not using authselect in my Kickstart file and authselect current says "No existing configuration detected." From what I've read, this should mean that sssd is out of the picture (anyway, as far as I can see, it's only used for external authentication.)
PAM config is untouched from the default, and I've added the debug option to pam_unix.so but am not getting much verbosity out of it:
Jul 10 17:00:06 pbxtest login[972]: pam_unix(login:auth): username [admin] obtained
Jul 10 17:00:08 pbxtest login[972]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=admin
Jul 10 17:00:10 pbxtest login[972]: FAILED LOGIN 1 FROM tty1 FOR admin, Authentication failure
In the event I'm misunderstanding SSSD, here is /etc/nsswitch.conf:
passwd: sss files systemd
shadow: files sss
group: sss files systemd
hosts: files dns myhostname
services: files sss
netgroup: sss
automount: files sss
aliases: files
ethers: files
gshadow: files
networks: files dns
protocols: files
publickey: files
rpc: files
(Which, now that I look at it, seems like sssd is getting in the way of things.) There are no files under /etc/sssd/ and the status looks like this:
● sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-10-22 17:16:49 EDT; 6 days ago
Main PID: 899 (sssd)
Tasks: 3 (limit: 4428)
Memory: 6.4M
CGroup: /system.slice/sssd.service
├─899 /usr/sbin/sssd -i --logger=files
├─940 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
└─944 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
Any thoughts on why I'm unable to log in with the expected password until setting it with passwd?
