4 ms·

Maybe stop using Macs as multiuser servers? Unavailability of FileVault-mounted home directories when not logged in has been the case since Tiger. I'm curious

Maybe stop using Macs as multiuser servers? Unavailability of FileVault-mounted home directories when not logged in has been the case since Tiger. I'm curious - if the OpenSSH config files are not available - how do they start sshd? If the system keys are encrypted, how do they accept connections? There's a surprising lack of detail here.

numbsafari 1y ago
How about I just want to access my files remotely after a reboot occurs without having to get to the device at my house? Agreed, though… MacOS isn’t a proper multi-user system and X is Not Unix…
- gjsman-1000 1y ago
  macOS is a Unix by pedigree; Linux is not. https://en.wikipedia.org/wiki/List_of_Unix_systems#/media/File:Unix_history-simple.svg https://en.wikipedia.org/wiki/List_of_Unix_systems#/media/Fi... I have to dig out this chart when people complain about macOS's "non-standard utilities." Linux's GNU tools are the ones that aren't standard. If anything, Linux did an "embrace, extend, extinguish" against Unix in general.
  - dangus 1y ago
    I’d add that it is rather prescriptive to declare that macOS is not a “proper multi-user system.” It is quite capable of handling multiple users. Maybe just not in the way that certain people want it to.
  - jen20 1y ago
    It's also not just Unix by pedigree, but also by certification [1]. [1]: https://www.opengroup.org/openbrand/certificates/1223p.pdf https://www.opengroup.org/openbrand/certificates/1223p.pdf
- jacobgkau 1y ago
  In addition to the pedigree that someone else pointed out, macOS is also explicitly certified as UNIX by the legal stewards of that name: https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/ This includes Tahoe specifically: https://www.opengroup.org/openbrand/register/brand3725.htm https://www.opengroup.org/openbrand/register/brand3725.htm
dangus 1y ago
I can’t imagine it’s too hard, I think password authentication is the key. Your user password is the same as your FileVault unlock password. I think that there’s a pre-unlock and post-unlock ssh session trick going on. The pre-unlock session just doesn’t have access to anything in the data volume and is able to use the provided password to unlock the data volume. This would explain why it won’t work with ssh key authentication.
- angulardragon03 1y ago
  Yeah iirc they have moved some stuff around that sshd relied on into the pre-boot volume, so it works exactly as you describe.
cyberax 1y ago
I think the SSH host keys are in the system partition ('/private' directory)? It's not protected by FileVault. This leaves out a possibility of a MITM. An attacker can steal the unencrypted machine host keys and pretend to be your computer. And since you're entering a clear-text password, it's easy to sniff. Moving the host keys into hardware root-of-trust would help. But macOS Secure Enclave barely supports that, and it's also pretty slow.
- _mikz 1y ago
  I have my private keys in Secure Enclave. Why the machine would not have own private keys there?
  - aaroncarson 1y ago
    100% - Apple wouldn’t be so stupid as to move the private host keys to an unencrypted partition when the Secure Enclave is _right there_. No way is the Secure Enclave too slow for this - it’s exactly what it’s designed to do!
    - davidczech 1y ago
      They are encrypted with a SEP key when stored in preboot volume.
    - cyberax 1y ago
      I misspoke. I meant a partition that is only protected by the machine-level keys. But then I also realized that it's still likely to be hard to access for the attacker. So I don't really have much issues with that.
  - cyberax 1y ago
    > I have my private keys in Secure Enclave. Really? Secure Enclave supports only one asymmetric algorithm. With only some limited usages.
    - SXX 1y ago
SXX 1y ago
> Unavailability of FileVault-mounted home directories when not logged in has been the case since Tiger. Since release of M1 now whole data partition is encrypted with single key and not home directories. And likely there no way at all to encrypt home directories with separate keys on modern macOS.

numbsafari 1y ago

How about I just want to access my files remotely after a reboot occurs without having to get to the device at my house? Agreed, though… MacOS isn’t a proper multi-user system and X is Not Unix…

gjsman-1000 1y ago
macOS is a Unix by pedigree; Linux is not. https://en.wikipedia.org/wiki/List_of_Unix_systems#/media/File:Unix_history-simple.svg https://en.wikipedia.org/wiki/List_of_Unix_systems#/media/Fi... I have to dig out this chart when people complain about macOS's "non-standard utilities." Linux's GNU tools are the ones that aren't standard. If anything, Linux did an "embrace, extend, extinguish" against Unix in general.
- dangus 1y ago
  I’d add that it is rather prescriptive to declare that macOS is not a “proper multi-user system.” It is quite capable of handling multiple users. Maybe just not in the way that certain people want it to.
- jen20 1y ago
  It's also not just Unix by pedigree, but also by certification [1]. [1]: https://www.opengroup.org/openbrand/certificates/1223p.pdf https://www.opengroup.org/openbrand/certificates/1223p.pdf
jacobgkau 1y ago
In addition to the pedigree that someone else pointed out, macOS is also explicitly certified as UNIX by the legal stewards of that name: https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/ This includes Tahoe specifically: https://www.opengroup.org/openbrand/register/brand3725.htm https://www.opengroup.org/openbrand/register/brand3725.htm

dangus 1y ago

I can’t imagine it’s too hard, I think password authentication is the key. Your user password is the same as your FileVault unlock password. I think that there’s a pre-unlock and post-unlock ssh session trick going on. The pre-unlock session just doesn’t have access to anything in the data volume and is able to use the provided password to unlock the data volume. This would explain why it won’t work with ssh key authentication.

angulardragon03 1y ago
Yeah iirc they have moved some stuff around that sshd relied on into the pre-boot volume, so it works exactly as you describe.

cyberax 1y ago

I think the SSH host keys are in the system partition ('/private' directory)? It's not protected by FileVault. This leaves out a possibility of a MITM. An attacker can steal the unencrypted machine host keys and pretend to be your computer. And since you're entering a clear-text password, it's easy to sniff. Moving the host keys into hardware root-of-trust would help. But macOS Secure Enclave barely supports that, and it's also pretty slow.

_mikz 1y ago
I have my private keys in Secure Enclave. Why the machine would not have own private keys there?
- aaroncarson 1y ago
  100% - Apple wouldn’t be so stupid as to move the private host keys to an unencrypted partition when the Secure Enclave is _right there_. No way is the Secure Enclave too slow for this - it’s exactly what it’s designed to do!
  - davidczech 1y ago
    They are encrypted with a SEP key when stored in preboot volume.
  - cyberax 1y ago
    I misspoke. I meant a partition that is only protected by the machine-level keys. But then I also realized that it's still likely to be hard to access for the attacker. So I don't really have much issues with that.
- cyberax 1y ago
  > I have my private keys in Secure Enclave. Really? Secure Enclave supports only one asymmetric algorithm. With only some limited usages.
  - SXX 1y ago

SXX 1y ago

> Unavailability of FileVault-mounted home directories when not logged in has been the case since Tiger. Since release of M1 now whole data partition is encrypted with single key and not home directories. And likely there no way at all to encrypt home directories with separate keys on modern macOS.