2. If someone has compromised your iCloud account and/or device, you have bigger things to worry about
3. No
Yes and no according to Glenn Fleishman. Storing FileVault recovery keys in iCloud Keychain wasn't a choice before. The old iCloud recovery method wasn't end to end encrypted. But iCloud Keychain is. So calling it escrow is debatable. And old recovery keys aren't added to iCloud Keychain. But new recovery keys are stored in iCloud Keychain if enabled.[1]
[1] https://sixcolors.com/post/2025/09/filevault-on-macos-tahoe-...
FWIW and having not looked yet (since I never upgrade major macOS versions anymore without a good 3-5 months going by and the first 2-3 minor fixes first) my default assumption is it's still possible to not escrow recovery keys, if only because plenty of people don't use iCloud keychain at all (including myself), and also because I know for sure that you can use configuration profiles to control FV recovery key escrow already. That'd be a requirement for lots of business usage so even if it needs a profile to use should still be there? But again this all seems orthogonal to the issue at hand. Stuff does crash or need updates that require a reboot and previously you either needed to turn off FV entirely or use a hardware workaround for GUI access (ie, setup a basic SBC with HDMI/USB in and use it as a bridge or use a premade solution along the lines of PiKVM [0]). It's definitely a small but nice (and feels rare nowadays from Apple) remote admin gesture to let it be done in software like it should have been long ago.
----
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.
Agreed, though… MacOS isn’t a proper multi-user system and X is Not Unix…
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.
It is quite capable of handling multiple users. Maybe just not in the way that certain people want it to.
[1]: https://www.opengroup.org/openbrand/certificates/1223p.pdf
This includes Tahoe specifically: https://www.opengroup.org/openbrand/register/brand3725.htm
This would explain why it won’t work with ssh key authentication.
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.
2. The notion of someone having access to / compromising your device in order to capture SSH creds doesn't strike me as realistic
sudo fdesetup authrestart -delayminutes -1
I think this doesn’t work from cold boot, only warm reboot.
That’s what I saw someone say on mastodon the other day.
Neat! I thought it was odd that I was able to SSH into my Mac after upgrading to Tahoe the other night – part of me wondered if I actually hit that "Upgrade" button before walking away. This is a welcome change though; I don't usually shut my Mac down but there have been a few times where I'm working away from home and need to SSH into my Mac only to remember that I'd installed some major update the night before.
Specifically, if you restart and opt to restart apps, they can come up before all volumes have been decrypted and mounted. If your shell is on one such volume, your terminal emulator may fail to start, for example. This can happen when using Nix to install your shell, for example.
I imagine this may be even easier to hit over SSH unless the underlying problem was resolved.
In the case of SSH though, I assume retrying after a second or so would be enough. You probably have some sort of retry mechanism to deal with network failures anyway.
(Here's a nickel kid...)
(It's technically not full-disk encryption because the kernel and initrd are in plaintext, but everything else is)
With the TPM you can fully disable password auth over SSH.
systemd-cryptenroll seems to be about storing encryption keys into the TPM so that they can be decrypted automatically at boot (?)
Apologies if I misunderstood something.
syndeo•1h ago
Now THAT is a welcome change!