root user must be unlocked (* not ! in /etc/shadow)

[champtar]

Small PSA, just did a new Fedora 31 install this morning, and since pretty recently dracut now copy the root:... line from system /etc/shadow to etc/shadow in the initramfs, before there was no etc/shadow in initramfs

sshd is launched with UsePAM no in the initramfs, so we need root not to be locked, ie you need
root:*:18343:0:99999:7:::
not
root:!:18343:0:99999:7:::

In my kickstart i was locking root using usermod -p '!' root, which allow me to login to the regular Fedora install, but not the initramfs sshd. It should have been usermod -p '*' root

Quick check:

grep '^root:!' /etc/shadow -q && echo "you need to unlock your root user" || echo "ok"

[HidingCherry]

I confirm this helps.
Though, I don't know yet what it means for security.

[x3ccd4828]

@champtar Do you have any other pointers for getting it to work on Fedora 31?
Your shadow file change helped sshing, however I now have a different problem where I enter the password for decryption but boot sequence is still not unblocked, however I do lose ssh access. At this point I can't even manually enter the decryption password, I actually have to reboot.

[champtar]

It worked with an up to date F31 last weekend, maybe there is a new update since last weekend that broke something, I'll try when I have time.

[gsauthof]

Thank you @champtar for sharing this.

Do you know which dracut module is copying /etc/shadow?

On a Fedora 31 machine of mine, initramfs doesn't contain an etc/shadow and I can't identify a dracut module that does something with shadow:

# lsinitrd | grep shadow
#
$ grep shadow /usr/lib/dracut -r              
/usr/lib/dracut/modules.d/90mdraid/module-setup.sh:    # remove incremental assembly from stock rules, so they don't shadow
$

[x3ccd4828]

@champtar it seems it was my partitioning that caused issues. I was able to reproduce my issue inside a VM and fixed it by changing the partition structure.

[champtar]

@gsauthof see 3rd line

# grep shadow /usr/lib/dracut -r 
/usr/lib/dracut/modules.d/99base/module-setup.sh:    [[ $hostonly ]] && pwshadow='x'
/usr/lib/dracut/modules.d/99base/module-setup.sh:    grep '^root:' "$initdir/etc/passwd" 2>/dev/null || echo  "root:$pwshadow:0:0::/root:/bin/sh" >> "$initdir/etc/passwd"
/usr/lib/dracut/modules.d/99base/module-setup.sh:    [[ $hostonly ]] && grep '^root:' $dracutsysrootdir/etc/shadow >> "$initdir/etc/shadow"
/usr/lib/dracut/modules.d/90mdraid/module-setup.sh:    # remove incremental assembly from stock rules, so they don't shadow

dracut-050-26.git20200316.fc31.x86_64

[gsauthof]

I see, my system was still on dracut-049-27.git20181204.fc31.1.x86_64.

It was introduced by this commit: dracutdevs/dracut@32f68c1

So, I'm not sure how to deal with this issue.

I mean you could argue that a system where the root user is locked, root also shouldn't be able to log into early boot.

I don't know how common it is to set up a system without root password (and then use ! for locking instead of *).

I always set up a password for root on my systems.

From your point of view, is there something actionable that could/should be changed in this dracut-sshd module in regard to this issue?

[champtar]

When using PAM ! and * is the same, both let you login with ssh
I use dracut-sshd for my VPS, If i break one of them I can either boot on a live os, rollback to latest backup or reinstall from scratch, in any case no need for root password.
The only safe thing to do for now is to print a big warning if there is ^root:!: in shadow in the initrd

[gsauthof]

Closing this issue because shadow checks are out-of-scope for dracut-sshd, in my opinion.

[wtogami]

I always set up a password for root on my systems.

For the last two decades Red Hat's distro has discouraged people from logging into the desktop as root. As a result many of us almost never login as root. We instead use ssh keys and sudo from non-root users. All of my systems have no root password. I am pretty sure I am not alone in this and thus find dracut-sshd to be broken.

As for what to do about it ... /usr/lib/dracut/modules.d/99base/module-setup.sh

    # add common users in /etc/passwd, it will be used by nfs/ssh currently
    # use password for hostonly images to facilitate secure sulogin in emergency console
    [[ $hostonly ]] && pwshadow='x'
    grep '^root:' "$initdir/etc/passwd" > /dev/null 2>&1 || echo "root:$pwshadow:0:0::/root:/bin/sh" >> "$initdir/etc/passwd"
    grep '^nobody:' "$dracutsysrootdir"/etc/passwd >> "$initdir/etc/passwd"

    [[ $hostonly ]] && grep '^root:' "$dracutsysrootdir"/etc/shadow >> "$initdir/etc/shadow"

Unfortunately 99base happens well after 46sshd so we can't detect and fix up during the existing script. We could add 99sshd-fixup that detects if /etc/shadow root would be broken and change that one character.

[gsauthof]

