2. If someone has compromised your iCloud account and/or device, you have bigger things to worry about
3. No
That doesn't mean all my security should be a house of cards with a single point of failure in the form of my iCloud account and/or device(s). Someone shouldn't be able to get the keys to the castle just by compromising any single one of those.
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-...
iCloud Keychain is NOT the same security as a hardcopy written down recovery key, which is what I used before. This is absolutely a forced change in security policy that was not communicated or opted into by the user.
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.
----
Belt and suspenders.
Makes sense when wiping the whole drive though.
At least if you have an iCloud account attached to your profile (I have no idea what happens if you don't), the upgrade process will automatically and without notification or asking consent add your recovery key to the iCloud Keychain. It does tell you afterwards what it so helpfully did.
2) copy unencrypted SSH host key from it to a new computer (which necessarily must not be stored in the data volume), configured with the network identity of original computer
3) leave new computer in place of original to capture remote SSH-to-unlock attempt
4) use knowledge of password to unlock original's filevault at your leisure somewhere offsite
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.
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.
Really? Secure Enclave supports only one asymmetric algorithm. With only some limited usages.
What you can do though is use Secure Enclave powered app for storing and managing access to the keys. So basically app like "secretive" run on your normal OS, but isolated and only it can access keys, use them and there no export function even with admin privileges.
AFAIK this will fail if there is a local root exploit on macOS, but still much better than keeping keys in plain text.
But that's it.
Anything more complicated is not possible. You can't even upload your existing key into the SE.
So "secretive" and similar software is not as secure as let's say hardware token.
If I'm wrong please correct me, but when I researched the topic I come to this conclusion.
This is the initial inspiration for Secretive: https://github.com/sekey/sekey - it uses the SE to generate and store the actual private key, so it never leaves the machine. Hence its limitations.
2. The notion of someone having access to / compromising your device in order to capture SSH creds doesn't strike me as realistic
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.
sudo fdesetup authrestart -delayminutes -1
So, sure, it's a bit like leaving the key on top of the safe... while you have the safe open. Which isn't all that odd.
In your analogy, the key atop the vault vanishes as soon as the vault is moved from its location (loses power).
But the sub-thread about using the existing utils is only for solving the unlock on reboot problem, and explicitly not solving the cold boot unlock problem.
> So you're saying i can now have a fully remote mac mini server with auto-reboot on power outage without the need to physically log ...
Reply:
> You can also do this: [...] -delayminutes -1 [...] which will make the computer auto login to the chosen account on next reboot, without having to type in a password. Only lasts once. Has obvious security downsides though but that might be fine.
Even though I haven't checked, the "-delayminutes -1" very much sounds to me like it disables the automated reboot, so it waits until the machine reboots for other reasons. Given this and given that it is a direct reply, I personally took it as another solution to the power outage problem, the "reboot" in question actually being a cold boot due to the power outage.
Note that I haven't verified whether this works after removing power.
I just want me to able to remotely login!
But if your Mac is physically secure, and has no keyboard or monitor on it anyway, I don't quite understand the risk? Remote login still requires the password after this of course. But if physical security is a concern it makes sense.
Also I suppose there's other risks from having a decryption key sitting in NVRAM.
Having to physically login to a remote Mac that has FieVault enabled to get it online after a power outage is not ideal!
So will I be able to actually remote into the GUI now after a reboot?
I've looking at getting a Mac mini for my homelab again, but thinking I'll need one of those remote enable KVM devices!
1. Enable: General > Sharing > Remote Management
2. After reboot, when trying to SSH you get this message:
"This system is locked. To unlock it, use a local account name and password. Once successfully unlocked, you will be able to connect normally."
3. Once you successfully ssh, the ssh connection is closed, and this message is shown:
"System successfully unlocked. You may now use SSH to authenticate normally."
4. You have to re-ssh and you're in!
Most SSH clients I know show a big and often non-overridable warning in case of a changed host key and don't allow (at least not TOFU-style) trusting two keys.
> Most SSH clients I know show a big and often non-overridable warning in case of a changed host key and don't allow (at least not TOFU-style) trusting two keys.
https://stackoverflow.com/questions/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but
It's worth noting I had to disable and re-enable (I had it enabled to begin with) this option for SSH to start working.
Remote Management option didn't change anything for me and is currently turned off.
So now I have a Mac mini that I have to unmount and connect to a screen to get working again. blerg
Time Machine backups could be one reason?
Also a bit of CI on these because why not.
Managing remote macOS instances is a constant PITA, including, but not limited to ssh access quirks.
Currently, someone has to head down to the basement and turn the mac on manually if it dies/crashes for any reason. Huge pain in the psu.
Being able to resume such a server after a power outage when traveling sounds great.
I dont think there is any single action you cant perform on Mini remoty. Once it's unlocked that is.
Having it work with just properly encrypted SSH is really welcome change.
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.
FWIW you can fix the shell issue by wrapping your shell in a shim that essentially runs wait4path on the nix store before exec'ing your real shell. I set up my environment to install that shim binary directly onto the data volume at a known path so it can be used as my login shell.
And thanks for the pointer, I actually have the same fix in my config with the nice benefit of only adding a single non-changing entry to /etc/shells. It might be worth up streaming something like this to nix-darwin, so we don't all go implement essentially the same fix.
(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.
https://wiki.archlinux.org/title/Dm-crypt/Specialties#Remote...
However, I'd prefer that the box is not on the general internet, but only over my tailscale net. I wonder if tailscale will also fit in the initramfs...
It's pretty incredible to be able to dump all this stuff directly into the boot system. Now to see what Omarchy has done to give the fancy LUKS password entry...
Apple is able to achieve this securely because their devices are not fully encrypted. They can authenticate/sign the unencrypted system partition.
You auth the initrd too
Security is rarely convenient. Since the early OS X days, Apple seems to be willing to do things the more secure way even if it's a bit of a hassle. Seems to be paying off for them.
Apple sells remote management software* if you don't want to buy your own KVM solution, it's $79.99 but given that there are no per-user limits and it has been continually updated for ~20 years, I'd say it's often overlooked in discussions of remotely managing Macs.
If you want a free solution, Tahoe w/ ssh FileVault unlock makes using a Mac as a server more useful than ever with a non-Apple VNC product of your choice.
* Mac App Store link: https://apps.apple.com/us/app/apple-remote-desktop/id4099073...
This is the same reason why Apple has lost the education market to Chromebooks.
I don't think Macs would be a great platform for running a k8s cluster, but the power efficiency alone makes them a curious alternative to explore.
It was *not* common in mid-90s. x86 was commodity hardware - home PCs, early NT workstations. PHP was still written in Perl. Linux was a few years old - industry veterans (e.g. Greenspun) were throwing rocks at it.
Yes, the x86 platform was documented - through reverse-engineering efforts. Compaq was the first to produce PC clones, to IBM's great disdain.
Don't get me wrong - you're probably better off running Ampere. Just don't dismiss commodity hardware.
This wouldn't work with Apple products because Apple ultimately has control over the hardware. You don't want a server that suddenly shows "Please enter your AppleID" in the middle of something, for example.
Sun Microsystems were also big in universities. As were IBM. Lots of people believed the "servers have special hardware" voodoo back then, and parroted that it's bad news to run servers on consumer hardware.
Somehow, decades later, the meme refuses to die. Unlike Sun Microsystems. Or IBM's Unix server business.
If Google had used Apple appliances for their servers they would be violating the EULA and have lawyers knocking on their door.
Apple appliances are made for consumers. Apple's lawyers were not paid to cover business usecases, so they basically don't allow it.
The point is: commodity hardware is powerful, and it's interesting to explore its capabilities outside of its original purpose. Apple or not.
“I wonder why people keep writing that PHP was ever written in Perl. It never was. #php”
The PHP history page at one point claimed it was:
https://web.archive.org/web/20090426061624/http://us3.php.ne...
He may have had some Perl scripts on his computer before the 1.0 C release, but that’s a far cry from “PHP was written in Perl”.
With this attitude, we'd all still be running 2U Dell PowerEdge and poor Raspberry Pi would have gone out of business.
It's 2025, almost 2026. A web server from a few years ago has less power than consumer mac Mini today while using much more energy.
Throw out the advice that is from the era of physical install media and let's focus on specific (instead of general, unhelpful) advice as we move into the modern era where cheap computers are just fine.
Though those poweredges would have had it.
Any software RAID on macOS is a risk I wouldn't be willing to take, but that is another matter entirely and has nothing to do with ECC.
There’s no reason you shouldn’t be able to boot all the way up including networking, before requiring the data volume to be decrypted.
I know they do a lot of clever things with overlays too, to make it look like you’re writing to the system partition when you’re actually writing to the data partition. It’s a pretty welcome change if FileVault can just skip encrypting the sealed system volume altogether.
However the one thing stopping me is exactly what's solved here with the new MacOS. If I'm away for a few weeks, and the machine power cycles, the full disk encryption password still needs to be entered, in person, as far as I can tell. I'm running it under ProxMox, with the GPU in-person USB devices being passed to the VM. So the standard VNC viewer doesn't work for the setup.
It would be interesting to see if Omarchy tries somethnig similar...
This is incorrect. Macs do only a tiny partial boot before showing the login. The real work is done after the machine is unlocked.
When using OpenCore on a Hackintosh, the unlock login is almost instantly presented after OpenCore completes its part of startup. Only after the unlock does MacOS startup really do anything.
It's awesome that someone has managed to get ssh to do the unlock, but saying the data volume is "locked... after booting" is going too far.
[1]: https://support.apple.com/guide/security/boot-process-secac7...
syndeo•4mo ago
Now THAT is a welcome change!