dlech / KeeAgent

ssh agent plugin for KeePass 2.x
http://lechnology.com/software/keeagent
Other
530 stars 35 forks source link

Allow ordering of keys #301

Open zoredache opened 4 years ago

zoredache commented 4 years ago

I have generated and I want to start using a new keypair, I also have a couple old keys that I want to keep available for systems I haven't updated yet, but only use them as needed

I want to be able to have my new key set to allow connections without out any constraints or confirmations, and my old keys ask for me to confirm their usage.

I want the zoredache-20200616 to be loaded and used first.

I know if I set zoredache-20200616 to only load at startup, and then manually add zoredache-20180109 keeagent seems works the way I want it to work, so mostly I just am l just wondering if there is a way to control the order keys are automatically loaded and added to the agent. Or if a method could be added.

tlynchpin commented 4 years ago

doc on how keys are ordered currently would be helpful.

my use case is KeeAgent with a bunch of keys and servers that have a low MaxAuthTries: the server errors on MaxAuthTries before KeeAgent gets to the correct key. If I knew how to affect key order then I could avoid this problem for most of the servers I work with by placing their keys first in KeeAgent order and placing keys for servers with larger MaxAuthTries last.

zoredache commented 4 years ago

@tlynchpin I was able to figure out a way to control order I made a set of folders in keepass named 1,2,3,9, and put the key I wanted first in 1, second in 2, third in 3, and everything else in 9. That seemed to allow me to control the order. So I am guessing there is a sort somewhere.

Still it would be nice if the docs were more explicit or there was some obvious controls somewhere.

tlynchpin commented 4 years ago

Keys are ordered in the natural order of the entries. Use 'Rearrange' to change the location of entries that have keys, this changes the order of the keys in KeeAgent.

KuttKatrea commented 4 years ago

You can also use the .ssh/config file to set the key that should be used for each host, using the public key

Host host-on-aws
  Hostname ec2-x-x-x-x.us-east-x.compute.amazonaws.com
  User ec2-user
  IdentityFile ~/.ssh/identities/host-on-aws.pub

You can even use multiple IdentityFile entries to select various keys in order

T81 commented 1 year ago

+1

Offerel commented 1 year ago

Keys are ordered in the natural order of the entries. Use 'Rearrange' to change the location of entries that have keys, this changes the order of the keys in KeeAgent.

Where do i find this 'Rearrange'?

ykis-0-0 commented 9 months ago

Sorry to necro, but this is indeed a much desired feature.

In case where 6 or more keypairs loaded in KeeAgent, PubkeyAuthentication will often fail, making ssh fallback to Password auth.

When in usages where non-interactive ssh is used, this causes the ssh process to fail (with a non-obvious "Too many authentication failures"), or even get stuck midway asking password.

Therefore a method to specifiy the priority of which keypair to try first will greatly improve the ease of use

KuttKatrea commented 9 months ago

Therefore a method to specifiy the priority of which keypair to try first will greatly improve the ease of use

There are already two ways to do this:

1. Ordering keys in KeePass

Loaded keys will be ordered in the natural order on Keepass (respecting group and key order). Keys inside a group can be reordered using the Rearrange context menu option: image

Ensure the list of entries is not sorted by any field to see the entries in natural order:

Sorted by title: image

Click in the Title header, to sort again by title but in descending order: image

Click again to remove the sort order: (Notice no arrow on any header) image

2. Ordering keys in SSH config

First, export the PUBLIC keys to files in your computer, for example, in C:\Users\your-user\identities\ Create a file named config on C:\Users\your-user\.ssh

For each host you connect to, add the following content:

Host host-to-connect.com
IdentityFile ~/.ssh/identities/public-key-to-use.pub

When you run ssh host-to-connect.com ssh will try first the ~/.ssh/identities/public-key-to-use.pub key from the agent.

Reference: https://linux.die.net/man/5/ssh_config

ykis-0-0 commented 9 months ago

For putting public keys to ~/.ssh, manpage ssh_config(5) states that:

IdentityFile Specifies a file from which the user's RSA or DSA authentication identity is read. The default is \~/.ssh/identity for protocol version 1, and \~/.ssh/id_rsa and \~/.ssh/id_dsa for protocol version 2. Additionally, any identities represented by the authentication agent will be used for authentication.

which seems to me is a private key. And cross-referencing ssh(1):

-i identity_file Selects a file from which the identity (private key) for RSA or DSA authentication is read. The default is \~/.ssh/identity for protocol version 1, and \~/.ssh/id_rsa and \~/.ssh/id_dsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files).

Therefore, from the manpage text, I don't suppose the IdentityFile directive will work for public keys.

Last (and least), some personal opinion I personally don't think KeeAgent as a plugin is "good" to dedicate the ordering for entries for its functionality. And unnecessarily leave keys (albeit only the public part) in the filesystem doesn't sound good to me. But both of these is only a personal opinion.
KuttKatrea commented 9 months ago

Therefore, from the manpage text, I don't suppose the IdentityFile directive will work for public keys.

It works as long as you have the corresponding privake key loaded into the agent (KeeAgent in this case). Once the agent is not running (locked database?), ssh will fail because of the file being of "incorrect format".

And unnecessarily leave keys (albeit only the public part) in the filesystem doesn't sound good to me.

Security-wise, it should not be a risk. But yeah, it just doesn't feel right. I would have prefered having some ssh_config option to specify the fingerprint of the key. But right now is some historical functionality from SSH.