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

Limit automatic loading of keys to specific hosts the database is opened on #215

Closed
hifi opened this issue Mar 14, 2018 · 6 comments
Closed

Comments

@hifi
Copy link

hifi commented Mar 14, 2018

We had a feature request (keepassxreboot/keepassxc#1721) for KeePassXC where a user wants to limit automatic adding of keys to specific systems rather than loading all keys that have the automatic setting enabled.

This would likely require changes to KeeAgent.settings so it would be the best if such feature would be implemented it would be coordinated with KeeAgent.

What do you guys think?

EDIT: Just to clarify, this is about the local system the database is opened on, sorry for the possible confusion.

@dlech
Copy link
Owner

dlech commented Mar 14, 2018

It sounds like a rather complex feature that won't be used by most people.

@hifi
Copy link
Author

hifi commented Mar 18, 2018

It could possibly help with issue #139 if some of the keys are only needed on specific systems.

@BWibo
Copy link

BWibo commented Mar 19, 2018

I would love to see this feature!

I use SSH with several different hosts as I have to access several different servers on a regular basis. As MaxAuthTries is usually configured to a conservative number on the host side (<< than the number of SSH keys I have on my agent) I fail to connect because of "Too many auth failures".
As a workaround, I currently copy all public keys to my ~/.ssh folder and add s.th. similar to this for every host in ~/.ssh/config:

Host my.example.host.de
  IdentityFile /c/users/theuser/.ssh/my.example.host.de.pub
  IdentitiesOnly yes

This requries some handwork for every new host or everytime SSH keys change.
Moreover, this solution is unhandy to transport accross client systems. You may have to redo the configuration for all clients you are using (DesktopPC at home/work, Laptop, ...).

Maybe an easy solution would be to make KeeAgent create a ~/.ssh/config file with entries for all hosts and exporting public keys.

Having this implemented within KeeAgent would be a great improvement for me!
I assume, I am not the only one having this kind of SSH usage scenario?
Thx in advance!! :-)

@hifi
Copy link
Author

hifi commented Mar 19, 2018

I think you misunderstood the feature, we can't automatically load keys to agent per remote host as that's not possible with the SSH Agent. This feature request was to select which keys are automatically loaded to agent based on the local host.

For your scenario somehow managing remote host mapping and exporting a ~/.ssh/config is probably the way to go. OpenSSH client supports Include directives so it could be a common location on non-Windows machines to automatically export and update such mapping. On Windows it wouldn't work I suppose.

What KeeAgent and compatible implementations could do is manage the list in KeeAgent.settings that such export file could be spun from but there's information leakage from the database that way (public keys and hosts that they "work" with) so that needs to be considered.

@hifi hifi changed the title Limit automatic loading of keys to specific hosts Limit automatic loading of keys to specific hosts the database is opened on Mar 19, 2018
@BWibo
Copy link

BWibo commented Mar 19, 2018

Your right, I had a missunderstanding here. That's what happens when you stop reading anything of the content but the headline. -_-
I'll move this to another feature request, as this might acually bother more people.

@hifi
Copy link
Author

hifi commented Jan 30, 2022

Closed in favor of #296.

@hifi hifi closed this as completed Jan 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants