Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Systemd user services do not start when home dir encrypted #247

Closed
trochdewei opened this issue Sep 5, 2020 · 4 comments
Closed

Systemd user services do not start when home dir encrypted #247

trochdewei opened this issue Sep 5, 2020 · 4 comments

Comments

@trochdewei
Copy link

My environment is Manjaro Linux with KDE as desktop environment and SDDM login manager
/etc/pam.d/passwd:

#%PAM-1.0
#password       required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
#password       required        pam_unix.so sha512 shadow use_authtok
password        required        pam_unix.so sha512 shadow nullok rounds=524288
password        optional        pam_fscrypt.so

/etc/pam.d/system-login:

#%PAM-1.0

auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth
auth       optional   pam_fscrypt.so debug

account    required   pam_access.so
account    required   pam_nologin.so
account    include    system-auth

password   include    system-auth

session    optional   pam_loginuid.so
session    optional   pam_keyinit.so       force revoke
session    include    system-auth
session    optional   pam_motd.so          motd=/etc/motd
session    optional   pam_mail.so          dir=/var/spool/mail standard quiet
-session   optional   pam_systemd.so
session    required   pam_env.so           user_readenv=1
session    optional   pam_fscrypt.so       drop_caches lock_policies debug

I created ssh-agent.service file with following content

[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
# DISPLAY required for ssh-askpass to work
Environment=DISPLAY=:0
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

as described here https://wiki.archlinux.org/index.php/SSH_keys#Start_ssh-agent_with_systemd_user

But after reboot and login service is inactive

>>> systemctl --user status ssh-agent.service                                                                  
● ssh-agent.service - SSH key agent
     Loaded: loaded (/home/user/.config/systemd/user/ssh-agent.service; enabled; vendor preset: enabled)
     Active: inactive (dead)

ANother problem is that home dir remains unlocked after logout

@sudoBash418
Copy link

I had the same problem, solved it by editing /etc/pam.d/system-login to move the session optional pam_fscrypt.so line above the systemd one:

[...]
session    optional   pam_fscrypt.so       drop_caches lock_policies debug
-session   optional   pam_systemd.so
session    required   pam_env.so           user_readenv=1

Not sure if this is a security issue as I'm not very familiar with PAM but it seems to work fine for me.

@1989gironimo
Copy link

#270 seems to be a duplicate of this.

I've created an issue on linux-pam but the don't seem to be responsible for fixing this:
The dev wrote, that this issue should be reported to the corresponding bugtrackers of each distribution.

Here's the bug reported for Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964951

@ramcq
Copy link
Contributor

ramcq commented Mar 2, 2021

In case it affects anyone else - on my Debian-based system, the workaround on #270 worked, but I also had to disable "lingering" for my user (the reverse of https://wiki.archlinux.org/index.php/systemd/User#Automatic_start-up_of_systemd_user_instances, ie disable-linger), so that systemd did not launch the systemd user session before my login session.

@ebiggers
Copy link
Collaborator

ebiggers commented Mar 9, 2021

This was fixed for users of Debian-based distros (distros using pam-config-framework) by increasing the priority of pam_fscrypt (#278). The improved documentation (#281 and an Arch Wiki update) also addressed this issue for users of non-Debian-based distros, to the extent possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants