Skip to content

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

@andrejpodzimek

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFE 🎁Request for Enhancement, i.e. a feature requesthomedhomed, homectl, pam_homed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions