Keepassxc: SSH keys storage

[logut]

It would be cool if keepassxc could store ssh keys and provide them trough ssh-agent or pagent something like what http://lechnology.com/software/keeagent/ is doing.
What do you think about it ?

[droidmonkey]

I agree with this idea, although I have no idea where to start since I am not familiar with how ssh-agent or pageant actually does what it does. There is also a security implication in this that should be handled similar to the HTTP plugin. Only a registered/authorized accesser should be allowed to pull the keys.

[rockihack]

I strongly disagree. Why do you want to store private keys in your password manager?
Do you want only one password for everything? Then why do you use a password manager in the first place?
A common use-case is to share your password database between multiple computers, but you do not want to share your private keys do you?

[nelsongraca]

Because I have several keys, and I use them on around 3 different computers, having them in a database that I can sync is useful.

[GuilloOme]

Like @nelsongraca, I also have several keys for different access type for different environment (prod vs dev) and this on multiple devices… So I disagree about the fact that we "should not share" private key between device. IMO, the private key serve the same purpose as a password (ie. authenticating you on an asset).
Centralizing private keys in a password manager will help managing this kind of credentials nightmare which lead to the usual "one key for all access". If we step back a bit, it will appear that is exactly the same concern that push us to use a password manager in the first place (ie. avoiding the "one password for all authentications")

@rockihack, as any other feature, if you don't feel this is secure enough for you to use it in your context, you should avoid using it. As always with security, every one have to do there own risk assessment. In my case (and probably for any person working in a place with proper identity and access management), it will be a more secure way to manage private keys.

[TheZ3ro]

You can already store SSH Key in KeePassXC: open the ~/.ssh/id_rsa file (or your SSH file) and copy all the content in a entry's custom attribute.

Here we are discussing adding an ssh-agent to provide those keys directly from KeePassXC.
IMHO it doesn't have much utility since you can save them and import them in your System's default agent.

---

Also, if your key starts with:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED

or
-----BEGIN ENCRYPTED PRIVATE KEY-----
or
-----BEGIN OPENSSH PRIVATE KEY-----

Your key is already password protected and there isn't much need to transport it inside KeePassXC :wink:

[rockihack]

@GuilloOme Yes, everyone have to do their own risk assessment.
But I disagree that someone should share private keys between multiple devices. Thats not the proper way. A private key should never leave it's origin where it was generated (besides taking backups).

[phoerious]

I think the use case is more to sync your SSH keys across multiple machines and then use KeePassXC directly as an ssh-agent implementation rather than copying the keys from KeePassXC to your .ssh directory first. Whether you want that or not is debatable, but it's definitely a use case I can see.
Another one would be to simply have one place to unlock things and not 10 (KeePassXC, ssh-agent, gpg-agent, KWallet, ...), even if you don't sync your password file to other PCs.

[GuilloOme]

Thank @phoerious you synthesize it right.
The main concern is the effort of manipulating several keys (with several passphrase) will eventually push the user to avoid using multiple keys where it should be mandatory to use one per access type/environment…

Unlocking all your ssh key with one passphrase is definitely a plus that will push people to use different key for each access.

In my case, I have a .db with only my private keys (which I have to open with KeePass+KeeAgent) and I use KeePassXC for my passwords… which is quite annoying.

[TheZ3ro]

I don't know how KeeAgent works but if you have encrypted ssh key (they are encrypted by default since OpenSSH 6,5 if I remember correctly) you need to:
-Unlock your Password DB with the KeePass master-password
-Decrypt the key with the key's password

So you don't use only 1 password.

Also I don't understand why would you transport an already encrypted private key in a "Password Manager". This is only usefull with unencrypted key and adding an agent only for this seems useless to me.

[phoerious]

An ssh-agent implementation takes care of decrypting the private key automatically. That's in fact the only reason ssh-agent exists. You decrypt once and then the decrypted key is kept in memory until either you tell it to forget the key or shut down the machine. I haven't used KeeAgent yet, but I'm certain it will do exactly that. It's not necessary that the key file itself is inside your password safe, but at least your key phrase is.

I think, having KeePassXC instead of using the default ssh-agent, can even be beneficial in terms of security. By default, ssh-agent unlocks keys indefinitely and it's really up to specific implementations to set a timeout. In KeePassXC, you can easily configure a reliable timeout after which an SSH key and all your other passwords will be locked away again. Maybe it's even possible to integrate it with keychain, but I'm not sure.

