nss-systemd can make sshd treat the root account as locked

[angelsl]

On my Debian 12 system, /etc/nsswitch.conf (on the system) has

passwd:         files systemd
group:          files systemd
shadow:         files systemd
gshadow:        files systemd

Normally /etc/nsswitch.conf isn't included in the initramfs, but some dracut modules cause it to be pulled in, e.g. the nfs module.

nss-systemd by default returns a synthetic entry for root shadow:

# getent -s systemd shadow root
root:!*:::::::

which as we know causes opensshd to refuse logins as root.

Two things need to be true for this to happen:

1. your initramfs has no /etc/shadow (or /etc/shadow has no entry for root)
2. your initramfs gets a /etc/nsswitch.conf that has systemd as a source for the shadow database

...of which (2) became true for me after I set up NFS one random day, and then I spent a few hours trying to figure out why sshd was saying root was locked.

Just leaving this here in case someone else runs into this issue..

[mhymny]

What would a correct approach be?
I disabled authselect(sudo authselect opt-out) and then fixed the shadow entry.
It seems like systemd is a default, as seen in /usr/share/authselect/default/local/nsswitch.conf :

# In order of likelihood of use to accelerate lookup.
passwd:     files {if "with-altfiles":altfiles }systemd
shadow:     files systemd
group:      files [SUCCESS=merge] {if "with-altfiles":altfiles [SUCCESS=merge] }systemd
hosts:      files myhostname {if "with-libvirt":libvirt libvirt_guest }{if "with-mdns4" and "with-mdns6":mdns_minimal [NOTFOUND=return] }{if "with-mdns4" and not "with-mdns6":mdns4_minimal [NOTFOUND=return] }{if not "with-mdns4" and "with-mdns6":mdns6_minimal [NOTFOUND=return] }resolve [!UNAVAIL=return] dns
services:   files
netgroup:   files
automount:  files

aliases:    files
ethers:     files
gshadow:    files systemd
networks:   files dns
protocols:  files
publickey:  files
rpc:        files

[creativecoder]

What would a correct approach be?

I have the same question!

Looking through the linked code, I noticed there is a systemd env variable for SYSTEMD_NSS_BYPASS_SYNTHETIC.

I was able to add a kernel arg to set this variable and bypass adding the synthetic user entries. This allowed me to authenticate the root user correctly via ssh during boot without touching authselect.

Here's the kernel arg:

systemd.setenv=SYSTEMD_NSS_BYPASS_SYNTHETIC=1

Here's how I enabled it on my Fedora CoreOS system

sudo rpm-ostree kargs --append "systemd.setenv=SYSTEMD_NSS_BYPASS_SYNTHETIC=1"

[gsauthof]

@creativecoder good find!

---

Perhaps what also plays into this is whether your host system has a root password set (vs. sudo only setup) and whether dracut is configured to hostonly mode (workstation/server Fedora spins seem to default to hostonly=yes since before Fedora 19.

[Whissi]

I also noticed for some time, that dracut-sshd wasn't working on my Debian box. Whenever I tried to login, my login was rejected with message Permission denied (publickey).

Today, after a remote box I just upgraded to Debian 13 failed on reboot and I had to get remote access to fix it, I spent some time debugging.

Once I finally got access to running initramfs system (hint: you may have to set SYSTEMD_SULOGIN_FORCE=1 as kernel parameter), I saw

sshd-session[1100] User root not allowed because account is locked
sshd-session[1100] Connection closed by invalid user root 

This is how the account is locked:

# lsinitrd /boot/initrd.img-6.12.57+deb13-amd64 /etc/shadow
root:!unprovisioned:20418::::::
daemon:!*:20418::::::
bin:!*:20418::::::
sys:!*:20418::::::
sync:!*:20418::::::
games:!*:20418::::::
man:!*:20418::::::
lp:!*:20418::::::
mail:!*:20418::::::
news:!*:20418::::::
uucp:!*:20418::::::
proxy:!*:20418::::::
www-data:!*:20418::::::
backup:!*:20418::::::
list:!*:20418::::::
irc:!*:20418::::::
_apt:!*:20418::::::
nobody:!*:20418::::::
root:$6$fkMhDHjy$...RVlsEeO.:17735:0:99999:7::: 

As you know, dracut tries to lock down initramfs for quiete some time (<2019). This file is being generated by the 60systemd-sysusers module. However, as you can see, it runs very early (60). This is what causing the problem. Upstream has fixed it already: https://github.com/dracut-ng/dracut-ng/pull/1212/files

However, this change isn't landed in Debian yet. This was reported to Debian in end of June 2025 via bug 1108404.

Not sure if this will also address the problem with nss but since multiple "root account is locked" issues are already mentioned in this issue, I am adding this one as an additional reference.

[gsauthof]

@Whissi thanks for sharing this - looks like the change you found fixes the issue reported in #91