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!

I actually turned it on after the update with General > Sharing > Remote Login.

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.

Ah, I use Remote Management because I also do screen sharing on this mac mini from time to time

If you had it on prior to the MacOS update with FileVault off, MacOS automatically enabled FileVault and didn't flip the switch with SSH to support this.

So now I have a Mac mini that I have to unmount and connect to a screen to get working again. blerg

One question for you or anyone who tried it. SSH host (mac) key pre disk unlock is randomly generated and persistent?

I'd be surprised if it were a different key from the regular host key.

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.

You can solve this with HostKeyAlias, but yeah I doubt Apple would do this. Considering other comments mentioning "just SSHing after reboot" it's certainly the same host key.

  https://stackoverflow.com/questions/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

PS: Another option obviously UserKnownHostsFile, but I would better keep single known hosts file.

Wow, TIL about HostKeyAlias and CheckHostIP. Especially the latter sounds super useful when it comes to frequently changing private IPs. Thank you!

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.

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!

You could have another script that immediately triggers the Lock Screen after boot...but agreed this comes with many compromises.

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.

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.

When it comes to disk encryption, at least in the home, the threat model isn't somebody sitting around in your home finding a way to exfiltrate the currently-unlocked filesystem; It's someone taking the computer or the drive with them and leaving.

In your analogy, the key atop the vault vanishes as soon as the vault is moved from its location (loses power).

If that was the case (maybe it is, I don’t know), then how does the proposed solution help against power outages, which was asked for?

That wasn’t what was asked for. The original reason given was to require a password on cold boot, but not require a password when rebooting e.g. for an OS update

Well, you've asked me to quote in another subthread, I did. Since I don't fully get what you're referring to now, can you please quote?

It makes sense temporarily. You can always move the key to your pocket later if nobody steals it.

Oh yeah, I get it. Just pointing out what this is doing, and why you should probably not always do this, for example.

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.

No, the scenario was power outage at an unknown time in the future, not immediate reboot.

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.

The stated problem was power outages. I did not verify the syntax of the proposed solution, but -1 looks like it disables the delay. So, indefinitely until the next reboot? Which, if the key is indeed saved in NVRAM (I don’t know), means someone can take the machine and have it unlocked at their destination.

You’re going to have to quote that the stated problem was power outages. The first comment in this thread was taking about how the linked article solves the power outage problem.

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.

First comment:

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

It used to be NVRAM at least, but that was before the integrated Secure Enclave. Now it could in theory store it there and only unlock if the boot chain is validated (similar to the automatic TPM-based unlock that Windows uses by default).

Right, but my point was, if the idea is to do this to have an automatic unlock on power outages (and if this persists across power outages), it’s not just a few minutes, it’s indefinitely.

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.

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.

A Mac mini (or studio, or however it's called these days) is supposedly one of the more affordable ways to self-host LLMs these days.

Being able to resume such a server after a power outage when traveling sounds great.

I run a render farm on macs. I'm getting so much more performance from a basic Mac Mini that it's not even funny.

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.

A couple of reasons for me to run it: - time machine - photos.app backup (have photos.app download local copies of your iCloud photos library, backup the photos.app files) - build server for ios/ipados/macos apps

I use linux SMB targets for Time Machine and PhotoSync and it works just fine. There's also icloudpd, but it requires ADP off.

I use it as a plex server and it can handle anything you throw at it. Previously plex was running on the synology NAS itself and it would choke with a couple concurrent transcodes

Build servers.

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.

I'm browsing for something to replace my M1 mini, possibly a non-Mac. With Tahoe around the corner, running a Mac headless seems to be the best option to cope with the redesign.

Have you considered https://asahilinux.org/ ?

Unfortunately they only support M1/M2 (last time I checked - hardstuck). It would be a great choice to repurpose existing hardware, but I wouldn't go shopping for Asahi specifically.

It sounds like they already are, and questioning what benefits having a remote MacOS server would give them.

Time Machine backups could be one reason?

Time Machine does not require Mac. You can point it to e.g. a SMB share as destination as well.

I mean, why not? There's few drawbacks. Low power usage, high performance, stable OS that can about the same software Linux can. You get the added benefit of interfacing with Apple's ecosystem and iCloud, so you could e.g. back up your Photos database remotely. You can remote in and have a fully featured desktop available anywhere.

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

What's wrong with just connecting to mini over VNC? You can even firewall it off and tunnel VNC connection over SSH, or tailscale / zerotier.

I dont think there is any single action you cant perform on Mini remoty. Once it's unlocked that is.

Maybe actions like "Please enter your AppleID", or a popup showing on your physical screen saying "system has to restart now", which doesn't show in VNC. In any case, you don't want this in a server because these are usually used over SSH and those types of popup will simply not be seen. Also, servers are usually administrated using scripting and those popups wouldn't work anyway.

maybe. but until then...

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.

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?

autossh + sshpass. Work perfectly.

Oh, this is nice indeed.