Bug 1806949 - homed: Cannot authenticate as homed user (homed requires manual pam.d config)
Summary: homed: Cannot authenticate as homed user (homed requires manual pam.d config)
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Iker Pedrosa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-25 10:38 UTC by Martin Pitt
Modified: 2021-09-20 08:12 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Martin Pitt 2020-02-25 10:38:08 UTC
Description of problem: I wanted to give homed a try, now that it is in Fedora 32. User creation fails due to SELinux, but that can be worked around with `setenforce 0`. But then logging in as that user doesn't work.


Version-Release number of selected component (if applicable):
systemd-245~rc1-3.fc32.x86_64


How reproducible: Always


Steps to Reproduce:
1. Create user:
   sudo homectl create test --real-name="Test User"
2. Check that NSS knows about it:
   id test
   (prints "uid=60444(test) gid=60444 groups=60444" for me)
3. Try to log in:
   su - test

Actual results:

su says "Authentication failure"; journal says

Feb 25 11:32:08 donald unix_chkpwd[5136]: check pass; user unknown
Feb 25 11:32:10 donald unix_chkpwd[5137]: check pass; user unknown
Feb 25 11:32:10 donald unix_chkpwd[5137]: password check failed for user (test)
Feb 25 11:32:10 donald su[5135]: pam_unix(su-l:auth): authentication failure; logname= uid=1000 euid=0 tty=pts/1 ruser=martin rhost=  user=test


Expected results: Login works


Additional info: /home/test.home does exist, and e. g. `userdbctl` shows it. The test user does not appear in /etc/passwd and friends, and AFAIUI also isn't supposed to. /etc/nsswitch.conf has

passwd: sss files altfiles systemd
shadow:     files sss
group: sss files altfiles systemd

which is how it comes by default.

I am running a rather minimal OSTree installation (like Silverblue, but with my own tree), so it's a crystal clean system without any hacks or cruft in /etc/.

Comment 1 Zbigniew Jędrzejewski-Szmek 2020-03-01 12:11:37 UTC
Dear PAM / authselect / authconfig maintainers:
please provide pam_systemd_home hookup in the default pam config.

I'm not sure what the best way to do this is. The following works for me:

# cat /etc/pam.d/system-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
-auth     sufficient pam_systemd_home.so                                  # added
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     sufficient      pam_unix.so                                   # changed required→sufficient
-account  sufficient pam_systemd_home.so                                  # added
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
-password sufficient pam_systemd_home.so                                  # added
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session  optional   pam_systemd_home.so                                  # added
session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

See also https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html.
Any comments on the setup recommended there are welcome.

Comment 2 Martin Pitt 2020-03-02 13:55:50 UTC
Thanks Zbigniew! I confirm that making these changes to PAM fixes logging in. There are some other problems with that, but I'll report these as separate issues.

Comment 3 Martin Pitt 2020-03-02 14:07:52 UTC
This now works for a local "su - test", but still not for ssh:

$ ssh test@127.0.0.2
Warning: Permanently added '[127.0.0.2]:2201' (ECDSA) to the list of known hosts.
test@127.0.0.2's password: 
Permission denied, please try again.

Journal says:
unix_chkpwd[8651]: check pass; user unknown
unix_chkpwd[8651]: password check failed for user (test)
sshd[8649]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.27.0.2  user=test
audit[8649]: USER_AUTH pid=8649 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="test" exe="/usr/sbin/sshd" hostname=172.27.0.2 addr=172.27.0.2 terminal=ssh res=failed'
kernel: audit: type=1100 audit(1583157966.895:461): pid=8649 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="test" exe="/usr/sbin/sshd" hostname=172.27.0.2 addr=172.27.0.2 terminal=ssh res=failed'
sshd[8649]: Failed password for test from 172.27.0.2 port 56510 ssh2

But /etc/pam.d/ssh includes password-auth in every category (auth, account, password, session). Is that a related problem, or should I file a separate bug for ssh?

Comment 4 Zbigniew Jędrzejewski-Szmek 2020-03-02 15:08:30 UTC
No idea why ssh doesn't work. But let's keep one bug for now.

Comment 5 Chris Murphy 2020-03-19 06:05:31 UTC
homed will require new selinux domain, bug 1809878

homectl has a --ssh-authorized-keys=KEYS flag for use with the create subcommand; but I haven't tested it yet.

Comment 6 Zbigniew Jędrzejewski-Szmek 2020-05-06 19:06:24 UTC
Can we get some movement on this? Would a PR help?