[TheZ3ro]

I don't know how much a third-party implementation is more secure then OpenSSH's ssh-agent.

So you store both the key and the key's password in KeePassXC database that will decrypt the key when needs to be used. This is not very secure and makes useless having an encrypted key in the first place.

[GuilloOme]

@TheZ3ro I totally agree with you about the matter of implementing a new "ssh-agent", it could be way worst but could it be possible to use the system one by calling it from KeePassXC?

Having the key and passphrase at the same place will be as secure as your .kdbx passphrase and .kdbx encryption is. IMO, it's the same problem as storing your username alongside with your password, it should not be done but it's more secure this way (a password manager give you the ability to not knowing your password but need to know your complete credentials).

If we compare, what is the worst:

• storing keys and passphrases at the same place but incite the user to use multiple key and locking it when not in use
• unlock the only one key the user have (because it's a pain to do it for every key you would need) and keep it unlock based on system timeout (disable by default on ubuntu)

[TheZ3ro]

You have an encrypted database kdbx on your pc and the master-password in your mind.

You put the .kdbx and your plain-text password together in your Dropbox folder.
It's secure, you have 2FA and the Dropbox login.
This is actually pretty unsecure. If someone stole your dropbox, he have both your kdbx and the password to access it.
So you shouldn't write down passwords and you should never keep password and kdbx together.

Now, why would I put the encrypted key and the password that decrypt it in the same kdbx file? If someone get access to your kdbx file he has both the key and the password.

Storing the key along side the encrypted material is like don't encrypt at all.

I think a better and more secure option should be:
Leave the key were it is. KeePassXC unlocks ssh-agent by providing the password.

[phoerious]

That's not the use case. The use case is to have an encrypted SSH key (whether it's inside a KDBX file or not doesn't matter at this point) and KeePassXC to decrypt it.

[nelsongraca]

With Keepass+KeeAgent it has the option to either run its own agent or use a running agent on the system, I personally have the system agent running and the KeeAgent one can load the keys into it, I don't know the specifics of implementation, it is also possible with KeeAgent to have it ask if I want to allow access to a key that comes from it, in other words the keys are not blindly used, you can enable a constraint to validate if you really want to allow it.

[TheZ3ro]

I personally have the system agent running and the KeeAgent one can load the keys into it

This sounds good to me. You don't need to store ssh-keys into KeePass, am I right?

Storing keys in KeePassXC along with password instead is a bad idea.

---

@phoerious the first message explicitly says (citing)

It would be cool if keepassxc could store ssh keys

The use case is this.

[phoerious]

This how KWallet integrates with ssh-agent: you set the SSH_ASKPASS environment variable to point to /usr/bin/ksshaskpass. When you add an SSH key to your ssh-agent using ssh-add, it uses /usr/bin/ksshaskpass to provide the passphrase for unlocking the key (which is stored in KWallet) and then adds the unlocked key to the ssh-agent.
I think, KeePassXC could do something similar, but should probably also take care of removing the key from ssh-agent when the database

If KeePassXC should also store the key itself is another question.

[GuilloOme]

@TheZ3ro says:

Leave the key where it is. KeePassXC unlocks ssh-agent by providing the password.

I think the first focus is on security AND usability. If the concern about storing encrypted key inside the db is too important to comfort the security aspect, I'll let go the usability ease by managing manually my key files to keep the "auto-unlock" features!

Thinking about using a linux implementation of ssh-agent: will it make the ssh-agent feature "linux only"?
(Actually, I have no idea if/how ssh-agent works on other platform)

[phoerious]

Storing the key inside KeePassXC is exactly as secure as storing it outside of KeePassXC encrypted with a passphrase. Of course, it's not more more secure to have an encrypted SSH key + plain text password inside your KDBX than it is to have an unencrypted key inside your KDBX, but you also wouldn't encrypt your already encrypted SSH key + its passphrase again when you are using only OpenSSH.

However, what you _would_ do is to configure a decent amount of rounds for the key derivation function. Both OpenSSH and KeePassXC allow you to you do that, but perhaps KeePassXC makes it a little easier and more accessible.

Whether you store your key inside a KDBX or not, the overall security is the same in both cases. Whether you sync the KDBX to other PCs is a totally different question. But of course, you could also put your encrypted id_rsa file into your Dropbox.

[TheZ3ro]

Storing the key inside KeePassXC is exactly as secure as storing it outside of KeePassXC encrypted with a passphrase.

I don't really agree. If I Sync my kdbx over the internet I don't want to place inside it both my private encrypted key and the password.
If I can just put my password is fine. The key will stay on my PC and nobody will have access to it.
(this is what I'm saying since I started replying)

[phoerious]

As I said: the security is exactly the same. But if you place your KDBX in a cloud folder, you have to compare it with placing your encrypted id_rsa file in a cloud folder. Otherwise you compare apples and oranges.
Nobody says you have to sync your KDBX file and nobody says you can't have a separate KDBX file which only contains SSH keys and isn't synced anywhere.

I myself do put my KDBX in a cloud folder (self-hosted Nextcloud), but I have encrypted it with a long passphrase and a key file which remains on my local machine and is not synced together with the password vault. I therefore still have two factors (and with the coming YubiKey support it would even be three) for decrypting anything.

[TheZ3ro]

I'm comparing 2 different behavior: one is secure and the other is not.
Like writing passwords on paper, instead using a PasswordManager.
It's the same reason as nobody sane would stores his PGP private key together with its plaintext password.
You instead are going out of context. The issue is about storing SSH keys in a KDBX to be provided to ssh-agent. How using 2 KDBX can solve the problem? This will only complicate the provide mechanism to ssh-agent (one KDBX provides the key and the other decrypt it?)

Leave the key where it is. KeePassXC unlocks ssh-agent by providing the password.

---

Anyway If someone want to actually develop this, I won't stop anyone. You are welcome.
But we can't implement every plugin ever made for KeePass. There are other things to do that have higher priority and things that users actually use.

[phoerious]

I'm comparing 2 different behavior: one is secure and the other is not.

Not, it's not. Storing your SSH key inside your KeePassXC vault isn't any less secure than storing it in encrypted form outside KeePassXC. It is exactly the same. There is no difference whatsoever.

[jsha]

If I can chime in my 2c: I agree that KeePassXC could match the security of ssh-agent. But why choose to do that when ssh-agent already exists? It seems like a significant amount of code, with its own security considerations to worry about, to do a job that is already done well by other software.

[phoerious]

I think the gist of this discussion here is that we won't duplicate the efforts of ssh-agent, but rather provide an ASKPASS implementation which can be used by ssh-agent.

[eternaltyro]

Can we push this to Milestone v2.3.0 instead of v2.2.0? This might involve a lot of discussion and would hold up v2.2.0.

[phoerious]

We will decide that once we have our clear roadmap for 2.2.0 and can see if we will manage to implement this in time or not. Right now there are lots of other features which are not finished or completely missing.

[KalleDK]

The one thing I really like KeeAgent for is the abbility to have the program popup to grant access each time a program tries to use a key. This also works with agent forwarding.

If ssh-agent and pageant had this, I would not need KeeAgent.

[CRCinAU]

I second (ok, 25th?) the idea that being able to throw SSH keys in the DB would be awesome.

Right now, I have scattered identity files everywhere among multiple machines - it would be great to put them all in one place.

[sstent]

The lack of this feature is really the only thing stopping me from migrating off Keepass2 now.

[jeroen7s]

Right now, I have scattered identity files everywhere among multiple machines - it would be great to put them all in one place.

that completely destroys the purpose of private keys, they are used to identify individual devices, if you're using the same private key on multiple devices you're doing it wrong.
it would be wasted resources to implement this, not to mention maintain it and keep it bug-free, when ssh-agent already exists.
i'm definitely in favor of this approach:

we won't duplicate the efforts of ssh-agent, but rather provide an ASKPASS implementation which can be used by ssh-agent.

[mfulz]

Is there any way to help implementing the ASKPASS feature? This is really something I'd love to have.

[hifi]

There doesn't seem to be a way to force OpenSSH into using SSH_ASKPASS when you execute ssh or ssh-agent directly within a terminal and it will default to using stdin to get the passphrase.

It unfortunately makes the askpass feature rather useless for most users who would like to use it to login to interactive sessions.

[mfulz]

Hm not sure I understand you correct, but for me everything is working fine with SSH_ASKPASS set to: /usr/bin/ksshaskpass
It's doing the same thing like I would like to have with keepass: Asking for password (even working when the PW is for the keyfile) and storing it into the kwallet.
For my ssh-agent, I'm using ssh-add for the keyfiles in my .zshrc and when the kwallet is open and the pw stored it's loding fine.
I just would like to have one store (which is my keepass file) instead of using kwallet for the ssh pws

[hifi]

I wrote a proof-of-concept ssh agent that works with KeePassHTTP. Please, do not use it as-is because it's very insecure as it stands. I really like this approach over supplying a passphrase as then the key follows my database.

https://github.com/hifi/keepassxc-agent
http://hifi.iki.fi/keepassxc-agent-demo.ogv

@mfulz ssh-add when run inside a terminal prompts for the passphrase there and never calls the askpass executable, at least for me

[mfulz]

Do you have SSH_ASKPASS variable set?
For me ssh-add is calling it fine from there.

[hifi]

Yes, I do, my env has SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass and I can call it manually just fine. Only in some rare circumstances it's actually being used.

Your env may not have DISPLAY set? If it's missing then SSH_ASKPASS is always used.

[hifi]

Correction to what I said earlier straight from the man page of ssh:

     SSH_ASKPASS           If ssh needs a passphrase, it will read the passphrase from
                           the current terminal if it was run from a terminal.  If ssh
                           does not have a terminal associated with it but DISPLAY and
                           SSH_ASKPASS are set, it will execute the program specified
                           by SSH_ASKPASS and open an X11 window to read the
                           passphrase.  This is particularly useful when calling ssh
                           from a .xsession or related script.  (Note that on some
                           machines it may be necessary to redirect the input from
                           /dev/null to make this work.)

My point is, it does not work reliably for everyone and it can end up asking for the passphrase in terminal which defeats the purpose.

[phoerious]

I've had such problems a lot and usually solved them by wrapper scripts. Ubuntu, on the other hand, seems to have managed to provide the user reliably with a GUI input, even when triggered from the console. Might be worth investigating how they did it or if they patched ssh-agent.

[hifi]

@phoerious I installed Ubuntu 16.04 LTS in a VM and looks like what you are seeing is GNOME Keyring acting as a ssh-agent which will automatically try loading your default key on-demand when the ssh client is requesting keys.

https://wiki.gnome.org/Projects/GnomeKeyring/Ssh

The most compatible mode of operation would be to act as a client to any existing ssh-agent and add/remove keys when the database is unlocked/locked. Most reasonable Linux desktops seem to have some sort of agent running by default and on Windows it can be done by acting as a client to Pageant.

What do you guys think?

[hifi]

I tested a bunch of popular distributions (and what I had in hand) in their default install and here are the results:

• Ubuntu has GNOME Keyring (Unity)
• Kubuntu has ssh-agent (KDE Plasma)
• Mint has GNOME Keyring (Cinnamon)
• Fedora has GNOME Keyring (GNOME)
• Debian has ssh-agent (Xfce)
• CentOS has GNOME Keyring (GNOME) [in KDE install it has ssh-agent]
• Lubuntu has ssh-agent (LXDE)
• Xubuntu has GNOME Keyring (Xfce) [ssh-agent is also running but trumped by the keyring]
• ElementaryOS has ssh-agent (Pantheon)
• openSUSE Leap does not have an agent running by default (KDE Plasma)
• Antegros has GNOME Keyring (GNOME)
• Manjaro has ssh-agent (Xfce)

Bonus: MacOS (OS X El Capitan) has a keyring daemon running that provides ssh-agent functionality

In conclusion: with one exception, all tested distributions and even the Mac had an agent running in default install with SSH_AUTH_SOCK environment variable having a working socket for ssh-add to work with.

Edit: added Lubuntu, Xubuntu, ElementaryOS and openSUSE Leap
Edit2: added Antegros and Manjaro

[hifi]

PR #1098 is now feature complete and implements a client for ssh-agent or Pageant. Feel free to test it.

[hifi]

Initial agent support has been merged. Please create new issues for enhancements that can be tracked separately.

[jD91mZM2]

Very sorry for notifying literally all of you, but I need to ask

Storing keys in KeePassXC along with password instead is a bad idea.

Why? I'm not saying it's a good idea, but, I mean, if somebody has cracked your vault you're already screwed...? Just asking because I'm currently doing this (it's my way of backing up my SSH Key. Although bad... it works for now) and got a little worried 😛

[hifi]

@jD91mZM2 It comes down to personal preference. Technically if you keep your keys external you have "more" security as then if someone steals your database and is somehow able to unlock it they can't access your SSH keys (although I would argue there's a bigger issue than SSH keys at that point) but only their passphrases.

Regardless which your preference is, the upcoming 2.3.0 feature will support both so you can make the choice yourself.