You don't ever remotely log into your desktop??!

What do you do if you've left files on your desktop at home/work and need them from work/home?

In theory with homed you can just keep all of those files (home directory) on a share or USB drive and access them anywhere.

Im personally curious to see how this works with a tool like Syncthing

gee great, more unnecessary shoving everything into the "cloud"-- just to make sure that users have absolutely no due process protection for the confidentiality of their data.

Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse?

As far as USB goes-- can you suggest a currently manufactured _good_ usb storage device? I've found myself scrounging for old ones because anything currently made are unreliable, slow (in spite of amazing performance claims), or usually both.

> gee great, more unnecessary shoving everything into the "cloud"-- just to make sure that users have absolutely no due process protection for the confidentiality of their data.

This doesn't really make sense as a response to comment mentioning Syncthing which works with any backend, including your other machines.

> What's systemd's excuse?

Systemd's excuse for what exactly?

> shoving everything into the "cloud"

What's "everything" and got does it it try to shove it into the cloud?

> Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse?

Who do you think is putting the resources (manhours/money/etc) into mainlining this crap into Linux? It's the corps. Add Intel to the list.

You know you don't HAVE to use systemd-homed right? If it doesn't fit your use case, just keep doing what you're doing right now.

Why do people keep saying this? I don't see any reason to believe this won't come default in e.g. Ubuntu in the future, and it feels disingenuous for people to claim this is a permanently optional feature.

> You know you don't HAVE to use systemd-homed right?

For now. Until GNOME pulls it in as a dependency.

If you want to weaken your security then that's what you want to do. Then just don't use it.

And also, this is just the default, the mechanism is general, how to do this unlocking can be done in many ways by other people who want to use these tools.

>You don't ever remotely log into your desktop??!

Is this really so common as to deserved two questions marks and an exclamation point? As one datapoint, if I've left files on my desktop at home that I need from work, I get fired.

I often log into my media server in my apartment to start a movie or tv show playing with mpv. Is that reasonable? I think that's a reasonable usecase. mpv is a perfectly suitable media player, and ssh is a perfectly suitable way to log into a computer. Why shouldn't I do this?

Is it what most "normal people" do? Of course not! Most normal people buy a spyware 'smart TV', roku, or some other proprietary appliance. So why the hell should the common habits of the general population be considered? If their habits are to be the guiding principle of the linux desktop, I'll soon have no reason to use the linux desktop.

Incidentally at one of my former (FANG) workplaces, each developer was given a RHEL workstation and a windows or mac laptop. Using ssh from one's laptop to access the workstation while in meetings, working from home (including oncall in the middle of the night), etc was common and permitted. This is not as crazy as you seem to think.

Yes? How else am I supposed to access my workstation remotely? Right now I just log in to the company VPN and ssh to my workstation when I need to do work from home. Remote access is a basic feature that has just worked on Linux since as far back as I can remember. And I remember when I had to twiddle the TV antenna to get good signal.

Obviously we live in very different worlds. I am not supposed to access my workstation remotely. Again, if I managed to do it I would be fired.

But that is policy and nothing technical.

I know the video had limited times, but in regards to enterprise authentication, is there any consideration to data ownership? In this scheme can the enterprise, or any superior device/data owner have a master key to decrypt home directory of a subordinate user?

I do not believe so. The homectl docs state that the encryption password == user password without any alternative:

https://www.freedesktop.org/software/systemd/man/homectl.htm...

Thanks for that link. I see further down that PKCS#11 is supported:

> Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV smartcard) that shall be able to unlock the user account. The security token URI should reference a security token with exactly one pair of X.509 certificate and private key. A random secret key is then generated, encrypted with the public key of the X.509 certificate, and stored as part of the user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the account and associated resources. See below for an example how to set up authentication with security token.

Key hierarchy management can probably be delegated to an external system.

FWIW, if you want to do dynamic mounted encrypted home you can do so today with pam_mount pretty easily. The two passwords can even disagree, you'll just get prompted twice during the login process.

In fedora, at least, it requires only three lines of configuration changes (adding the pam hooks, and setting up the mount point in the pam_mount config).

> encryption password == user password

What if your password is in LDAP, and you change it the OpenLDAP back-end? Or if you have OpenLDAP talk to AD (via SASL) for password checks, but the rest of the GECOS & group is in LDAP? Is Kerberos covered? How is NFS handled? Automounts?

Doing a ^F I find no mention in the man page of either LDAP or Kerberos.