Most active commenters
  • SXX(9)
  • anyfoo(8)
  • amelius(7)
  • adastra22(6)
  • leakycap(6)
  • rollcat(6)
  • cyberax(5)
  • johncolanduoni(5)
  • lxgr(4)
  • epistasis(4)

Apple: SSH and FileVault

(keith.github.io)
507 points ingve | 189 comments | 18 Sep 25 20:15 UTC | HN request time: 1.958s | source | bottom
1. syndeo ◴[18 Sep 25 20:32 UTC] No.45294655[source]▶
>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!

2. mmaunder ◴[18 Sep 25 20:37 UTC] No.45294710[source]▶
There’s an attack vector in there somewhere.
replies(3): >>45294968 #>>45295595 #>>45300986 #
3. sugarpimpdorsey ◴[18 Sep 25 20:39 UTC] No.45294739[source]▶
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.

replies(4): >>45294817 #>>45294905 #>>45294943 #>>45301003 #
4. reader9274 ◴[18 Sep 25 20:47 UTC] No.45294811[source]▶
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
replies(11): >>45295194 #>>45295532 #>>45295803 #>>45295918 #>>45296499 #>>45298327 #>>45298862 #>>45298996 #>>45299462 #>>45300622 #>>45300893 #
5. numbsafari ◴[18 Sep 25 20:47 UTC] No.45294817[source]▶
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…

replies(2): >>45294865 #>>45295141 #
6. nozzlegear ◴[18 Sep 25 20:49 UTC] No.45294844[source]▶
> 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.

replies(2): >>45301721 #>>45390034 #
7. gjsman-1000 ◴[18 Sep 25 20:51 UTC] No.45294865{3}[source]▶
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.

replies(2): >>45294925 #>>45295174 #
8. dangus ◴[18 Sep 25 20:54 UTC] No.45294905[source]▶
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.

replies(1): >>45295205 #
9. dangus ◴[18 Sep 25 20:57 UTC] No.45294925{4}[source]▶
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.

10. cyberax ◴[18 Sep 25 20:58 UTC] No.45294943[source]▶
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.

replies(2): >>45295020 #>>45295324 #
11. xoa ◴[18 Sep 25 21:01 UTC] No.45294968[source]▶
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.
replies(3): >>45295011 #>>45296172 #>>45301008 #
12. Cu3PO42 ◴[18 Sep 25 21:02 UTC] No.45294976[source]▶
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.

replies(4): >>45295432 #>>45296342 #>>45296948 #>>45297212 #
13. adastra22 ◴[18 Sep 25 21:06 UTC] No.45295011{3}[source]▶
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?
replies(3): >>45295348 #>>45295489 #>>45295543 #
14. _mikz ◴[18 Sep 25 21:07 UTC] No.45295020{3}[source]▶
I have my private keys in Secure Enclave. Why the machine would not have own private keys there?
replies(2): >>45295383 #>>45300066 #
15. daft_pink ◴[18 Sep 25 21:20 UTC] No.45295140[source]▶
It’s such a welcome change. I have filevault disabled specifically for that purpose.
16. jacobgkau ◴[18 Sep 25 21:20 UTC] No.45295141{3}[source]▶
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

17. jen20 ◴[18 Sep 25 21:24 UTC] No.45295174{4}[source]▶
It's also not just Unix by pedigree, but also by certification [1].

[1]: https://www.opengroup.org/openbrand/certificates/1223p.pdf

18. varenc ◴[18 Sep 25 21:25 UTC] No.45295194[source]▶
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.
replies(2): >>45295374 #>>45296504 #
19. angulardragon03 ◴[18 Sep 25 21:27 UTC] No.45295205{3}[source]▶
Yeah iirc they have moved some stuff around that sshd relied on into the pre-boot volume, so it works exactly as you describe.
20. pfexec ◴[18 Sep 25 21:37 UTC] No.45295315[source]▶
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...)

replies(7): >>45295330 #>>45295407 #>>45295507 #>>45295760 #>>45295936 #>>45299627 #>>45311400 #
21. Citizen8396 ◴[18 Sep 25 21:38 UTC] No.45295324{3}[source]▶
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

replies(1): >>45295356 #
22. trueismywork ◴[18 Sep 25 21:38 UTC] No.45295330[source]▶
Link?
replies(1): >>45295369 #
23. Citizen8396 ◴[18 Sep 25 21:40 UTC] No.45295348{4}[source]▶
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

