Add support for Age SSH

[iamd3vil]

Currently sops only supports age with age keys. This PR adds support for using SSH keys for encryption, decryption using age.

Usage

Encryption

./sops --ssh /home/user/.ssh/id_ed25519.pub -e -i secrets.yaml

--ssh flag here denotes the ssh keys for encrypting.

Decryption

./sops -d enc.json

If there is no SOPS_AGE_SSH_PRIVATE_KEY env variable given, sops will check ~/.ssh/id_ed25519 and fallbacks to ~/.ssh/id_rsa.

Let me know if I need to do any changes.

P.S: I have updated to the latest version as well.

[itscaro]

Any news on this PR?

[hikhvar]

This fixes #692 and would allow a really streamlined process combined with gitops tools like argocd or flux.

[hiddeco]

GitOps tool maintainer here (Flux). Thanks a lot for this contribution, I have no doubt this will be extremely useful to quite some users. 🥇

I have assigned this to myself to review, but am waiting for #1064 to land first as I have a gut feeling it would be better to merge the two key source into one than to introduce an additional one. For this, I need a clear view on the state of develop post-merge in combination with this PR. Please hold for a tiny bit longer 🙇

[saimonn]

@hiddeco #1064 is now merged, is there some way we could help to merge this current PR as well ?

[hiddeco]

Sorry for the wait folks, this has been on my to-do list for some time but #1072 and #1085 had a bit more priority.

Based on a quick study of the current key source implementation in develop and age itself, I am wondering if the current age.X25519Recipient in this implementation could be replaced with a more generic age.Recipient. We could then load decryption keys (identities) from all known files (either X25519 or SSH), and re-use most logic already there with some minor changes to deal with different receiver string types. WDYT?

[Sebor]

Hello @hiddeco!
Any news about the review?

[neongreen]

Would also love to have this. Perhaps there is somebody else who can pick up the review?

[neongreen]

Or should it be closed in favor of #1134? @hiddeco

[hiddeco]

While I really do appreciate your work here @iamd3vil, I am going to close this in favor of #1134 which incorporates the feedback I gave in #898 (comment). Thank you very much nonetheless! 🙇