Apple: SSH and FileVault

[syndeo]

>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!

[reader9274]

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

[reader9274]

Just tested it and it works flawlessly!

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!

[varenc]

You can also do this:

   sudo fdesetup authrestart -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.

[SXX]

Yeah this is really cool. Before I had to setup hardware KVM for managing Mac build server. Extra $50 for SiSpeed NanoKVM is okay, but then KVM is effectively MiTM that can siphon the password for disk encryption.

Having it work with just properly encrypted SSH is really welcome change.

[drusklo]

Honest question; why would you want a server with mac os? I am asking because I thought about getting a mac mini for that purpose, because the hardware is great, but running mac os vs linux is what is throwing me off.

[amelius]

Until Apple triggers something that needs user input, such as an AppleID prompt. Then it's back to the data center ...

[alerighi]

I remember the time one of my coworkers accidentally enabled failevault on our CI machine, I had to take it out of the rack, dust it off, connect it to a monitor and keyboard, just to login and disable it. Good thing they made it can be unlocked with SSH, so in case it happens another time I can just do it remotely.

[firecall]

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!

[Reason077]

You’ve always been able to do this, just not in combination with FileVault.

[tristansokol]

How would you automatically login via ssh?

[ubermonkey]

Oh, this is nice indeed.

[georgeburdell]

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.

[nozzlegear]

> 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.

[watusername]

IIRC macOS upgrades will automatically store a FileVault token (basically `fdesetup authrestart`) before restarting, so the disk is automatically unlocked. It's not a Tahoe-specific thing.

[port11]

As someone staying away from Tahoe for as long as possible, it's a shame this wasn't backported.

[ninkendo]

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.

[astafrig]

Not always on networking; any WiFi passwords are on the data volume too.

[Cu3PO42]

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.

[lilyball]

Unlock over SSH terminates the connection after unlocking the data volume, so it doesn't even attempt to start the shell until you reconnect after it's fully booted up.

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.

[xrisk]

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.

[conradev]

Apple does a “userspace reboot” (killing all processes) after device unlock to categorically solve this problem

[floam]

That sounds like a perfect use case for the wait4path utility that’s shipped with the OS for decades

[daft_pink]

It’s such a welcome change. I have filevault disabled specifically for that purpose.

[epistasis]

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...

[halJordan]

You've been able to bake a dropbear into the initramfs for, well, ever on linux

[mmaunder]

There’s an attack vector in there somewhere.

[xoa]

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.

[lxgr]

Unless this somehow force-enables username/password authentication for SSH configs that otherwise enforce public-key auth, I can't really think of anything. Can you?

[bigyabai]

Yup. My post-Blastdoor reaction to these writeups is always one of tentative suspicion.

[AceJohnny2]

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?

[conradev]

Networking always comes up after cold boot, but WiFi passwords are stored on the encrypted volume. So, it depends on whether you use WiFi!

[johannes1234321]

I guess it is need, so that the IT department may revoke keys remotely.

[cjensen]

>When FileVault is enabled, the data volume is locked and unavailable during and after booting

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.

[mjg59]

"Someone" here is Apple - this is the Apple manpage for a Tahoe feature

[unloader6118]

You are confused. There are no "partial boot". This is fully booted in "before first unlock" state. Apple's public document always call it that way.

[nnx]

Is there a way to somehow authenticate with ssh key instead?

[oefrha]

Sadly you need to upgrade to the abomination that is macOS 26 to use this… Which I probably won’t do until latest Xcode drops support for macOS 15.

[kylehotchkiss]

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.

[lilyball]

LaunchDaemons don't rely on GUI login state so they should come up. If you use LaunchAgents then they won't start this way, but LaunchDaemons should be enabled once the data volume is unlocked and booting finishes.

[kylehotchkiss]

Real life experience on my headless Mac mini: I had SSH enabled and FileVault disabled. Updated to latest MacOS. FileVault was automatically enabled(!!!). Restart again. All Mac mini services invisible. SSH `Connection refused`.

[egorfine]

This has been such a PITA for us. A very, very welcome change. Given Apple's stance towards professional users I truly wonder how come this change has been considered at all. Maybe this was something Apple themselves struggled with.

[nunez]

Huge news for kick-starting Mac minis in a rack and remote lockout troubleshooting!

[sandreas]

I welcome this change, while I'm still asking myself whether macs did not support JetKVM or NanoKVM? This should allow way more flexible remote access solutions than having to use SSH.

[lossolo]

Finally, MacOS version of Linux dropbear + LUKS. I waited for this.

[odo1242]

They also seem to have added the ability to use external displays on the login screen while FileVault is enabled, which is pretty useful.

[leakycap]

Pretty useful is a kind way to put it, but I'm glad they fixed this.