replies(1): >>45297351 #
24. trueismywork ◴[18 Sep 25 21:41 UTC] No.45295356{4}[source]▶
Thats how all major supercomputer was hacked for crypto.
25. pfexec ◴[18 Sep 25 21:41 UTC] No.45295369{3}[source]▶
https://www.freedesktop.org/software/systemd/man/251/systemd...
26. eastbound ◴[18 Sep 25 21:42 UTC] No.45295374{3}[source]▶
But then you could just disable FileVault?
replies(2): >>45295885 #>>45296333 #
27. georgeburdell ◴[18 Sep 25 21:42 UTC] No.45295378[source]▶
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.
replies(1): >>45297133 #
28. aaroncarson ◴[18 Sep 25 21:42 UTC] No.45295383{4}[source]▶
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!
replies(2): >>45295530 #>>45300058 #
29. rnhmjoj ◴[18 Sep 25 21:45 UTC] No.45295407[source]▶
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)

replies(1): >>45295435 #
30. xrisk ◴[18 Sep 25 21:48 UTC] No.45295432[source]▶
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.

31. pfexec ◴[18 Sep 25 21:48 UTC] No.45295435{3}[source]▶
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.

replies(2): >>45295467 #>>45299124 #
32. AceJohnny2 ◴[18 Sep 25 21:51 UTC] No.45295453[source]▶
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?
replies(2): >>45295494 #>>45296357 #
33. rnhmjoj ◴[18 Sep 25 21:52 UTC] No.45295467{4}[source]▶
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.
34. pseudalopex ◴[18 Sep 25 21:54 UTC] No.45295489{4}[source]▶
> 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-...

replies(1): >>45297329 #
35. johannes1234321 ◴[18 Sep 25 21:54 UTC] No.45295494[source]▶
I guess it is need, so that the IT department may revoke keys remotely.
36. xrisk ◴[18 Sep 25 21:56 UTC] No.45295507[source]▶
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.

replies(2): >>45295907 #>>45296423 #
37. davidczech ◴[18 Sep 25 21:59 UTC] No.45295530{5}[source]▶
They are encrypted with a SEP key when stored in preboot volume.
38. ◴[18 Sep 25 21:59 UTC] No.45295532[source]▶
39. xoa ◴[18 Sep 25 22:00 UTC] No.45295543{4}[source]▶
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/

replies(2): >>45295879 #>>45297339 #
40. bigyabai ◴[18 Sep 25 22:07 UTC] No.45295595[source]▶
Yup. My post-Blastdoor reaction to these writeups is always one of tentative suspicion.
41. ninkendo ◴[18 Sep 25 22:22 UTC] No.45295747[source]▶
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.

replies(2): >>45296847 #>>45296989 #
42. kwk1 ◴[18 Sep 25 22:23 UTC] No.45295760[source]▶
More similar to the usage pattern in the original post is "dropbear-initramfs", e.g. https://wiki.debian.org/DropBear
43. Reason077 ◴[18 Sep 25 22:29 UTC] No.45295803[source]▶
You’ve always been able to do this, just not in combination with FileVault.
44. epistasis ◴[18 Sep 25 22:36 UTC] No.45295868[source]▶
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...

replies(1): >>45296146 #
45. qmr ◴[18 Sep 25 22:38 UTC] No.45295879{5}[source]▶
Call me crazy, (“you’re crazy!”) but I still zero all storage before destruction, sale or repurposing.

Belt and suspenders.

replies(2): >>45296391 #>>45297890 #
46. derefr ◴[18 Sep 25 22:38 UTC] No.45295885{4}[source]▶
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.
replies(2): >>45296130 #>>45296150 #
47. epistasis ◴[18 Sep 25 22:41 UTC] No.45295907{3}[source]▶
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...

replies(1): >>45296075 #
48. tristansokol ◴[18 Sep 25 22:43 UTC] No.45295918[source]▶
How would you automatically login via ssh?
replies(1): >>45300701 #
49. adestefan ◴[18 Sep 25 22:45 UTC] No.45295936[source]▶
But that uses TPM backed keys only protected by the TPM PSRs. Someone could still swipe your box and unlock the disk.
50. xrisk ◴[18 Sep 25 23:03 UTC] No.45296075{4}[source]▶
Yeah I was looking at that page. Found this btw: https://github.com/darkrain42/tailscale-initramfs
replies(1): >>45296219 #
51. kkylin ◴[18 Sep 25 23:10 UTC] No.45296130{5}[source]▶
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.
52. halJordan ◴[18 Sep 25 23:12 UTC] No.45296146[source]▶
You've been able to bake a dropbear into the initramfs for, well, ever on linux
replies(1): >>45296402 #
53. anyfoo ◴[18 Sep 25 23:13 UTC] No.45296150{5}[source]▶
It's still a little bit like putting your jewelry in a safe, and leaving the key on top of the safe.
replies(3): >>45296758 #>>45297354 #>>45298122 #
54. g-mork ◴[18 Sep 25 23:16 UTC] No.45296172{3}[source]▶
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

replies(1): >>45296355 #
55. epistasis ◴[18 Sep 25 23:22 UTC] No.45296219{5}[source]▶
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...

56. nnx ◴[18 Sep 25 23:34 UTC] No.45296303[source]▶
Is there a way to somehow authenticate with ssh key instead?
57. johncolanduoni ◴[18 Sep 25 23:38 UTC] No.45296333{4}[source]▶
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.
replies(1): >>45297622 #
58. conradev ◴[18 Sep 25 23:40 UTC] No.45296342[source]▶
Apple does a “userspace reboot” (killing all processes) after device unlock to categorically solve this problem
59. kylehotchkiss ◴[18 Sep 25 23:41 UTC] No.45296353[source]▶
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.
replies(1): >>45296978 #
60. johncolanduoni ◴[18 Sep 25 23:42 UTC] No.45296355{4}[source]▶
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.
61. conradev ◴[18 Sep 25 23:42 UTC] No.45296357[source]▶
Networking always comes up after cold boot, but WiFi passwords are stored on the encrypted volume. So, it depends on whether you use WiFi!
replies(2): >>45296698 #>>45297902 #
62. johncolanduoni ◴[18 Sep 25 23:47 UTC] No.45296391{6}[source]▶
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.
replies(1): >>45296827 #
63. epistasis ◴[18 Sep 25 23:48 UTC] No.45296402{3}[source]▶
Thanks for the pointer! Looks like tailscale also has at least 3 implementations for initramfs too:

https://news.ycombinator.com/item?id=45296075

64. conradev ◴[18 Sep 25 23:51 UTC] No.45296423{3}[source]▶
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.

replies(1): >>45296761 #
65. firecall ◴[19 Sep 25 00:05 UTC] No.45296499[source]▶
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!

66. firecall ◴[19 Sep 25 00:06 UTC] No.45296504{3}[source]▶
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!

replies(1): >>45306037 #
67. SoftTalker ◴[19 Sep 25 00:39 UTC] No.45296698{3}[source]▶
And also depends on your using DHCP?
68. derefr ◴[19 Sep 25 00:50 UTC] No.45296758{6}[source]▶
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.

replies(1): >>45297607 #
69. klooney ◴[19 Sep 25 00:51 UTC] No.45296761{4}[source]▶
https://mastodon.social/@pid_eins/113404099228886304

You auth the initrd too

replies(1): >>45297153 #
70. jshier ◴[19 Sep 25 01:03 UTC] No.45296827{7}[source]▶
Apple's SSDs are all encrypted at the controller nowadays. No need to rewrite, just reformat and it cycles the key, leaving any recoverable data irrevocably encrypted (until we break modern encryption).
replies(1): >>45298200 #
71. lossolo ◴[19 Sep 25 01:04 UTC] No.45296839[source]▶
Finally, MacOS version of Linux dropbear + LUKS. I waited for this.
72. astafrig ◴[19 Sep 25 01:05 UTC] No.45296847[source]▶
Not always on networking; any WiFi passwords are on the data volume too.
replies(1): >>45297359 #
73. cjensen ◴[19 Sep 25 01:07 UTC] No.45296864[source]▶
>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.

replies(4): >>45296982 #>>45297056 #>>45297387 #>>45297876 #
74. lilyball ◴[19 Sep 25 01:23 UTC] No.45296948[source]▶
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.

replies(1): >>45297024 #
75. lilyball ◴[19 Sep 25 01:27 UTC] No.45296978[source]▶
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.
76. odo1242 ◴[19 Sep 25 01:27 UTC] No.45296981[source]▶
They also seem to have added the ability to use external displays on the login screen while FileVault is enabled, which is pretty useful.
replies(1): >>45299596 #
77. ◴[19 Sep 25 01:28 UTC] No.45296982[source]▶
78. ◴[19 Sep 25 01:29 UTC] No.45296989[source]▶
79. Cu3PO42 ◴[19 Sep 25 01:34 UTC] No.45297024{3}[source]▶
Depending on the timeouts involved, I imagined it might still happen if you had automatic retry.

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.

80. mjg59 ◴[19 Sep 25 01:38 UTC] No.45297056[source]▶
"Someone" here is Apple - this is the Apple manpage for a Tahoe feature
81. TheTaytay ◴[19 Sep 25 01:50 UTC] No.45297133[source]▶
Ive been curious about using some Macs for general purpose servers. Is there anything else you do to make them easier to administrate as servers? Are you running Mac-specific stuff on them or more general purpose Linux containerized stuff?
replies(2): >>45297957 #>>45299480 #
82. conradev ◴[19 Sep 25 01:53 UTC] No.45297153{5}[source]▶
This is super cool, thanks for the link! I’m glad they were able to leverage the TPM
83. floam ◴[19 Sep 25 02:04 UTC] No.45297212[source]▶
That sounds like a perfect use case for the wait4path utility that’s shipped with the OS for decades
84. adastra22 ◴[19 Sep 25 02:25 UTC] No.45297329{5}[source]▶
I can confirm that old recovery keys are added to the iCloud Keychain, even if you explicitly opted out of iCloud recovery before. This is exactly what happened to me when I upgraded my systems to macOS 26 yesterday.

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.

replies(1): >>45297661 #
85. adastra22 ◴[19 Sep 25 02:27 UTC] No.45297339{5}[source]▶
> my default assumption is it's still possible to not escrow recovery keys

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.

86. adastra22 ◴[19 Sep 25 02:29 UTC] No.45297351{5}[source]▶
> If someone has compromised your iCloud account and/or device, you have bigger things to worry about

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.

87. BHSPitMonkey ◴[19 Sep 25 02:30 UTC] No.45297354{6}[source]▶
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).

replies(1): >>45297610 #
88. unloader6118 ◴[19 Sep 25 02:31 UTC] No.45297359{3}[source]▶
Some WiFi password and Bluetooth keyboard pairing are in nvram.
replies(1): >>45298669 #
89. oefrha ◴[19 Sep 25 02:34 UTC] No.45297369[source]▶
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.
90. unloader6118 ◴[19 Sep 25 02:37 UTC] No.45297387[source]▶
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.
replies(1): >>45297509 #
91. dishsoap ◴[19 Sep 25 03:01 UTC] No.45297509{3}[source]▶
In the past it used to work the way the parent comment is describing. The confusion is understandable. Apple basically got rid of macos and replaced most of it with things from ios in 2020, a lot changed.
replies(1): >>45303332 #
92. anyfoo ◴[19 Sep 25 03:18 UTC] No.45297607{7}[source]▶
No, the scenario was power outage at an unknown time in the future, not immediate reboot.
93. anyfoo ◴[19 Sep 25 03:18 UTC] No.45297610{7}[source]▶
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?
replies(1): >>45299241 #
94. anyfoo ◴[19 Sep 25 03:20 UTC] No.45297622{5}[source]▶
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.
replies(2): >>45297804 #>>45299265 #
95. pseudalopex ◴[19 Sep 25 03:27 UTC] No.45297661{6}[source]▶
Was iCloud Keychain enabled before you upgraded? Or was it forced on?
replies(1): >>45297711 #
96. adastra22 ◴[19 Sep 25 03:37 UTC] No.45297711{7}[source]▶
I use iCloud keychain as my password manager, just for other things.
97. johncolanduoni ◴[19 Sep 25 03:59 UTC] No.45297804{6}[source]▶
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).
replies(1): >>45298916 #
98. wpm ◴[19 Sep 25 04:14 UTC] No.45297876[source]▶
Only true for Intel Macs
99. wpm ◴[19 Sep 25 04:16 UTC] No.45297890{6}[source]▶
I mean, if you regularly deal with data worth the effort necessary to recover, that isn’t crazy at all
replies(1): >>45328661 #
100. wpm ◴[19 Sep 25 04:18 UTC] No.45297902{3}[source]▶
One network will get stored on NVRAM, I think it’s probably whatever the first one you connect to is.
101. mrtesthah ◴[19 Sep 25 04:30 UTC] No.45297957{3}[source]▶
Macs make terrible servers. I’ve had to manage various on-premises Mac servers for the last 15-20 years and every year Apple breaks something extremely basic and obvious with no reasonable workaround. Especially these days with locking down all the administrative functions such that only a local admin user (with a SecureToken!) clicking a button in the GUI with a physically attached mouse/keyboard can enable them.
replies(2): >>45299574 #>>45305434 #
102. nunez ◴[19 Sep 25 04:31 UTC] No.45297967[source]▶
Huge news for kick-starting Mac minis in a rack and remote lockout troubleshooting!
103. sandreas ◴[19 Sep 25 04:47 UTC] No.45298041[source]▶
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.
104. tonymet ◴[19 Sep 25 04:58 UTC] No.45298105[source]▶
could this be used more generally for secrets & creds? i would like to improve the security of api keys and stuff
105. patrakov ◴[19 Sep 25 05:02 UTC] No.45298122{6}[source]▶
It makes sense temporarily. You can always move the key to your pocket later if nobody steals it.
replies(1): >>45298907 #
106. burnerthrow008 ◴[19 Sep 25 05:18 UTC] No.45298200{8}[source]▶
I thought all SSDs did that for wear-leveling purposes.
replies(1): >>45310433 #
107. reader9274 ◴[19 Sep 25 05:48 UTC] No.45298327[source]▶
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!

replies(3): >>45300726 #>>45302048 #>>45308439 #
108. Halan ◴[19 Sep 25 06:11 UTC] No.45298440[source]▶
I have a Mac mini that I deemed unfit for home lab due to the lack of this feature. This changes everything
109. jiveturkey ◴[19 Sep 25 06:54 UTC] No.45298669{4}[source]▶
not exactly.

https://eclecticlight.co/2024/07/30/nvram-in-apple-silicon-m...

110. alerighi ◴[19 Sep 25 07:24 UTC] No.45298862[source]▶
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.
111. anyfoo ◴[19 Sep 25 07:31 UTC] No.45298907{7}[source]▶
Oh yeah, I get it. Just pointing out what this is doing, and why you should probably not always do this, for example.
112. anyfoo ◴[19 Sep 25 07:33 UTC] No.45298916{7}[source]▶
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.
113. drusklo ◴[19 Sep 25 07:47 UTC] No.45298996[source]▶
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.
replies(8): >>45299024 #>>45299109 #>>45299128 #>>45299320 #>>45299496 #>>45299586 #>>45299754 #>>45300974 #
114. dbdr ◴[19 Sep 25 07:51 UTC] No.45299024{3}[source]▶
Have you considered https://asahilinux.org/ ?
replies(2): >>45299061 #>>45299542 #
115. happymellon ◴[19 Sep 25 07:55 UTC] No.45299061{4}[source]▶
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?

replies(1): >>45299312 #
116. mvanbaak ◴[19 Sep 25 08:01 UTC] No.45299109{3}[source]▶
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
replies(1): >>45299266 #
117. auguzanellato ◴[19 Sep 25 08:03 UTC] No.45299124{4}[source]▶
My Raspberry Pi some time ago had a setup where only public key auth was enabled for LUKS unlock, so I only had to have an authorized_keys file unencrypted.
118. fredsted ◴[19 Sep 25 08:03 UTC] No.45299128{3}[source]▶
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.
119. avianlyric ◴[19 Sep 25 08:17 UTC] No.45299241{8}[source]▶
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
replies(1): >>45310889 #
120. avianlyric ◴[19 Sep 25 08:20 UTC] No.45299265{6}[source]▶
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.

