systemd-homed

homectl is the main utility you will use for homed. With it, you can create, update, and inspect users; their home directories; and their ~/.identity files controlled by the systemd-homed(8) service.

The simplest usage of homectl is:

# homectl create username

This command will create a user with the specified username, a free UID in range 60001–60513, create a group with the same name and a GID equal to the chosen UID, set the specified user as its member, and set the user's default shell to .

The home directory mount point is set to . The storage mechanism is chosen in this order:

1. luks if supported;
2. subvolume if LUKS is not supported and subvolume is supported;
3. if none of the above is supported and no other manual option is specified.

The image path for the LUKS mechanism is set to . The directory path for the directory mechanism is set to .

A query tool used to inspect users, groups and group memberships provided by both classic UNIX mechanisms and systemd-homed.

A user home directory is stored in a Linux file system, inside an encrypted LUKS (Linux Unified Key Setup) volume inside a loopback file or any removable media. To use this mechanism provide to homectl.

If you are using a removable media, make sure that these conditions are met:

• The image contains a GPT partition table. For now it should only contain a single partition, and that partition must have the type UUID . Its partition label must be the user name.
• This partition must contain a LUKS2 volume, whose label must be the user name. The LUKS2 volume must contain a LUKS2 token field of type systemd-homed. The JSON data of this token must have a record field, containing a string with base64-encoded data. This data is the JSON user record, in the same serialization as in ~/.identity, though encrypted. The JSON data of this token must also have an iv field, which contains a base64-encoded binary initialization vector for the encryption. The encryption used is the same as the LUKS2 volume itself uses, unlocked by the same volume key, but based on its own IV.
• Inside of this LUKS2 volume must be a Linux file system, one of ext4, btrfs and XFS. The file system label must be the user name.
• This file system should contain a single directory named after the user. This directory will become the home directory of the user when activated. It contains a second copy of the user record in the ~/.identity file, like in the other storage mechanisms.

A user home directory is stored the same way as when using the above method, but this time a native filesystem encryption is used. To use this mechanism provide --storage=fscrypt to homectl.

A user home directory is stored in and mounted to using bind mount on unlocking. When this method is used no encryption is provided. To use this mechanism provide or to homectl.

Here, the home directory is mounted from a CIFS (Common Internet File System) server at login. Note that CIFS is implemented via the Samba protocol. Use on the homectl command line. The local password of the user is used to log into the CIFS service.

Create a user with LUKS encryption:

# homectl create username --storage=luks

Create a user with fscrypt encryption (make sure that fscrypt is enabled on the file system):

# homectl create username --storage=fscrypt

Create a user with a specific UID, shell and groups:

# homectl create username --shell=/usr/bin/zsh --uid=60100 --member-of=wheel,adm,uucp

Other options can be found in .

It is possible to delete several users at the same time, as root, you can run the command below to immediately delete 2 users:

# homectl remove username username2

The option can be used with entries in the files in /etc/pam.d/ to enable forget key on suspend. No session manager at the moment supports this feature. Furthermore, TTY sessions do not support the reauthentication mechanism. So, when session managers start supporting this feature, the suspend option should only be enabled for them. Read and the Linux-PAM System Administrators' Guide for more details.

systemd-homed encrypts your home directory using your password, so SSH configured for public key authentication cannot mount it or read authorized_keys. A possible solution is to add authorized keys to your user record and require both public key and password for authentication. Add the following to :

Update your user record with your authorized keys while the user is unlocked using:

# homectl update username --ssh-authorized-keys=@/path/to/mounted/home/.ssh/authorized_keys

From now on, SSH will ask you to enter your password after completing key-based authentication. systemd-homed will use it to unlock and mount your home directory.

If you need to mount a systemd-homed-encrypted directory from a rescue disk or another machine, you will need to decrypt the directory outside of the systemd-homed framework. You may wish to keep a text file or script of this solution from the forums on your rescue disk for emergencies:

# losetup -fP --show username.home
# cryptsetup open /dev/loopXpY mappername
# mount /dev/mapper/mappername /mnt/mountpoint

where,

• is the file in the directory with your username and the .home extension as its name
• is the device in the directory with the loop number of the loopback device created in the prior step and the partition number of the relevant partition, probably
• is whatever alias you decide to adopt for the mapped device, e.g. user_oldhome
• is wherever you want to mount your decrypted home directory

This setup requires a fido2 security device and ask for a pin to login and decrypt the home directory:

# homectl create username --storage=fscrypt --fido2-device=auto --fido2-with-client-pin=yes --fido2-with-user-presence=no --recovery-key=yes

Setting up a recovery key is recommended in case the device is lost or broken. The recovery key will be used like a password to access the user and files. Instead of using a device pin, it is also possible to ask only for user presence, which requires touching the security device. Currently, homectl also requires the user to set a password as alternative login which also works as a backup secret.

After logging out of Plasma, there may still be active user processes (e.g. dbus-daemon) that prevent the home directory's deactivation.

This can be solved by enabling Plasma's systemd startup.

If there is an umask set in , the user's own umask set via homectl is currently ignored. See systemd issue 23007.

To solve this, set the umask in your login shell's startup files e.g. or .