For the last two decades Red Hat's distro has discouraged people from logging into the desktop as root. As a result many of us almost never login as root.

Well, Linux distributions in general have discouraged people from logging into a desktop environment as root since forever.
But dracut-sshd has nothing to do with a desktop environment.
Bringing this up like this is a straw man.

I just installed Fedora 38 server via the official GUI installer and there it presents me with to menu points for root _and _ user account creation. Both are marked with an exclamation mark to direct the user entering their configuration menus. Forward progress is blocked until any of those items is configured.

The root user creation item is even on top of the user creation, thus, the installer even encourages to consider creating a root account. (at least for people who are used to a left-to-right/top-to-bottom reading direction)

When I enter the root user creation dialog I'm presented with this text:

The root account is used for administering the system.

The root user (also known as super user) has complete access to the entire system. For this reason, logging into this system as the root user is best done only to perform system maintenance or administration.

(*) Disabling the root account will lock the account and disable remote access with root account. This will prevent unintended administrative access to the system.

( ) Enabling the root account will allow you to set a root password and optionally enable remote access to root account on this system.

The first option is pre-selected, but that's it. The wording doesn't strongly pushes a user into disabling the root account at all.
When I click on enable, root SSH login with password is even disabled, by default.

---

Granted, it's possible to skip the root user creation item and just configure a normal user and continue with the installation.

In that case the root account is disabled via ! in the shadow password field.

I find it hilarious how such a system then has sudo credential caching enabled, by default.
Such a system objectively has worse security properties than one where the root account has a strong password, only allows public-key authentication for root (and ideally all other users) and doesn't configure sudo for normal users.
The latter is what I recommend.

Besides, having a root account with a password allows for console repair login in situations where the normal network is down, the normal user authentication and/or NFS user homes are broken.

---

We instead use ssh keys and sudo from non-root users.

Do you use sudo with or without credential caching?

All of my systems have no root password. I am pretty sure I am not alone in this and thus find dracut-sshd to be broken.

I'm sure that you aren't the only one.
But this doesn't show that dracut-sshd is broken.

One can argue for some time about the semantics of ! vs. !! vs. * etc. differ between PAM, various UNIX like systems and openssh and which are the 'right' ones.

---

It would be consequent for Fedora to patch openssh to use a different LOCKED_PASSWD_PREFIX, since under PAM ! locked accounts can still ssh public-key auth login.

Sure, Fedora already claims that UsePAM no simply isn't supported.

However, if you care strongly about this, creating an openssh issue in the fedora bugzilla is small effort and perhaps you can convince the openssh fedora packager to change it.

Especially since LOCKED_PASSWD_PREFIX really only is used under UsePAM no and changing it has zero side effects for UsePAM yes.

[wtogami]

The first option is pre-selected, but that's it. The wording doesn't strongly pushes a user into disabling the root account at all.

Your argument is Red Hat is overall doing it wrong and we must convince them to change. Even if you're correct that is exceedingly difficult for a codepath that they outright declare is unsupported.

However, if you care strongly about this, creating an openssh issue in the fedora bugzilla is small effort and perhaps you can convince the openssh fedora package to change it.

I am uncertain we could convince them to accept a UsePAM no behavior change for Fedora. We definitely won't be able to convince them to make that change for RHEL8 and RHEL9 supported until 2029 and 2032 respectively.

[gsauthof]

wrtogami wrote:

gsauthof wrote:

The first option is pre-selected, but that's it. The wording doesn't strongly pushes a user into disabling the root account at all.
Your argument is Red Hat is overall doing it wrong and we must convince them to change. Even if you're correct that is exceedingly difficult for a codepath that they outright declare is unsupported.

I don't follow. In the part you cite I'm arguing that Fedora (a distribution which is co-authored by Redhat) doesn't push a user to disable the root account, strongly.

I am uncertain we could convince them to accept a UsePAM no behavior change for Fedora.

We will never know if you don't try.

We definitely won't be able to convince them to make that change for RHEL8 and RHEL9 supported until 2029 and 2032 respectively.

Depends on your RHEL support contract.

If you can't convince them you can still simply switch your locking method for your ! locked root user like this:

usermod --password '*' root

Or simply set a strong password for your root account.

[wtogami]

I don't follow. In the part you cite I'm arguing that Fedora (a distribution which is co-authored by Redhat) doesn't push a user to disable the root account, strongly.

OK you're correct. Red Hat used to more strongly discourage users from logging in to the desktop as root. Perhaps I haven't tried in years. There is no visible warning anymore.

The installer still has an option to set a root password and it's valid to not set it. Perhaps many of us trained long ago continue to not ever set a root password.

[gsauthof]

As mentioned before, there are two completely different things:

1. a distribution trying its best to discourage users to login as root into a desktop
2. creating a system with a locked root account

The way you are trying to to repeatedly mix those together is a typical straw man move.

---

Perhaps many of us [..]

Speak for yourself.