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/.
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.
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.
This now works for a local "su - test", but still not for ssh: $ ssh test.0.2 Warning: Permanently added '[127.0.0.2]:2201' (ECDSA) to the list of known hosts. test.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?
No idea why ssh doesn't work. But let's keep one bug for now.
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.
Can we get some movement on this? Would a PR help?
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.
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.
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.
(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?
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.
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.
(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.
> 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.
(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.
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.
(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.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.
I finally found out how to fix this: s/password-auth/system-auth/ in /etc/pam.d/sshd.
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.
+1 Please update affected version to 34
I have tested systemd-homed one Feodra 35. First test was to create a user and login. Trying this I got an error message from "homectl create". The reason was SELinux (see attached file). After changing into permissive mode I was able to create the user. Next thing was PAM configuration. I have checked the information in this bug report and had a look at this article: https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html -auth sufficient pam_systemd_home.so -account sufficient pam_systemd_home.so -password sufficient pam_systemd_home.so -session optional pam_systemd_home.so I put this stuff into /etc/pam.d/systemd-auth (this is the file name on my system). After testing the user login it still did not work. Then I put the same stuff into /etc/pma.d/password-auth (just guessing). After this I was able to login. Finally I put SELinux back into enforcing mode and found that login is still possible.
Created attachment 1848093 [details] output of "ausearch -m avc -ts today | grep homed"
To make things clear for other people having issues, this is what I needed to change on Fedora 35: ``` $cat /etc/pam.d/password-auth #%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok -auth sufficient pam_systemd_home.so # added auth required pam_deny.so account sufficient pam_unix.so # changed required to sufficient -account sufficient pam_systemd_home.so # added password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so try_first_pass use_authtok nullok yescrypt shadow -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 ``` as diff -hu: ``` #%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok +-auth sufficient pam_systemd_home.so # added auth required pam_deny.so -account required pam_unix.so +account sufficient pam_unix.so # changed required to sufficient +-account sufficient pam_systemd_home.so # added password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so try_first_pass use_authtok nullok yescrypt shadow +-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 ```
@robert.mader Made your edits to `/etc/pam.d/password-auth` and I wasn't able to `su $USER`. However, adding the entries from https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html to `/etc/pam.d/system-auth` did work though. This is partly based off of what arch does. Running Fedora 36 here FYI.
Adding those same entries to `/etc/pam.d/gdm-password` allow users to login from the gnome login screen (I was having issues with this previously). So currently it seems at least two PAM files have to be edited. I did see a lot of SELinux warning when logging in for the first time though. So I have to go through those as well, but thats a separate issue.
@pattyn586: I forgot to update my post here - for me it turned out that I need to edit both `password-auth` and `system-auth` in order to log in into a graphical session as well as from TTY - so what you say seems right, `system-auth` is needed in your case. Further more in Fedora 36 the files in `/etc/pam.d` seem to get overwritten by `authselect` on every boot. To get a normal working system (I use it as my daily driver on one setup) I needed to change both `/etc/authselect/password-auth` and `/etc/authselect/system-auth` to keep things persistent. Unfortunately even then a update to the authselect package resets those files IIRC - so a better solution (or rather proper support from Fedora) would be great.
Is there something we can do to push this? Should I make a PR some where? From the earlier discussion it looks like Lennart doesn't believe adding the additional PAM entries will cause any issues, but Pavel wanted discussion on fedora-devel. So point me in the right direction so we can make this easier to use for end users (mainly myself). As it is usable and its been >2 years since this issue was open. It doesn't have to be the default way to make users, but for people who want to enable it, it would be nice not to have the PAM config overridden on every boot or authselect update. Homed has a lot of cool features and security benefits. Therefore, pushing some sane config to lower the barrier to entry will allow more people to test this and hopefully push for better support from Gnome/KDE.
If you want to enable it only for people who seek it, then I'd recommend you to work with the authselect package (https://github.com/authselect/authselect). As Pavel has suggested previously you could create a new command (i.e. authselect select sssd with-homed) to do that work. If you want to enable it by default for everybody I'd suggest you to open a discussion in Fedora's development list. From the two options the first one is the easiest one as the change can be triggered by the user/admin, and it will only affect a given system. Moreover, I'm pretty sure that Pavel will be happy to accept a PR.
Thanks Iker! I'll start to look in the direction of modifying the authselect package first. Should I focus my efforst at that github repo? Or is there a specific fedora repo I should look at?
For the moment the Github repo is your way forward.
Please post the github issue URL here, and also https://pagure.io/fedora-workstation/issue/82. thanks!
No problem, here is the link: https://github.com/authselect/authselect/issues/310
I'm closing this bugzilla because authselect already provided an option to enable homed support, which is already available in Fedora.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days