Comment 7 Iker Pedrosa 2020-05-07 07:06:52 UTC
Sorry, but I must have forgot about this bug. I'll start working on it in the following days.

Zbigniew if you have some changes that you feel confident about please propose the PR.

Comment 8 Tomas Mraz 2020-05-07 08:23:53 UTC
I am not sure this bug is for PAM at all. If anywhere the pam_systemd_homed should be configured by authselect. I do not think it is appropriate to include it into the default PAM configuration (when authselect is not used). That configuration should be really basic and not involving any extra optional authentication modules.

Comment 9 Tomas Mraz 2020-05-07 08:27:04 UTC
To add more arguments - homed is still an experimental concept, so it should not be configured by default which means it should not be in the PAM stack by default (neither in configuration created by authselect by default when the system is installed with anaconda). At least not until proper Fedora System Wide Change is filed and approved by FESCo.

Comment 10 Pavel Březina 2020-05-07 10:12:37 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> No idea why ssh doesn't work. But let's keep one bug for now.

SSH does not follow system-auth stack but password-auth stack. This module needs to be enabled in all system, password, smartcard and fingerprint-auth.

I'm not familiar with the module/concept but is looks like something that should go to session and not auth. Why is it in auth?

Comment 11 Zbigniew Jędrzejewski-Szmek 2020-05-07 11:02:00 UTC
authselect sounds like a better place, indeed. The goal is to have this in the
default configuration that users see.

I think it makes a lot of sense to "enable" this by default. I use quotes because
as long as users are not created using homectl, the presence of this module in the
stack is not supposed to have any effect. Homed has garnered quite a bit of end-user
attention, and even though there are no plans to make this the default mechanism,
it'd be great to allow people to experiment with this without requiring such complicated
changes like the pam stack. (Complicated, and easy to mess up too.)

In some sense, this was already "enabled" when systemd was shipped with homed compiled
in. Since this is all opt-in, I didn't think we need a Change page. But if you feel
that that is needed for the modifications in the pam/authselect profiles, I can
file it.

> Zbigniew if you have some changes that you feel confident about please propose the PR.

Actually, I'm not. We updated the upstream documentation recently
(https://github.com/systemd/systemd/commit/96249bf8d66f2d3ea3235b9f927ccaa094a611fd),
but I'm not sure how to best integrate this into the authselect profiles, and it would
certainly be good to get a good look at this from people who know the PAM stack best.

> Why is it in auth?

The knowledge of the decryption key is used to authenticate the user.

Comment 12 Tomas Mraz 2020-05-07 11:34:35 UTC
If it is just an optional profile in authselect it is a matter of running authselect with option to select the profile. So I do not think it would be a barrier. We must not take changes to the _default_ PAM configuration lightly, they have potential of breaking access for existing users and can even cause security issues of various impact.

So I do not think there would have to be a System Wide Change for adding a non-default optional authselect profile for homed. However for changing the default there definitely MUST be a System Wide Change and I am actually against implementing it until the Homed concept is well tested, reviewed and widely accepted.

Comment 13 Pavel Březina 2020-05-07 12:02:49 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11)
> > Why is it in auth?
> 
> The knowledge of the decryption key is used to authenticate the user.

And does it work even if the user is authenticated with smartcard or 2FA?

We can include in conditionally in authselect (e.g. enabled by authselect select sssd with-homed). I agree with Tomas that a change page should be created for making it default and we must be sure that it does not collide with non-password authentication mechanisms.

Comment 14 Lennart Poettering 2020-05-07 16:27:17 UTC
> If it is just an optional profile in authselect it is a matter of running authselect with option to select the profile. So I do not think it would be a barrier. We must not take changes to the _default_ PAM configuration lightly, they have potential of breaking access for existing users and can even cause security issues of various impact.

pam_systemd_home is (like pam_systemd) pretty carefully written to not fuck things up in unexpected environments. i.e. pam_systemd_home returns early on for users it doesn't manage. The idea is that i lives side-by-side with whatever else you do on the same, as one provider of user records of many. i.e. it's entirely fine to mix sssd and pam-systemd-home on the same system.

The PAM lines we propose in the linked man page are prefixed with "-" for a reason: the affect things as little as possible.

> So I do not think there would have to be a System Wide Change for adding a non-default optional authselect profile for homed. However for changing the default there definitely MUST be a System Wide Change and I am actually against implementing it until the Homed concept is well tested, reviewed and widely accepted.

