-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Description
Is your feature request related to a problem? Please describe.
There are two problems:
-
Passwordless SSH logins are (in general) impossible with
systemd-homed, even when the home directory is on a Btrfs subvolume and technically doesn't require a password to get mounted.This has no impact on safety, because you can (and should) always enable (additional) certificate authentication in
sshd_config. However, it is impossible to log in (for the first time) with a certificate only. This SSH remote unlocking section describes the setup and here's my talk page entry with further details.Once a user's home directory is activated, passwordless SSH logins can work, but require a
sshd_configmodification (and SSH server restart) on the host side. And then you may lock yourself out if the machine reboots. The only reliable option is to require a password on each and every SSH login — even when the home directory is active or doesn't require a password. -
Lingering doesn't work nicely with
systemd-homed; afterloginctl enable-linger, there's always an unsuccessful attempt at starting the user's service at boot:Oct 10 01:56:51 aether systemd[1]: Starting User Manager for UID 1984... Oct 10 01:56:51 aether systemd[1622]: pam_systemd_home(systemd-user:account): conversation failed Oct 10 01:56:51 aether systemd[1622]: pam_systemd_home(systemd-user:account): conversation failed Oct 10 01:56:51 aether systemd[1622]: pam_systemd_home(systemd-user:account): Failed to prompt for password/prompt. Oct 10 01:56:51 aether systemd[1622]: PAM failed: Authentication service cannot retrieve authentication info Oct 10 01:56:51 aether systemd[1622]: user@1984.service: Failed to set up PAM session: Operation not permitted Oct 10 01:56:51 aether systemd[1622]: user@1984.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Oct 10 01:56:51 aether systemd[1]: user@1984.service: Main process exited, code=exited, status=224/PAM Oct 10 01:56:51 aether systemd[1]: user@1984.service: Failed with result 'exit-code'. Oct 10 01:56:51 aether systemd[1]: Failed to start User Manager for UID 1984.This^^^ is rather tricky, because the service (re)starts successfully afterwards, upon the user's first login, so there's no indication in
systemctl --failedthat something went wrong.
Describe the solution you'd like
It would be awesome to have an option to not require passwords when they are unnecessary. Passwords may be required by default, for consistency, but an option to skip them when feasible would be great. (homectl has a flag called --no-ask-password, but that doesn't work for me; it does stop asking for a password temporarily, so that a few activations / deactivations (done by root) work without a password, but it starts asking for the password again after a timeout.)
Describe alternatives you've considered
For the first problem, support on the OpenSSH side could be an alternative. But it would be rather complicated: On a per-user basis, a user's first login would switch AuthenticationMethods from publickey,password to publickey. But I sincerely doubt that OpenSSH would want to implement that.
For the second problem I don't see any alternatives to a "passwordless auto-activation" support of some sort.