>When FileVault is enabled, the data volume is locked and unavailable during and after booting, until an account has been authenticated using a password. The macOS version of OpenSSH stores all of its configuration files, both system-wide and per-account, in the data volume. Therefore, the usually configured authentication methods and shell access are not available during this time. However, when Remote Login is enabled, it is possible to perform password authentication using SSH even in this situation. This can be used to unlock the data volume remotely over the network. However, it does not immediately permit an SSH session. Instead, once the data volume has been unlocked using this method, macOS will disconnect SSH briefly while it completes mounting the data volume and starting the remaining services dependent on it. Thereafter, SSH (and other enabled services) are fully available.
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 in with a keyboard attached? Awesome
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.
I think the point of this technique is to be able to leave the machine locked on cold boot, but to be able to e.g. unlock it, put it to sleep, and go on vacation; and then, if you need to remotely reboot it, you can reboot it in such a way that it stays unlocked on next boot, rather than reverting to locked.
This only puts the key in NVRAM until the next restart - so if you run it just before you restart an attacker would have to happen to grab the device in those few minutes.
Biggest change for corporate non-personal Mac usage. Mac Minis are actually fairly good value and good quality for miscellaneous automation purposes. We started switching over to them at work, and the FileVault issue described here was actually one of the big things holding us back.
I guess this means the system volume is not encrypted with FileVault? It makes total sense, since it’s supposed to be sealed, read-only data, and identical for every macOS installation.
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.
> The capability to unlock the data volume over SSH appeared in macOS 26 Tahoe.
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.
Neat. Though I wonder if this suffers from the same race condition that the graphical session does when your shell is stored on a data volume.
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.
This is such a hilarious failure mode. I would never have imagined something like this to a problem.
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.
I've been playing with Omarchy ("highly opinionated" Arch configuration) which has full disk encryption, and was wondering if I could use it as my primary VM. While in person, I would get a full GPU accelerated desktop, with access to all the long-running compute jobs etc. that I'm doing otherwise.
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...
Can LaunchDaemons spin up after this initial unlock? I'm trying to get my Mac Mini server to run things regardless of my login status. It would be great to get FileVault enabled on the server with this. I'm OK to manually login whenever the power goes out.
Kinda struggling to think of what, beyond the well understood risks of using password-based SSH at all. But that's easily ameliorated by sticking it behind Wireguard or something similar. I think this is a pretty welcome change vs turning off FV entirely which I've had to do with Mac servers in the past.
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
I’m not sure if they do this, but nothing would stop Apple from putting the SSH host key in the Secure Enclave. This would prevent the extract the SSH host (private) key step.
Tahoe now escrows your FileVailt key to the iCloud keychain, even if that is something you explicitly opted out of before. Can this recovery key be used to unlock over SSH?
> Tahoe now escrows your FileVailt key to the iCloud keychain, even if that is something you explicitly opted out of before.
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]
I don't know but I'm still not seeing the relevance? The threat/target scenarios in general for FDE are physical theft of a device, hardware servicing by 3rd parties, and dealing with end of life (either due to replacement or hardware failure). FDE means that "erasing all data securely" can involve simple key purging instead of extremely time consuming zeroing/overwriting or physical destruction. But it's no barrier nor meant to be any barrier against hot online attacks, if someone is able to get admin remote access to a running system without authorization that is the problem and it'd be equally the problem whether the machine was cold booted or already booted. And if they illegitimately possess the recovery key then it's a problem whether remote or physically present.
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.
For SSDs that doesn’t actually guarantee deletion - there could still be some over-provisioned erase blocks that have the old data due to wear leveling.
Interesting. I thought even networking didn't come up after a cold boot on a system with FileVault until there was a local login, which is a big reason I do not enable FileVault on my office workstation. I guess this has been changed on Tahoe too?
This is not the same thing is it? Arch Wiki mentions something about having to install a separate ssh server into initramfs to support ssh’ing into fully encrypted systems.
systemd-cryptenroll seems to be about storing encryption keys into the TPM so that they can be decrypted automatically at boot (?)
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...
Thanks! I'm just getting back into Linux boot issues for the first time in multiple decades, and boy is it different than I remember.
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...
Correct, someone with physical access could run a MitM attack and steal your passphrase. I just find this extremely unlikely, so I honestly don't care.
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?
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/
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.
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.
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.
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!
>When FileVault is enabled, the data volume is locked and unavailable during and after booting, until an account has been authenticated using a password. The macOS version of OpenSSH stores all of its configuration files, both system-wide and per-account, in the data volume. Therefore, the usually configured authentication methods and shell access are not available during this time. However, when Remote Login is enabled, it is possible to perform password authentication using SSH even in this situation. This can be used to unlock the data volume remotely over the network. However, it does not immediately permit an SSH session. Instead, once the data volume has been unlocked using this method, macOS will disconnect SSH briefly while it completes mounting the data volume and starting the remaining services dependent on it. Thereafter, SSH (and other enabled services) are fully available.
Now THAT is a welcome change!
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 in with a keyboard attached? Awesome
You can also do this:
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.I was also aware of this - but I dont want my Mac to actually auto login, for obvious reasons!
I just want me to able to remotely login!
But then you could just disable FileVault?
I think the point of this technique is to be able to leave the machine locked on cold boot, but to be able to e.g. unlock it, put it to sleep, and go on vacation; and then, if you need to remotely reboot it, you can reboot it in such a way that it stays unlocked on next boot, rather than reverting to locked.
Generally I have used fdesetup to do remote OS upgrades: do this just before an OS upgrade so that on reboot I can still log in.
It's still a little bit like putting your jewelry in a safe, and leaving the key on top of the safe.
I mean, I assume you'd set the unlock-on-reboot flag, and then immediately reboot — at which point the unlock-on-reboot flag gets automatically unset.
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.
This only puts the key in NVRAM until the next restart - so if you run it just before you restart an attacker would have to happen to grab the device in those few minutes.
I'm hoping that's the case!
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!
You’ve always been able to do this, just not in combination with FileVault.
How would you automatically login via ssh?
Biggest change for corporate non-personal Mac usage. Mac Minis are actually fairly good value and good quality for miscellaneous automation purposes. We started switching over to them at work, and the FileVault issue described here was actually one of the big things holding us back.
I guess this means the system volume is not encrypted with FileVault? It makes total sense, since it’s supposed to be sealed, read-only data, and identical for every macOS installation.
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.
> The capability to unlock the data volume over SSH appeared in macOS 26 Tahoe.
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.
Neat. Though I wonder if this suffers from the same race condition that the graphical session does when your shell is stored on a data volume.
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.
Apple does a “userspace reboot” (killing all processes) after device unlock to categorically solve this problem
This is such a hilarious failure mode. I would never have imagined something like this to a problem.
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.
I've been playing with Omarchy ("highly opinionated" Arch configuration) which has full disk encryption, and was wondering if I could use it as my primary VM. While in person, I would get a full GPU accelerated desktop, with access to all the long-running compute jobs etc. that I'm doing otherwise.
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...
You've been able to bake a dropbear into the initramfs for, well, ever on linux
Thanks for the pointer! Looks like tailscale also has at least 3 implementations for initramfs too:
https://news.ycombinator.com/item?id=45296075
It’s such a welcome change. I have filevault disabled specifically for that purpose.
Can LaunchDaemons spin up after this initial unlock? I'm trying to get my Mac Mini server to run things regardless of my login status. It would be great to get FileVault enabled on the server with this. I'm OK to manually login whenever the power goes out.
There’s an attack vector in there somewhere.
Kinda struggling to think of what, beyond the well understood risks of using password-based SSH at all. But that's easily ameliorated by sticking it behind Wireguard or something similar. I think this is a pretty welcome change vs turning off FV entirely which I've had to do with Mac servers in the past.
1) steal computer,
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
I’m not sure if they do this, but nothing would stop Apple from putting the SSH host key in the Secure Enclave. This would prevent the extract the SSH host (private) key step.
Tahoe now escrows your FileVailt key to the iCloud keychain, even if that is something you explicitly opted out of before. Can this recovery key be used to unlock over SSH?
> Tahoe now escrows your FileVailt key to the iCloud keychain, even if that is something you explicitly opted out of before.
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-...
I don't know but I'm still not seeing the relevance? The threat/target scenarios in general for FDE are physical theft of a device, hardware servicing by 3rd parties, and dealing with end of life (either due to replacement or hardware failure). FDE means that "erasing all data securely" can involve simple key purging instead of extremely time consuming zeroing/overwriting or physical destruction. But it's no barrier nor meant to be any barrier against hot online attacks, if someone is able to get admin remote access to a running system without authorization that is the problem and it'd be equally the problem whether the machine was cold booted or already booted. And if they illegitimately possess the recovery key then it's a problem whether remote or physically present.
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.
----
0: https://pikvm.org/
Call me crazy, (“you’re crazy!”) but I still zero all storage before destruction, sale or repurposing.
Belt and suspenders.
For SSDs that doesn’t actually guarantee deletion - there could still be some over-provisioned erase blocks that have the old data due to wear leveling.
1. Keychain is local if you don't enable iCloud
2. If someone has compromised your iCloud account and/or device, you have bigger things to worry about
3. No
Yup. My post-Blastdoor reaction to these writeups is always one of tentative suspicion.
Interesting. I thought even networking didn't come up after a cold boot on a system with FileVault until there was a local login, which is a big reason I do not enable FileVault on my office workstation. I guess this has been changed on Tahoe too?
Networking always comes up after cold boot, but WiFi passwords are stored on the encrypted volume. So, it depends on whether you use WiFi!
And also depends on your using DHCP?
I guess it is need, so that the IT department may revoke keys remotely.
Is there a way to somehow authenticate with ssh key instead?
Friendly reminder that you've been able to automatically unlock fully-encrypted Linux systems via TPM for years since it was added to systemd...
(Here's a nickel kid...)
This is not the same thing is it? Arch Wiki mentions something about having to install a separate ssh server into initramfs to support ssh’ing into fully encrypted systems.
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.
I'm looking for what you're describing, some way to remote unlock a system. Is this the wiki page you're talking about?
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...
Yeah I was looking at that page. Found this btw: https://github.com/darkrain42/tailscale-initramfs
Thanks! I'm just getting back into Linux boot issues for the first time in multiple decades, and boy is it different than I remember.
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...
and I imagine that the initramfs is not encrypted and trivially modifiable?
Apple is able to achieve this securely because their devices are not fully encrypted. They can authenticate/sign the unencrypted system partition.
https://mastodon.social/@pid_eins/113404099228886304
You auth the initrd too
More similar to the usage pattern in the original post is "dropbear-initramfs", e.g. https://wiki.debian.org/DropBear
But that uses TPM backed keys only protected by the TPM PSRs. Someone could still swipe your box and unlock the disk.
Also possible without a TPM: you just put openssh into the initrd, so you can log in and type the password to unlock the root.
(It's technically not full-disk encryption because the kernel and initrd are in plaintext, but everything else is)
What do you authenticate against? Your shadow file is in the unencrypted area leaving it susceptible to offline attack.
With the TPM you can fully disable password auth over SSH.
Correct, someone with physical access could run a MitM attack and steal your passphrase. I just find this extremely unlikely, so I honestly don't care.
Link?
https://www.freedesktop.org/software/systemd/man/251/systemd...
[dead]
[dead]
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.
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…
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/
This includes Tahoe specifically: https://www.opengroup.org/openbrand/register/brand3725.htm
macOS is a Unix by pedigree; Linux is not.
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's also not just Unix by pedigree, but also by certification [1].
[1]: https://www.opengroup.org/openbrand/certificates/1223p.pdf
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.
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.
Yeah iirc they have moved some stuff around that sshd relied on into the pre-boot volume, so it works exactly as you describe.
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.
1. The drive is encrypted and practically impossible to access on modern Macs regardless of FileVault status
2. The notion of someone having access to / compromising your device in order to capture SSH creds doesn't strike me as realistic
Thats how all major supercomputer was hacked for crypto.
I have my private keys in Secure Enclave. Why the machine would not have own private keys there?
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!
They are encrypted with a SEP key when stored in preboot volume.