Most active commenters
  • anyfoo(8)

←back to thread

Apple: SSH and FileVault

(keith.github.io)
507 points ingve | 21 comments | | HN request time: 0s | source | bottom
Show context
reader9274 ◴[] 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 #
1. varenc ◴[] 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 #
2. eastbound ◴[] No.45295374[source]
But then you could just disable FileVault?
replies(2): >>45295885 #>>45296333 #
3. derefr ◴[] No.45295885[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 #
4. kkylin ◴[] No.45296130{3}[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.
5. anyfoo ◴[] No.45296150{3}[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 #
6. johncolanduoni ◴[] No.45296333[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 #
7. firecall ◴[] No.45296504[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 #
8. derefr ◴[] No.45296758{4}[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 #
9. BHSPitMonkey ◴[] No.45297354{4}[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 #
10. anyfoo ◴[] No.45297607{5}[source]
No, the scenario was power outage at an unknown time in the future, not immediate reboot.
11. anyfoo ◴[] No.45297610{5}[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 #
12. anyfoo ◴[] No.45297622{3}[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 #
13. johncolanduoni ◴[] No.45297804{4}[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 #
14. patrakov ◴[] No.45298122{4}[source]
It makes sense temporarily. You can always move the key to your pocket later if nobody steals it.
replies(1): >>45298907 #
15. anyfoo ◴[] No.45298907{5}[source]
Oh yeah, I get it. Just pointing out what this is doing, and why you should probably not always do this, for example.
16. anyfoo ◴[] No.45298916{5}[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.
17. avianlyric ◴[] No.45299241{6}[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 #
18. avianlyric ◴[] No.45299265{4}[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 #
19. varenc ◴[] No.45306037[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.

20. anyfoo ◴[] No.45310884{5}[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.

21. anyfoo ◴[] No.45310889{7}[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?