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

SSH keys storage #278

Closed
logut opened this issue Feb 9, 2017 · 45 comments

Comments

Projects
None yet
@logut
Copy link

commented Feb 9, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 9, 2017

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.

@phoerious phoerious added this to the v2.2.0 milestone Feb 10, 2017

@rockihack

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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 😉

@rockihack

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

@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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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 comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

@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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Feb 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 19, 2017

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

This comment has been minimized.

Copy link

commented Mar 15, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 15, 2017

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

This comment has been minimized.

Copy link

commented Mar 20, 2017

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.

image

@droidmonkey droidmonkey modified the milestones: v2.3.0, v2.2.0 May 7, 2017

@droidmonkey droidmonkey added the wishlist label May 7, 2017

@CRCinAU

This comment has been minimized.

Copy link

commented Jul 3, 2017

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.

@phoerious phoerious referenced this issue Jul 10, 2017

Merged

Add Yubikey 2FA for unlocking databases #127

8 of 8 tasks complete
@sstent

This comment has been minimized.

Copy link

commented Jul 28, 2017

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

@jeroen7s

This comment has been minimized.

Copy link

commented Jul 28, 2017

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

This comment has been minimized.

Copy link

commented Aug 3, 2017

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

@hifi

This comment has been minimized.

Copy link
Member

commented Oct 4, 2017

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

This comment has been minimized.

Copy link

commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 6, 2017

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

This comment has been minimized.

Copy link

commented Oct 6, 2017

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

@hifi

This comment has been minimized.

Copy link
Member

commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 12, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 14, 2017

@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

This comment has been minimized.

Copy link
Member

commented Oct 15, 2017

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 hifi referenced this issue Oct 21, 2017

Merged

SSH agent client support (KeeAgent compatible) #1098

19 of 19 tasks complete
@hifi

This comment has been minimized.

Copy link
Member

commented Oct 28, 2017

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

@hifi

This comment has been minimized.

Copy link
Member

commented Nov 19, 2017

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

@TheZ3ro TheZ3ro closed this Nov 19, 2017

@jD91mZM2

This comment has been minimized.

Copy link

commented Nov 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 24, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.