replies(1): >>45310884 #
121. rendx ◴[19 Sep 25 08:20 UTC] No.45299266{4}[source]▶
I use linux SMB targets for Time Machine and PhotoSync and it works just fine. There's also icloudpd, but it requires ADP off.
122. rendx ◴[19 Sep 25 08:28 UTC] No.45299312{5}[source]▶
Time Machine does not require Mac. You can point it to e.g. a SMB share as destination as well.
123. drexlspivey ◴[19 Sep 25 08:30 UTC] No.45299320{3}[source]▶
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
124. amelius ◴[19 Sep 25 08:55 UTC] No.45299462[source]▶
Until Apple triggers something that needs user input, such as an AppleID prompt. Then it's back to the data center ...
replies(2): >>45300581 #>>45300646 #
125. amelius ◴[19 Sep 25 08:57 UTC] No.45299480{3}[source]▶
It's generally a bad idea to use consumer hardware for servers.
replies(3): >>45299525 #>>45299545 #>>45303920 #
126. rollcat ◴[19 Sep 25 09:00 UTC] No.45299496{3}[source]▶
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.
127. rollcat ◴[19 Sep 25 09:05 UTC] No.45299525{4}[source]▶
One reason Google was a big hit was because (while all the competition was doubling down on big iron), they ran their search on commodity hardware, and compensated in software/networking.

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.

replies(1): >>45299558 #
128. rollcat ◴[19 Sep 25 09:07 UTC] No.45299542{4}[source]▶
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.
129. leakycap ◴[19 Sep 25 09:08 UTC] No.45299545{4}[source]▶
Yes, and it's wise not to apply general advice to niche situations: like using a Mac mini for a web host.

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.

replies(1): >>45304890 #
130. amelius ◴[19 Sep 25 09:10 UTC] No.45299558{5}[source]▶
Google used x86 Linux machines. Which is common in industry. Everything is documented, unlike Apple's offerings.
replies(1): >>45300016 #
131. leakycap ◴[19 Sep 25 09:11 UTC] No.45299574{4}[source]▶
I'd rather know how a mac server is to run today than how it was over the last 15-20 years. Seems things are getting better now, especially with this ssh news.

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.

replies(2): >>45303813 #>>45304036 #
132. egorfine ◴[19 Sep 25 09:13 UTC] No.45299586{3}[source]▶
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.

133. egorfine ◴[19 Sep 25 09:15 UTC] No.45299592[source]▶
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.
134. leakycap ◴[19 Sep 25 09:15 UTC] No.45299596[source]▶
Pretty useful is a kind way to put it, but I'm glad they fixed this.
135. leakycap ◴[19 Sep 25 09:19 UTC] No.45299627[source]▶
If this worked as well/seamlessly across updates and hardware revisions as your friendly reminder makes it seem, today's Mac news wouldn't be all over the place getting praise.
136. BatteryMountain ◴[19 Sep 25 09:43 UTC] No.45299754{3}[source]▶
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.

137. rollcat ◴[19 Sep 25 10:28 UTC] No.45300016{6}[source]▶
> Which is common in industry.

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.

replies(2): >>45300503 #>>45303796 #
138. cyberax ◴[19 Sep 25 10:34 UTC] No.45300058{5}[source]▶
I misspoke. I meant a partition that is only protected by the machine-level keys.

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.

139. cyberax ◴[19 Sep 25 10:35 UTC] No.45300066{4}[source]▶
> I have my private keys in Secure Enclave.

Really? Secure Enclave supports only one asymmetric algorithm. With only some limited usages.

replies(1): >>45300900 #
140. amelius ◴[19 Sep 25 11:46 UTC] No.45300503{7}[source]▶
The setup was common in universities, back then. That's probably also how they got to use it.

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.

replies(1): >>45302275 #
141. naikrovek ◴[19 Sep 25 11:56 UTC] No.45300581{3}[source]▶
maybe. but until then...
142. SXX ◴[19 Sep 25 12:00 UTC] No.45300622[source]▶
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.

143. SXX ◴[19 Sep 25 12:04 UTC] No.45300646{3}[source]▶
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.

replies(1): >>45301982 #
144. SXX ◴[19 Sep 25 12:09 UTC] No.45300701{3}[source]▶
autossh + sshpass. Work perfectly.
145. SXX ◴[19 Sep 25 12:11 UTC] No.45300726{3}[source]▶
One question for you or anyone who tried it. SSH host (mac) key pre disk unlock is randomly generated and persistent?
replies(1): >>45300955 #
146. ubermonkey ◴[19 Sep 25 12:28 UTC] No.45300893[source]▶
Oh, this is nice indeed.
147. SXX ◴[19 Sep 25 12:28 UTC] No.45300900{5}[source]▶
As far as I aware you can't actually do 100% of crypto needed for SSH auth inside the SEP itself. Might be I missed something, but I tried to find a way before and there was none. This would obviously be most secure.

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.

