Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ordering of keys #301

Open
zoredache opened this issue Jun 18, 2020 · 10 comments
Open

Allow ordering of keys #301

zoredache opened this issue Jun 18, 2020 · 10 comments

Comments

@zoredache
Copy link

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.

  • zoredache-20180109, set with confirm constraint
  • zoredache-20200616

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
Copy link

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
Copy link
Author

zoredache commented Aug 6, 2020

@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
Copy link

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
Copy link
Contributor

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
Copy link

T81 commented Apr 21, 2023

+1

@Offerel
Copy link

Offerel commented Apr 25, 2023

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants