| ▲ | sugarpimpdorsey 4 days ago |
| 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. |
|
| ▲ | numbsafari 4 days ago | parent | next [-] |
| 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… |
| |
|
| ▲ | dangus 4 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | angulardragon03 4 days ago | parent [-] | | Yeah iirc they have moved some stuff around that sshd relied on into the pre-boot volume, so it works exactly as you describe. |
|
|
| ▲ | cyberax 4 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | _mikz 4 days ago | parent | next [-] | | I have my private keys in Secure Enclave. Why the machine would not have own private keys there? | | |
| ▲ | aaroncarson 4 days ago | parent | next [-] | | 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! | | |
| ▲ | cyberax 4 days ago | parent | next [-] | | 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. | |
| ▲ | davidczech 4 days ago | parent | prev [-] | | They are encrypted with a SEP key when stored in preboot volume. |
| |
| ▲ | cyberax 4 days ago | parent | prev [-] | | > I have my private keys in Secure Enclave. Really? Secure Enclave supports only one asymmetric algorithm. With only some limited usages. | | |
| ▲ | SXX 4 days ago | parent [-] | | 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. | | |
| ▲ | cyberax 3 days ago | parent [-] | | 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. | | |
| ▲ | SXX 3 days ago | parent [-] | | 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. | | |
| ▲ | cyberax 2 days ago | parent [-] | | 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. | | |
| ▲ | SXX 9 hours ago | parent [-] | | 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. |
|
|
|
|
|
| |
| ▲ | Citizen8396 4 days ago | parent | prev [-] | | 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 | | |
|
|
| ▲ | SXX 4 days ago | parent | prev [-] |
| > 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. |