replies(1): >>45304325 #
148. lxgr ◴[19 Sep 25 12:35 UTC] No.45300955{4}[source]▶
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.

replies(1): >>45301073 #
149. lxgr ◴[19 Sep 25 12:37 UTC] No.45300974{3}[source]▶
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.

150. lxgr ◴[19 Sep 25 12:39 UTC] No.45300986[source]▶
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?
151. SXX ◴[19 Sep 25 12:40 UTC] No.45301003[source]▶
> Unavailability of FileVault-mounted home directories when not logged in has been the case since Tiger.

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.

152. shawnz ◴[19 Sep 25 12:41 UTC] No.45301008{3}[source]▶
Would Wireguard function in this pre-unlock environment?
153. SXX ◴[19 Sep 25 12:47 UTC] No.45301073{5}[source]▶

  > 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.
replies(1): >>45301126 #
154. lxgr ◴[19 Sep 25 12:52 UTC] No.45301126{6}[source]▶
Wow, TIL about HostKeyAlias and CheckHostIP. Especially the latter sounds super useful when it comes to frequently changing private IPs. Thank you!
155. watusername ◴[19 Sep 25 13:55 UTC] No.45301721[source]▶
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.
replies(1): >>45315550 #
156. crest ◴[19 Sep 25 14:15 UTC] No.45301916[source]▶
Now that's a nice quality of life feature if it's implemented correctly!
157. amelius ◴[19 Sep 25 14:20 UTC] No.45301982{4}[source]▶
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.
158. nazarewk ◴[19 Sep 25 14:27 UTC] No.45302048{3}[source]▶
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.

replies(1): >>45324534 #
159. oarsinsync ◴[19 Sep 25 14:48 UTC] No.45302275{8}[source]▶
> The setup was common in universities, back then. That's probably also how they got to use it.

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.

replies(1): >>45302536 #
160. amelius ◴[19 Sep 25 15:12 UTC] No.45302536{9}[source]▶
Except Apple has tight control. You're basically building your castle in Apple's kingdom.

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.

replies(1): >>45308615 #
161. dcrazy ◴[19 Sep 25 16:13 UTC] No.45303332{4}[source]▶
Your comment is overbroad as written, but it is close to true about the boot chain. The Apple Platform Security Guide [1] says: “When a Mac with Apple silicon is turned on, it performs a boot process much like that of iPhone and iPad.”

[1]: https://support.apple.com/guide/security/boot-process-secac7...

162. trollbridge ◴[19 Sep 25 16:51 UTC] No.45303796{7}[source]▶
PHP was written in C. To quote Rasmus Lerdorf:

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

replies(1): >>45308626 #
163. trollbridge ◴[19 Sep 25 16:52 UTC] No.45303813{5}[source]▶
It’s a lot harder than it used to be. You basically need to ensure you have a remote KVM, or else have access to smart hands every few months to press a button.
replies(1): >>45310192 #
164. snovymgodym ◴[19 Sep 25 17:02 UTC] No.45303920{4}[source]▶
And yet, running clusters of Mac Minis is one of the most common datacenter solutions for when you need MacOS (usually for CI systems that run iOS builds or something similar).
replies(1): >>45304049 #
165. mrtesthah ◴[19 Sep 25 17:12 UTC] No.45304036{5}[source]▶
the point is that the “security” changes apple has been making are not broadly beneficial to the server use case and seem designed for single-user systems with no consideration for remote management/access.

This is the same reason why Apple has lost the education market to Chromebooks.

166. mrtesthah ◴[19 Sep 25 17:13 UTC] No.45304049{5}[source]▶
If you want iOS build servers Apple’s licensing gives them no other option.
167. cyberax ◴[19 Sep 25 17:37 UTC] No.45304325{6}[source]▶
You can generate and store your private SSH key in the secure enclave, there's even an SSH agent that does that for you: https://github.com/maxgoedjen/secretive

But that's it.

Anything more complicated is not possible. You can't even upload your existing key into the SE.

