Passphrase encrypted rsa or ed25519 default keys complicates the usability

[johnalotoski]

On a system where a user has a default passphrase protected rsa and/or ed25519 key, agenix throws errors, even if the identity is explicitly declared as an alternate key,:

# Specify a cwd non-passphrase protected ed25519 key:

❯ agenix -vvv -i ./id_ed25519 test-encrypted/test.age
DEBUG checking '/home/$USER' for .agenix.toml config
DEBUG found config at '/home/$USER/.agenix.toml'
TRACE validate_config? false
TRACE rekey? false
TRACE path.is_none()? false
TRACE got valid ssh identity 'ssh-ed25519 <snip> testkey'
DEBUG using ["./id_ed25519", "/home/$USER/.ssh/id_rsa"] as identity file(s)
Error: 
   0: Failed to decrypt file 'test-encrypted/test.age'
   1: Failed to get usable identity or identities
   2: /home/$USER/.ssh/id_rsa: EncryptedPem

Location:
   src/cli.rs:703

Now, let's remove the offending passphrase protected key which it is choking on to make it work:

❯ mv ~/.ssh/id_rsa ~/.ssh/id_rsa-tmp-rename
❯ agenix -vvv -i ./id_ed25519 test-encrypted/test.age
DEBUG checking '/home/$USER' for .agenix.toml config
DEBUG found config at '/home/$USER/.agenix.toml'
TRACE validate_config? false
TRACE rekey? false
TRACE path.is_none()? false
TRACE got valid ssh identity 'ssh-ed25519 <snip> testkey'
DEBUG using ["./id_ed25519"] as identity file(s)
TRACE rekey? false
TRACE encrypt_in_place? false
DEBUG editor: 'vim'
DEBUG args: 'None'
WARN  contents unchanged, not saving

The upstream age reference shows that if the default user rsa and ed25519 keys it checks are passphrase protected, it will prompt if needed, or silently ignore any passphrase errors.

Here it is blocking instead. It seems it would be better to adopt the upstream behavior so users aren't forced to move their default keys if password protected?

[cole-h]

I don't currently have time to investigate this issue, but your approach definitely sounds reasonable. I'd gladly accept a PR fixing this! (And sorry for the delay in getting back to you.)

[johnalotoski]

Thanks. I'm swamped also, unfortunately, so I probably won't be able to contribute a PR any time soon.