Secrets not accessible with correct permissions, only via root

[dr460nf1r3]

Hey!

I'm currently having a very weird issue which causes some secrets to be impossible to read for my user. Particularly, I'm using sops-nix to provide my SSH private key. This used to work perfectly fine until some time ago, now I frequently can't authenticate with it due to being inaccessible.

The solution has been to delete the symlink, copy the key from /run/secrets/ via sudo and then chowning it to my user.

The given permissions in both ~/.ssh and /run/secrets/ look just fine, so I'm not sure what is going on here:

 nico@dragons in repo: dr460nixed on  main [$!+] via  v18.17.1 as 🧙 took 7ms                                                                                                      
❌1 ❯ ls -l ~/.ssh                                                                                                                                                                                                                                                                                                    
lrwxrwxrwx   28 nico 26 Aug 19:41 id_rsa -> /run/secrets/ssh_keys/id_rsa                                                                                                             

 nico@dragons in repo: dr460nixed on  main [$!+] via  v18.17.1 as 🧙 took 5ms
❯ cat ~/.ssh/id_rsa
[bat error]: '/home/nico/.ssh/id_rsa': Permission denied (os error 13)

 nico@dragons in repo: dr460nixed on  main [$!+] via  v18.17.1 as 🧙 took 6ms
❌1 ❯ sudo ls -l /run/secrets/ssh_keys        
total 4
-rw------- 1 nico users 2602 26. Aug 19:41 id_rsa

Another example:

 nico@dragons in ~/.config/syncthing took 3ms
❯ ls -l
lrwxrwxrwx 41 nico 26 Aug 18:28 cert.pem -> /run/secrets/syncthing/dragons-ryzen_cert
lrwxrwxrwx 40 nico 26 Aug 19:54 key.pem -> /run/secrets/syncthing/dragons-ryzen_key

 nico@dragons in ~/.config/syncthing took 4ms
❯ sudo ls -l /run/secrets/syncthing
total 8
-rw------- 1 nico syncthing 794 26. Aug 19:54 dragons-ryzen_cert
-rw------- 1 nico syncthing 288 26. Aug 19:54 dragons-ryzen_key

 nico@dragons in ~/.config/syncthing as 🧙 took 436ms
❯ cat cert.pem 
[bat error]: 'cert.pem': Permission denied (os error 13)

The expression I use to provide the secret:

  sops.secrets."ssh_keys/id_rsa" = {
    mode = "0600";
    owner = config.users.users.nico.name;
    path = "/home/nico/.ssh/id_rsa";
  };

And the full flake, in case it helps. Thanks!

[Mic92]

Does it work if you don't nest the secret?

{
  sops.secrets."ssh_keys-id_rsa" = {
    mode = "0600";
    owner = config.users.users.nico.name;
    path = "/home/nico/.ssh/id_rsa";
  };
}

sudo ls -la /run/secrets.d/1/ssh_keys-id_rsa

vs the old permission:

sudo ls -la /run/secrets.d/1/ssh_keys

[dr460nf1r3]

Did it not nested via:

    "ssh_keys_id_rsa" = {
      mode = "0600";
      owner = config.users.users.nico.name;
      path = "/home/nico/.ssh/id_rsa";
    };

The path was a little different (3 instead of 1):

❌2 ❯ sudo ls -la /run/secrets.d/3/
-rw------- 1 nico users 2602 27. Aug 12:27 ssh_keys_id_rsa

So basically the same permissions as before:

❌1 ❯ sudo ls -l /run/secrets/ssh_keys
total 4 -rw------- 1 nico users 2602 26. Aug 19:41 id_rsa

This yields the same result btw, files are inaccessible.

[colemickens]

I feel like this is probably the same thing I was reporting here in https://github.com/Mic92/sops-nix/issues/381 ?

[bertbesser]

Could it be the ownership/perms of your /home/nico/.ssh folder?

I'm also managing SSH keys with sops-nix. My issue today was that /home/user/.ssh is owned by root and home-manager could not generate the config file into it. I solved it with a NixOS system activation script that makes me instead of root own the folder.

Does sops-nix allow to change ownership/perms of the chain of parent folders of a secret? I'm guessing no. Would a sensible default be "same as secret"?

Cheers.

[dr460nf1r3]

Yeah, that's the case and exactly what the issue referenced above reported as well. I didn't know about the activation script method, that's something worth trying to workaround this one in the meantime! :)