A production server stayed up, but root could not log in with the correct password. The cause was a corrupted /etc/login.defs. We restored it from the package through rescue mode, with no password resets.
29 September 2026 · 3 min read
TRIGGER
Corrupted /etc/login.defs
PLATFORM
RHEL-family Linux, SELinux enforcing
ACCESS PATH
Rescue mode and chroot
ENGAGEMENT
Emergency access recovery
File replaced, nothing else touched
Passwords reset
Checks before return to normal
Scroll the diagram sideways to see all of it →
Package verification found the one layer that had changed.
The server was up, but root could not get in. Root authentication suddenly stopped working on a production Linux server. The server and its services were still running, but administrators could no longer log in as root. The root password was correct and the account was valid, so the failure had to be in the authentication configuration, not the credentials.
Verify the stack, not the password. We reviewed the authentication log (/var/log/secure), checked for lockouts with faillock, inspected ownership and SELinux contexts on the authentication files, and verified every package in the login path with rpm -V: shadow-utils, pam, util-linux and openssh-server. The account was not locked or expired. The finding came from package verification: rpm -V shadow-utils showed that /etc/login.defs no longer matched the installed package, and inspection confirmed the file was corrupted.
A correct root password does not guarantee that root authentication will succeed.
A corrupted /etc/login.defs. /etc/login.defs is read by the Linux login and account-management stack. With the file damaged, root authentication could not complete, even though the account and password were correct.
Root login failed with a correct password while the server kept running.
Check every authentication layer and let package verification find the changed file.
Root access restored by replacing one file: no password resets, no accounts lost, no application data affected.
Preserve, restore from the package, relabel. With root login unavailable, we booted into rescue mode, remounted the root filesystem read-write and entered the installed system with chroot. The damaged file was preserved first for later analysis. A clean /etc/login.defs was extracted from the matching shadow-utils package with rpm2cpio, compared with the damaged copy using diff, and put in place. restorecon then corrected its SELinux context, and the server was rebooted normally.
Root access restored, nothing else changed. Root login worked again with the existing password. rpm -V shadow-utils came back clean, /etc/passwd and /etc/shadow were intact, pwck -r and grpck -r passed, password changes and test-user creation worked, SELinux contexts on the authentication files were correct, and no new authentication errors appeared in the logs. The damaged file was kept for root-cause analysis.
We work through the authentication stack layer by layer, find what actually changed and restore only that, without resetting passwords or touching your data.