Well, that's a chicken and egg problem.

Again, systemd-homed is not like sssd, winbind and the others: it does not take "possession" of the system, it just adds in additional users if the user tells it so.

Comment 15 Lennart Poettering 2020-05-07 16:40:59 UTC
(In reply to Pavel Březina from comment #13)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #11)
> > > Why is it in auth?
> > 
> > The knowledge of the decryption key is used to authenticate the user.
> 
> And does it work even if the user is authenticated with smartcard or 2FA?

systemd-homed has a stronger security model regarding smartcards and stuff, than traditional smartcard auth: it derives the encryption keys for the storage backend from the smartcard directly, i.e. it not only does account authentication with it but also binds storage encryption to it, to comprehensively protect the user's data. Because of that it talks directly with PKCS#11 and FIDO2 devices, so that it can ask the devices to provide it with keys to pass to the luks and fscrypt backends it supports.

External (i.e. PAM) authentication mechanisms that do not supply an authentication token via the pam context cannot be used to fully unlock homed accounts. We need some stable passphrase-like string we can give the luks/fscrypt backend for unlocking, and if the used authentication mechanism does not provide that then we try to ask via the usual PAM dialog stuff for it (this can only work for apps that support interactive dialog stuff though, not all do). This means: if you authenticate via SSH or so, we might ask you one more question even after SSH's own auth completed. If everything fails, i.e. no PAM module passed us a suitable token, and any attempts to ask the user for one failed we'll print a message to first log in locally via some other means (e.g. via gdm or console getty), which unlocks the backend storage given the provided passphrase/security token/…, at which point the original authentication can be retried which should then work, as the passphrase is not required anymore.

Comment 16 Pavel Březina 2020-05-12 14:27:18 UTC
My experience is that users fight any module that is enabled by default and does not have to be. I'm fine with putting it to authselect as optional module disabled by default. Personally, I'd like to see (ideally) approved change page or at least some discussion on fedora-devel that is positive about it. But ultimately, I will follow Tomas' suggestions.

Comment 17 Martin Pitt 2020-09-24 06:48:24 UTC
(In reply to Chris Murphy from comment #5)

I just tried this again, to see where we are in current Fedora 33.

> homectl has a --ssh-authorized-keys=KEYS flag for use with the create
> subcommand; but I haven't tested it yet.

I just tried that again, and it also doesn't work:

    sudo setenforce 0
    sudo homectl create --ssh-authorized-keys=@.ssh/id_rsa.pub test
    ssh -vv test@localhost

doesn't accept the key, and asks me for password instead (which also doesn't work, see original bug here):

debug1: Next authentication method: publickey
debug1: Offering public key: /var/home/martin/.ssh/id_rsa RSA SHA256:Eq3Xz7MwpEieWi+5do3xJ9l0b/VW4ryM1B84W399zfg agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: cockpit@falcon.thewalter.lan RSA SHA256:h7+tFtibY7JEezNuodkjeMNxCn064dAjta4WhlhDEpc agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /var/home/martin/.ssh/id_dsa
debug1: Trying private key: /var/home/martin/.ssh/id_ecdsa
debug1: Trying private key: /var/home/martin/.ssh/id_ecdsa_sk
debug1: Trying private key: /var/home/martin/.ssh/id_ed25519
debug1: Trying private key: /var/home/martin/.ssh/id_ed25519_sk
debug1: Trying private key: /var/home/martin/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

It also does not work if I previously unlock /home/test/ with "su - test" and password authentication. That test user does not have any ~/.ssh/ directory (and thus not an authorized_keys), but I think the point of homed was to store the SSH key separately. It does seem to know it:

$ sudo homectl inspect test | grep -i ssh
SSH Pub. Key: 1

But apparently that's still missing some integration in /etc/pam.d/sshd? So far I only changed /etc/pam.d/system-auth.

Comment 18 Martin Pitt 2020-12-14 05:01:29 UTC
I finally found out how to fix this: s/password-auth/system-auth/ in /etc/pam.d/sshd.

Comment 19 Freddy Willemsen 2021-04-26 08:31:56 UTC
Any news on this one? Trying to use systemd-homed in Fedora 34 also needs manual adjustments to pam modules. Would be nice if authselect profiles would support it.

Comment 20 Damian Ivanov 2021-04-26 10:43:05 UTC
+1
Please update affected version to 34


Note You need to log in before you can comment on or make changes to this bug.