replies(1): >>45305080 #
168. comprambler ◴[19 Sep 25 18:33 UTC] No.45304890{5}[source]▶
Your data integrity is at risk not using ECC ram (EXTRA ESPECIALLY IF YOU USE SOFTWARE RAID), which is usually gated out of consumer hardware.

Though those poweredges would have had it.

replies(1): >>45320670 #
169. SXX ◴[19 Sep 25 18:51 UTC] No.45305080{7}[source]▶
AFAIK "secretive" SSH agent is not actually running inside SEP when it using the keys. So when keys are actively used they are exposed in main OS RAM and only protected by macOS security model (so are safe unless there is jailbreak / actual root exploit).

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.

replies(1): >>45320826 #
170. MangoToupe ◴[19 Sep 25 19:28 UTC] No.45305434{4}[source]▶
Why not just install linux on them? Macs don't require macos. Hardware ≠ software.
171. varenc ◴[19 Sep 25 20:16 UTC] No.45306037{4}[source]▶
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.

172. kylehotchkiss ◴[20 Sep 25 00:22 UTC] No.45308439{3}[source]▶
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

173. kylehotchkiss ◴[20 Sep 25 00:24 UTC] No.45308452[source]▶
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`.
174. rollcat ◴[20 Sep 25 00:44 UTC] No.45308615{10}[source]▶
None of this is the point of this discussion.

The point is: commodity hardware is powerful, and it's interesting to explore its capabilities outside of its original purpose. Apple or not.

replies(1): >>45313091 #
175. rollcat ◴[20 Sep 25 00:46 UTC] No.45308626{8}[source]▶
Thanks for debunking, I'll stop spreading lies now ^^;
176. leakycap ◴[20 Sep 25 03:53 UTC] No.45310192{6}[source]▶
I don't agree that it is harder than it used to be, unless you specifically mean there are a few more dialogs to hop through during install and initial setup which is annoying on recent versions. But you do this once, just like Windows UAP.

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

177. johncolanduoni ◴[20 Sep 25 04:38 UTC] No.45310433{9}[source]▶
They do, but consumer ones usually don't implement the additional API (TCG Opal) that lets you lock/unlock the hardware encryption key. Without that capability you can't use it to implement full-disk encryption. They do usually implement the NVMe secure erase feature though, which will rotate it.
178. anyfoo ◴[20 Sep 25 06:12 UTC] No.45310884{7}[source]▶
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.

179. anyfoo ◴[20 Sep 25 06:13 UTC] No.45310889{9}[source]▶
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?
180. Dylan16807 ◴[20 Sep 25 08:02 UTC] No.45311400[source]▶
If you want it to automatically unlock via TPM then you turn filevault off. This is protection on top of that.
181. amelius ◴[20 Sep 25 13:12 UTC] No.45313091{11}[source]▶
If you ignore legal constraints, maybe.
182. nozzlegear ◴[20 Sep 25 17:50 UTC] No.45315550{3}[source]▶
Oh I didn't know that, interesting to learn in hindsight. Thanks!
183. leakycap ◴[21 Sep 25 07:00 UTC] No.45320670{6}[source]▶
Unless you're sending the Mac mini to space as part of this project, the internal hardware ECC built in to Apple silicon SoC combined with the extremely short unified memory paths removes this as a valid concern

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.

184. cyberax ◴[21 Sep 25 07:35 UTC] No.45320826{8}[source]▶
Ah, I see that Secretive is a victim of feature creep. I think it still can use the SE to store the private key, but it also has more ways to do it.

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.

replies(1): >>45336435 #
185. reader9274 ◴[21 Sep 25 17:01 UTC] No.45324534{4}[source]▶
Ah, I use Remote Management because I also do screen sharing on this mac mini from time to time
186. adastra22 ◴[22 Sep 25 02:51 UTC] No.45328661{7}[source]▶
On a modern SSD it is cargo culting though. Every write is assigned to a new sector.

Makes sense when wiping the whole drive though.

187. SXX ◴[22 Sep 25 17:10 UTC] No.45336435{9}[source]▶
Again - I could be really wrong about Secretive. Sadly their documentation dont make it very clear and I myself don't have enough time to actually to go read the code and figure out how it works exactly.
188. port11 ◴[26 Sep 25 19:19 UTC] No.45390034[source]▶
As someone staying away from Tahoe for as long as possible, it's a shame this wasn't backported.