From 1c5d03c088f60717de2028326e8198b45fc56cda Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Mon, 27 Nov 2023 15:09:05 +0100 Subject: [PATCH] update TODO --- TODO | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/TODO b/TODO index c0260c7b03..a64a6a0c1c 100644 --- a/TODO +++ b/TODO @@ -1195,16 +1195,8 @@ Features: passwords, not just the first. i.e. if there are multiple defined, prefer unlocked over locked and prefer non-empty over empty. -* homed: while a home dir is not activated generate slightly different NSS - records for it, that reports the home dir as "/" and the shell as some binary - provided by us. Then, when an SSH login happens and SSH permits it our binary - is invoked. This binary can then talk to homed and activate the homedir if - it's not around yet, prompting the user for a password. Once that succeeded - we'll switch to the real user record, i.e. home dir and shell, and our tool - exec()s the latter. Net effect: ssh'ing into a homed account will just work: - we'll neatly prompt for the homedir's password if its needed. –– Building on - this we could take this even further: since this tool will potentially have - access to the client's ssh-agent (if ssh-agent forwarding is enabled) we +* homed: if the homed shell fallback thing has access to an SSH agent, try to + use it to unlock home dir (if ssh-agent forwarding is enabled). We could implement SSH unlocking of a homedir with that: when enrolling a new ssh pubkey in a user record we'd ask the ssh-agent to sign some random value with the privkey, then use that as luks key to unlock the home dir. Will not