[andrerm]

> So do I understand it correctly? The solution to SSH remote login is to not have it?

> With systemd-homed access to the home directory is simply impossible unless the luks keyphrase (aka "user password") is specified (i.e. tje user logged in) since the data store is after all fully encrypted unless the user logs in. Thats a good thing btw: the user's data should be protected from the system unless the user is actually logged in. Now, ssh public key auth doesnt deal with passwords hence just using ssh pk auth means we couldnt unlock the luks volume simply because we have no keyphrase to unlock things with. So the PAM module that unlocks homed volumes actually enquires the client for the password explicitly if this happens. Unfortunately this is not sufficient for this to work with openssh since its pam hook-up doesnt support asking questions via pam after authentication.

> That said people suggested we maybe should provide a stub account you can log into with a fixed password that instead of a shell just spawns a program that queries you for username and password and then allows you to unlock the specified home directory.

I get that GNU is not Unix but why do this guy hates Unix so much?

[erik_seaberg]

“Logged in”? Does this seriously not accommodate cronjobs? Well, this isn't the first time they have ignored non-interactive and distributed uses, and it always seems like they're targeting a game console rather than a real computer.

[theamk]

He is talking about homedir encryption with auto-lock, and this fundamentally incompatible with cronjobs.

Sorry, you got to choose - cronjobs or secures encryption. No one can have both.

[erik_seaberg]

“Will the user hit ^D in time?” is some kind of movie-inspired imitation of security. If I can't trust that computer while I'm not logged in, I shouldn't trust it any more when I am. Encryption keys should be opaquely held by processes as capability tokens.

[michaelmrose]

I'm sorry this is wrong. Full disk encryption combined with locking said encryption on suspend secures a machine from trivial invasions of privacy while not in use or theft of the machine. Cron implementations and individual jobs can intelligently figure out how to handle missed jobs while the machine was off or suspended. Example doing the missed job once at some interval after resuming, doing it per runtime interval instead of per calendar interval, just doing the next scheduled interval.

Systemd has its own cron type implementation called timers and I'm sure it logically would work user jobs in at times the user is logged in, in the same way cron works around the fact that the user is sometimes suspended or off for indeterminate time frames.

In most cases it wont even have to. Most users machines have a lifecycle like this

POST 15 seconds Optional FDE passphrase entry 10 seconds Starting up 30 seconds to 2 minutes User login 10 seconds Operation some duration for hours to weeks Shutdown

The encrypted and or logged out state are transitory states on the way to the machines single owner entering credentials to access the device and the machine is only in those states 0.001% of its lifecycle.

For people worried about substantial secrets as opposed to a thief stealing their personal data it may be wise to segregate THAT data on a separate encrypted volume that is only unlocked during use so that opening up your machine to watch cat videos on Youtube doesn't expose thousands of patient records or company secrets.

Cron is only incompatible with homedir encryption if your scheme relies on time sensitive things which effect things OFF your computer happening ON your machine which is powered on frequently enough but not logged in as you sufficiently to complete the tasks it must also require data on your home dir to complete.

I say it has to be factors that effect off computer items because otherwise the task can simply be done as soon as you log in.

I say it must require data on your home dir to complete else your system can be told to do it for you.

For the small number of cases where one might imagine a shared computer might be turned on enough but logged in as other users one can imagine ignoring homedir encyption and simply using FDE with multiple passphrases for individual users. This will necessarily be less secure as all users would be constrained by permissions by able to break into other users local data. At this point we have identified the use case that is actually incompatible.

Shared computers with privileged local data with mutually untrustworthy users on which users need to regularly run tasks which require access to user data regardless of who is logged in.

The logical solution to which is a server, segregation to be provided by different virtual machines if needed.

[AstralStorm]

Not entirely true, a cronjob at user level can just ask for the password.

[theamk]

Not sure how that work? The computer just stands there, with no one around, and “please enter password for user joe” appears? Or same thing happens on a shared computer while another user is logged in - what next?

I mean, sure one can code this, but I cannot imagine many situations where it will be useful. I think if you want cronjobs, you just have to use service users.

[eikenberry]

My guess is that this is not meant for systems you'd ssh into. That this particular feature is designed specifically for use on laptops.

[brmgb]

It's a good guess. The first sentence of Lennart answer to this question is :

> Well. Homed is intended primarily for client machines, i.e. laptops and thus machines you typically ssh from a lot more than ssh to if you follow what i mean.

andrerm left it out of his quote. He also left this part out. It's about openssh and pam :

> Maybe they solve this eventually but lets see. In the meantime you at least get a friendly msg explaining the situation briefly and what to do.

[jacquesm]

That he doesn't use it is his problem. I run sshd on all my laptops and regularly ssh into a machine in another room.

[JohnFen]

Huh? I ssh into my laptops all the time...

[brmgb]

It's only a problem if you want to use an encrypted home and ssh into your laptop while not logged locally.

I mean, no one likes the current situation but it was deemed an acceptable trade off considering there is a work around.

[Gibbon1]

Not anymore you heathen.

[codys]

I think the confusion here might be a lack of clear distinction in the discussion between "ssh password auth" and "ssh pub key auth".

My impression is that the result of some of the design decisions might make "ssh pub key auth" work less often. IOW: one would need to login via password auth before pub key auth would work.

The alternate ("somehow have pubkey auth work and then ask for a crypto password") sounds like it would need some work and it isn't clear how useful it would be: if I'm already needing to enter a password anyhow, why bother with the previous pubkey auth?

As discussed elsewhere, it's plausible that some mechanism could be developed to use the ssh key material (or some other stored key material) to have the unlocking happen without manual password entry, but that would require some additional development.

Really, all this boils down to is that "login mechanisms aren't quite flexible enough", and the presentation touches on this to some extent as well.

[michaelmrose]

I read that you would have to physically log into your machine in order to mount home but ssh login including via public key auth would work thereafter.

Public key ssh login at a machine you hadn't sat down and logged in would fail in the same fashion as one would expect if the home partition was absent.

This would seem to be passable in many cases right up until you have to reboot the machine for some reason and its no longer possible to login.

There is good reason to prefer a public key vs password. Pubkey auth means you aren't entering anything over the wire that can be intercepted and nobody can guess or use your password if they knew it to access your local system.

For example someone who shoulder surfed your password couldn't gain the ability to log into your machine from across town.

If they shoulder surfed your passphrase/password and then stole your physical machine they would of course have everything they needed in a typical configuration even with encryption. You could of course go further and require a keyfile AND a passphrase and hope it is harder to say steal a small usb device on your keychain and your computer than just your computer.

At this point it really looks like you are defending against a targeted attack on your data rather than simple theft.

[tyingq]

Wouldn't it similarly have issues with the various desktop UI logins? Or do these all use systemd-logind?

[eikenberry]

The quoted paragraph says it uses a PAM module to unlock it, and PAM is independent of systemd.

[bitwize]

The ones that don't use systemd-logind can be safely ignored because they aren't modern, or compatible with the modern Linux ecosystem.