need to hard code user key paths

[gabysbrain]

I have a few keys which are only encrypted with my user ssh keys to keep them consistent across systems. On a nixos-rebuild switch I was getting an error:

decrypting /nix/store/ddsxinl7ixlmfhlay848zy8qg916f1ks-google-vdirsyncer.age to /run/secrets/google-vdirsyncer...
Error: No matching keys found

[ Did rage not do what you expected? Could an error be more useful? ]
[ Tell us: https://str4d.xyz/rage/report                            ]
chmod: cannot access '/run/secrets/google-vdirsyncer.tmp': No such file or directory
chown: cannot access '/run/secrets/google-vdirsyncer.tmp': No such file or directory
mv: cannot stat '/run/secrets/google-vdirsyncer.tmp': No such file or directory

I traced this down to the fact that age,sshKeyPaths defaults to only the system rsa and ed25519 keys but does not try and look in user directories. Is this intentional? If so, I can update the documentation to reflect this but otherwise this will need some changes to the nixos module.

Thanks for an awesome package! This has made things so much easier!

[ryantm]

@gabysbrain Are you saying you were expecting it to look into all the user's ~/.ssh directories for decryption keys by default? Currently it only looks in /etc/ssh.

I hadn't really thought about considering the home directories, because in my use case the home directories rarely have private SSH keys. Seems like maybe it would be fine to check there, but I hope some other people can help me think through the security implications.

[gabysbrain]

Yes, that's what I'd like.

The reason this would help is I have a few secrets that I encrypt for my local user so it would be easier to just encrypt it with my personal host key rather than updating the key every time I add or remove a system from my nix deployment. It's not a huge deal right now. I just override the secrets files in the config but it would be nice, since you can encrypt keys with your personal ssh key, that it would automatically decode them as well.

But you're right, I'm not sure of the security implications either.

[asymmetric]

I tried thinking of possible security drawbacks, but none came to mind.

Still, it could be a good idea to keep this behaviour off by default, behind a config flag.

[gabysbrain]

#58 basically does what I'm requesting here. I would suggest to close this as duplicate

[ryantm]

Thinking about this again, I think I see at least one security problem:

Alice and Mallory share a machine configured by Bob. Mallory has Alice's encrypted secret for her other unrelated machine which she publishes in her public GitHub repo. Mallory convinces Bob to incorporate the encrypted secret into the machine's configuration, then when Bob deploys, the activation script reads Alice's home directory private key and decrypts the secret for Mallory.

Though this security problem isn't too common these days as few people share machines in this way. Alice should not put her private key on a machine shared with people she doesn't trust.