Tahoe FileVault: iCloud Keychain and SSH
When setting up FileVault, you used to be presented with two choices:
- View the Recovery Key, write it down, and keep it safe. It’s never presented again. (But as long as you can log in, you can toggle FileVault and get a new key.)
Use your iCloud account to store the key in escrow. However, the key is not end-to-end encrypted, so there was always the slight potential that the key could be recovered by anyone who gains access to your Apple Account and unlocks that escrow.
Neither choice was great; I always opted for the first.
Read the whole post for details about how booting with FileVault works.
Now the key can be shown after it’s first created, which makes it easier to retrieve it without cycling FileVault off and on to regenerate the Recovery Key. And, instead of using basic Apple Account encryption, protected just by a password, the Recovery Key is now stored in your end-to-end encrypted iCloud Keychain and accessible via the Passwords app.
So you now need a trusted device rather than just your Apple Account password to get at the recovery key.
apple_ssh_and_filevault(7) (via Hacker News):
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.
macOS 26, despite all its visual warts, lets you manage Macs with FileVault drive encryption enabled, even after a hard reboot or cold boot (like after a power outage).
I’ll show you how it works in this video.
Previously:
Update (2025-09-24): Miguel Arroz:
macOS Tahoe UI has a HUGE new feature for folks like me who have 24/7 Mac Minis running and access them remotely: you can now type the boot password remotely via SSH!
Power on the Mac, then SSH to it. A simple SSH server will handle your request. Typing the password there is equivalent to typing it on the keyboard. The connection then closes and the machine boots normally.
Combine this with “Start up automatically after a power failure” and you can ditch that KVM!
4 Comments RSS · Twitter · Mastodon
Credit where it's due. I've often griped about using macOS as a server platform nowadays, but much more so because you couldn't (really) operate a server without a logged-in session. That meant no FileVault, and no password. Well, now that changes! You still have to manually unlock, but at least you can plausibly do that over the network, and your data volume remains protected at all times. This is Apple at its best, when it *listens*.
This *almost* makes me want to upgrade my Mac server to macOS 26, because I would love to use FileVault with it, but I don't want to give up the ability to reboot it remotely or have it automatically recover after a power failure.
I'm not going to do it, mainly because it's an old 2012 iMac so it can't run macOS 26 anyway. But I wouldn't even if I could, since I imagine it will only cause my server to run worse and become less reliable. But it's rare these days to hear of a new feature from Apple that's actually enticing. If only those were the majority of new features from them!
@Bri For the remote reboot, this is already possible, using "fdesetup authrestart". Remote SSH potentially helps with the second part (hard reboot after powerfail), so long as your server isn't actually part of your remote connectivity (VPN server, etc).
But, sure, it's a moving part that can go wrong, so it's only a liability I would take on for sensitive data in an environment that has other servers for remote access etc. You might self-host your email on a Mac Mini now, for instance, in the fashion of the Helm server when that was a thing, with real hardware encryption of the internal flash.
On a related note, they've even gone and made VoiceOver usable in a Screen Sharing session. I no longer need my massive kludge of Blackhole+Sonobus to capture VoiceOver's audio. This, too, is very, very welcome, and makes the update non-negotiable for me.
That unlock-filevauöt-via-ssh-preboot will only work when the machine has a wired connection. There's no wifi until after there's keychain access , hence no network, hence no ssh.
