[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] semi OT: systemd-homed

I'm far too lazy ?

Basically by using the sshd with centos7+ and freeipa to manage everything, users can copy their ssh pub key into ldap using a web gui.

When a user then ssh to a freeipa managed host, sshd knows to look for pub key in ldap and ~/.ssh/<file from config>. The pub key storage on ldap is keyed on the user name as expected. 

This should also with Debian, suse, ubuntu, fedora and most derivatives. Don't know about aspen or gentoo.

On May 1, 2020 4:03:41 PM EDT, Steve Litt via Ale <ale at ale.org> wrote:
>Hi Jim,
>Could you please draw a block diagram of your key retrieval from ldap
>via FreeIPA idea, including interactions with systemd, LUKS, D-Bus,
>logind, and any remnants of PAM?
>Afterwords, as we gaze upon your diagram, we can contemplate that
>according to the article's author, systemd-homed was created to:
>"So, for the simple act of logging in, three
>mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is
>Steve Litt
>March 2020 featured book: Troubleshooting: Why Bother?
>On Fri, 01 May 2020 07:23:47 -0400
>Jim Kinney via Ale <ale at ale.org> wrote:
>> Was thinking about the ssh part. Ssh has the ability to retrieve keys
>> from ldap. Ok, so not all releases but most of the big distros now
>> ship that ability. FreeIPA is a scalable tool for user management
>> that is easy for users to publish their pub key with into ldap.
>> On May 1, 2020 7:18:36 AM EDT, Solomon Peachy via Ale <ale at ale.org>
>> wrote:
>> >On Thu, Apr 30, 2020 at 02:59:44PM -0400, Boris Borisov via Ale
>> >wrote:  
>> >>  
>> >
>> >It provides a good alternative to full-disk encrpytion, and makes 
>> >homedirectories fully portable from one system to another.
>> >(Assuming nothing hardcodes absolute paths, heh..)  Each user's
>> >homedir becomes its own encrpyted filesystem, accessible only to
>> >them, and not even the
>> >
>> >local admins.  Which is both good and bad; depends on the use case
>> >and trust model.
>> >
>> >(Worth mentioning that LUKS can have parallel admin/fallback keys,
>> >so it's really up to how the admins set things up.  The same caveats
>> >apply
>> >
>> > to systemd-homed too..)
>> >
>> >So it's a good option to have for single-user systems or multi-user 
>> >systems that are accessed via a "local" login (ie on the console or
>> >via
>> >
>> >the likes of full remote sessions ala VNC).  Which I suspect
>> >encompasses 
>> >the overwhelming majority of "workstation/desktop" types of use
>> >cases.
>> >
>> >Consider the UI implications of using encrypted storage; the current
>> >model presents an all-or-nothing approach, and requires a password
>> >or other token (which can be the built-in TPM) to be physically
>> >present at
>> >
>> >boot. This new approach allows the base system to be [un]encrypted 
>> >independently of the user data, and also prevents any given user
>> >from being able to decrpyt any other user's data.
>> >
>> >Where systemd-homed falls down is on systems/accounts that are
>> >accessed
>> >
>> >primarily via ssh (and authenticated via ssh keys) -- ie most
>> >server-ish 
>> >use cases.  So it's not some universal pancea.
>> >
>> > - Solomon
>> >-- 
>> >Solomon Peachy			      pizza at shaftnet dot
>> >org (email&xmpp)
>> >                                     @pizza:shaftnet dot org
>> > (matrix)
>> >High Springs, FL                      speachy (freenode)  
>Ale mailing list
>Ale at ale.org
>See JOBS, ANNOUNCE and SCHOOLS lists at

"no government by experts in which the masses do not have the chance to inform the experts as to their needs can be anything but an oligarchy managed in the interests of the few.? - John Dewey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20200501/a246c4ee/attachment.html>