should password managers enable ssh-agent modes?

[Bill Evans]

I'm normally a KeePass user, and two of the longest-standing reasons are that (1) it is completely offline, like passsafe; and (2) it mimics ssh-agent (with https://github.com/dlech/KeeAgent). The benefit for me is that I can maintain my intention of "opening my passwords/keys" by unlocking KeePass, and every ssh/scp/rsync call I subsequently make benefits from the agent sock. (It can optionally verify each key or just use them silently, with levels of verbosity in between.) Similarly, by locking my KeePass, I assert I expect no more authentication requests to be filled (e.g., when somebody is remotely troubleshooting my computer, sigh).

Though I believe it is a good use-case (at least for me, possibly for others), what is the concensus on whether this should be made available in a password manager?

The alternative appears to be using the "normal" ssh-agent, whether unix's ssh-agent or PuTTY's pageant (depending on your platform). For this to work, assuming the agent knows when to lock itself (e.g., screen saver, idle timeout), so in order to again use it I need to unlock my pw mgr then get the password to the agent (either copy/paste or more secure clipboard-less alternatives).

A consequence of this (I see it as "negative" but perhaps not) is that all keys need to be stored in the normal filesystem, and are not automatically synced with the password database. To me, I see my private keys as "passwords" as well, so it seems logical and intuitive to keep them secured within my password database ... so losing this is a major detractor in my eyes.

Knowing that security versus convenience is an easy topic point, what are other consequences of (mis-)using a password manager to mimic SSH agents?

(This is not yet a formal request to implement an ssh-agent-mode in pwsafe, more to understand if there are reasons I should consider removing it from my KeePass toolkit.)

[ouzo12]

My take on it is that PuTTY is an excellent ssh/scp/sftp client and the agent that comes
along with it (pageant) is also very good, so I don't feel there's the need to reinvent the wheel.
I can use pageant as the agent while keeping the private key passphrases in the password safe.

[Bill Evans]

In the past, I've used PuTTY a lot, so I know it has value. The fact that I find other tools more compatible/usable at the moment in my instance doesn't undermine the fact that PuTTY and pageant is a good pair of tools.

But that wasn't my question. Do you have any thoughts on the consequences of using a password manager to mimic SSH agents?

[alan]

I think there was a deliberate decision not to include any network connectivity code in passwordsafe as a security measure.
That's also the reason it doesn't check for new versions.

[Bill Evans]

I wasn't aware of that decision, do you have a link? It makes perfect sense to me, though, thank you for the historical context.

To me, there is a clear distinction between using unix-domain sockets (which is what ssh-agent uses) and TCP/IP sockets (which I interpret as the spirit of the aversion to networking code). The two types of sockets are certainly similar in many ways, but I think one can argue that they are different-enough that the "no network" argument is distinct from "no sockets". (That is, permit socket(AF_UNIX, ...).)

Or is it that pwsafe intentionally denies any type of communication channel at all?

So in the context of the original question, mimicking ssh-agent is opening the pw-manager up to having to deal with communicating with something else, where this could introduce an attack vector. That makes some sense.

[Rony Shapiro]

The benefit of protecting ssh access by the same master password and program needs to be balanced against the risk of the increased attack surface created by an open port to a program that manages your passwords.
A mitigation would be to use a "safe" file that only contains your ssh keys, but then you lose the benefit of a single control point.

Bottom line, I'm not comfortable with adding this to PasswordSafe. I think the risks outweigh the benefits.

[Bill Evans]

Rony, that's what I think is the big point. And I cannot disagree with your concern over introducing an attack vector (though for clarity, when you say "open port", you do mean a local unix-domain socket, right?).

Have you heard of any local unix-domain socket attacks through the ssh-agent protocols? (Again, I'm not asking you to implement into pwsafe. I'm asking from an academic point.) It would be a curious attack vector, effectively gaining direct entry to other hosts.

[Rony Shapiro]

I'm unaware of specific attacks on ssh-agent, but where there's a protocol there's a potential misuse of the protocol, that can be potentially exploited.

Also, if we're talking about ssh and accessing remote systems, it's not infeasible for an attacker to drop an AF_UNIX - AF_INET proxy on the target machine, and access ssh-agent via that.

[Bill Evans]

Great points, Rony. Thanks for the discussion!