mirror of
https://github.com/systemd/systemd
synced 2024-07-21 10:17:21 +00:00
update TODO
This commit is contained in:
parent
8349bbdfd8
commit
1c5d03c088
12
TODO
12
TODO
|
@ -1195,16 +1195,8 @@ Features:
|
||||||
passwords, not just the first. i.e. if there are multiple defined, prefer
|
passwords, not just the first. i.e. if there are multiple defined, prefer
|
||||||
unlocked over locked and prefer non-empty over empty.
|
unlocked over locked and prefer non-empty over empty.
|
||||||
|
|
||||||
* homed: while a home dir is not activated generate slightly different NSS
|
* homed: if the homed shell fallback thing has access to an SSH agent, try to
|
||||||
records for it, that reports the home dir as "/" and the shell as some binary
|
use it to unlock home dir (if ssh-agent forwarding is enabled). We
|
||||||
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
|
|
||||||
could implement SSH unlocking of a homedir with that: when enrolling a new
|
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
|
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
|
with the privkey, then use that as luks key to unlock the home dir. Will not
|
||||||
|
|
Loading…
Reference in a new issue