←back to thread

Apple: SSH and FileVault

(keith.github.io)
507 points ingve | 9 comments | 18 Sep 25 20:15 UTC | HN request time: 0.001s | source | bottom
Show context
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 #
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 #
eastbound ◴[18 Sep 25 21:42 UTC] No.45295374[source]▶
But then you could just disable FileVault?
replies(2): >>45295885 #>>45296333 #
derefr ◴[18 Sep 25 22:38 UTC] No.45295885{3}[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 #
1. anyfoo ◴[18 Sep 25 23:13 UTC] No.45296150{4}[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 #
2. derefr ◴[19 Sep 25 00:50 UTC] No.45296758[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 #
3. BHSPitMonkey ◴[19 Sep 25 02:30 UTC] No.45297354[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 #
4. anyfoo ◴[19 Sep 25 03:18 UTC] No.45297607[source]▶
No, the scenario was power outage at an unknown time in the future, not immediate reboot.
5. anyfoo ◴[19 Sep 25 03:18 UTC] No.45297610[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 #
6. patrakov ◴[19 Sep 25 05:02 UTC] No.45298122[source]▶
It makes sense temporarily. You can always move the key to your pocket later if nobody steals it.
replies(1): >>45298907 #
7. anyfoo ◴[19 Sep 25 07:31 UTC] No.45298907[source]▶
Oh yeah, I get it. Just pointing out what this is doing, and why you should probably not always do this, for example.
8. avianlyric ◴[19 Sep 25 08:17 UTC] No.45299241{3}[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 #
9. anyfoo ◴[20 Sep 25 06:13 UTC] No.45310889{4}[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?