maxgoedjen / secretive

Store SSH keys in the Secure Enclave
MIT License
6.99k stars 155 forks source link

Unprotected private key file after macOS upgrade #443

Open anthropic-eli opened 1 year ago

anthropic-eli commented 1 year ago

Encountered an odd blip when trying to SSH after macOS upgrade.

macOS version 13.2 (22D49) I got the following message when trying to SSH.

 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 Permissions 0644 for '/Users/eli/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/b617805090865fee9ccba1aa613e6d42.pub' are too open.
 It is required that your private key files are NOT accessible by others.
 This private key will be ignored.
 Load key "/Users/eli/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/b617805090865fee9ccba1aa613e6d42.pub": bad permissions
 git@github.com: Permission denied (publickey).
 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.

It worked just fine when I tried again, though.

maxgoedjen commented 1 year ago

@anthropic-eli yeah, I've seen this occasionally. I think macOS might be touching those permissions during upgrade or something? Secretive will flush/recreate those public key files though periodically.

Just in case anyone is following along and seeing that scary message: it's a red herring, your private key is never on disk at all, just macOS incorrectly freaking out over pubkey permissions.

bblacey commented 3 months ago

Is there a way to force secretive to flush/recreate the public keys (e.g. delete the PublicKeys directory)?

I'm asking because I encountered this issue last night after a reboot. I checked the permissions and sure enough, they are public read. I have not tried to manually correct them yet because it smells like a bug - perhaps Secretive should ensure the permissions are in the proper state?

% ls -l
total 48
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 48cb345ed9b736bf19c694de7b9d5d15.pub
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 6669b441ee1e7497d45e39aecf421a2f.pub
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 7724b599539f12835e4debba9b109eb3.pub
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 96446bb54900be42119d5e2557a5edc6.pub
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 9e232df478696b71aea859ca018c8118.pub
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 a0a4f2f8f34edcfdeb6851c2b2715653.pub

I also noticed the public key files have quarantine xattrs on them. Is this expected/normal?

% ls -l@
total 48
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 48cb345ed9b736bf19c694de7b9d5d15.pub
    com.apple.provenance     11 
    com.apple.quarantine     26 
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 6669b441ee1e7497d45e39aecf421a2f.pub
    com.apple.provenance     11 
    com.apple.quarantine     26 
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 7724b599539f12835e4debba9b109eb3.pub
    com.apple.provenance     11 
    com.apple.quarantine     26 
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 96446bb54900be42119d5e2557a5edc6.pub
    com.apple.provenance     11 
    com.apple.quarantine     26 
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 9e232df478696b71aea859ca018c8118.pub
    com.apple.provenance     11 
    com.apple.quarantine     26 
-rw-r--r--@ 1 blacey  staff  160 Mar  7 08:01 a0a4f2f8f34edcfdeb6851c2b2715653.pub
    com.apple.provenance     11 
    com.apple.quarantine     26 

Now, from an update standpoint, macOS updated Apple's XProtect yesterday morning so perhaps XProtect is doing something with these files upon boot?

Also, what permissions do you recommend for secretive socket.ssh file?

Secretive has been working flawlessly until this recent glitch. Please advise.

bblacey commented 3 months ago

Update - the permissions on socket.ssh were:

srwxr-xr-x@   1 blacey  staff      0 Mar  7 08:01 socket.ssh

So I changed them to 0700 and Secretive no longer issues the public key warning. So perhaps the socket permissions triggered the red herring and not the public key permissions because mine public key files are still wide open.

So the question is, why were the permissions on socket.ssh incorrect?