Option to skip password prompts in systemd-homed for unencrypted home directories

[andrejpodzimek]

Is your feature request related to a problem? Please describe.

There are two problems:

1. 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_config modification (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.

2. Lingering doesn't work nicely with systemd-homed; after loginctl 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 --failed that 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.

[jokeyrhyme]

I had some questions about homectl update --auto-login=true ... over here: #16703 (comment)

But this discussion here could also be a way to approach my use case

[cerebrate]

I'm having this issue with using systemd-homed in conjunction with https://github.com/arkane-systems/bottle-imp under WSL; specifically, bottle-imp makes use of systemd-containerd and machinectl user@.host to start a "proper" login session rather than the Microsoft approach of merely spawning a shell under the appropriate uid. Unfortunately, since this doesn't provide a password when creating said login session, the home directory can't be mounted even if it's just a local directory or an NFS-mounted directory.

A way of working around this would be most useful.