[yjftsjthsd-h]

Okay, I'll bite. What are you calling a dark pattern in assorted agents? Especially given that dark pattern implies intent to harm. (And I say this as someone looking at using an agent: If there's a gotcha, I'd like to know about it)

[inetknght]

1) SSH agent will cache your passphrase. While that's the whole purpose of SSH agent, remember that nothing is more insecure than an unlocked secret.

2) SSH agent often starts automatically, frequently without user interaction (even if you specify `-i keyfile`). SSH client and DBus are both culprits here; there's also other culprits too.

3) There are often multiple different agents installed on Linux desktop systems. For example, ssh-agent, gnome-keyring, seahorse, gpg-agent ... the list goes on. Good luck auditing that.

4) Without `-i keyfile`, SSH will present to the remote server all keys, in sequence, cached in your agent (and will cause trouble with active firewalls from too many authentication attempts)

5) If the keyfile you specified in `-i keyfile` does not authenticate, then SSH will fall-back to using keys cached in your agent. That's especially frustrating since you might want to know that the key you specified was rejected!

6) Removing the executable flag from ssh-agent is not a permanent solution: updates will often overwrite the program with a new file and reset the executable bit. Obviously the same goes for renaming the program (that one causes a hell of a lot more noise in logs btw; programs seem to complain more if a program can't be found instead of just not being executable)

7) See also (related) concerns I posted about GPG agent on Stack Overflow [1]

Last, but not least: 8) Hope you don't use a system where agent forwarding or agent caching is turned on in the system settings!

[1] https://stackoverflow.com/q/47273922/1111557

[naniwaduni]

> 1) SSH agent will cache your passphrase. While that's the whole purpose of SSH agent, remember that nothing is more insecure than an unlocked secret.

There's one thing more insecure than an unlocked secret: a "secret" sitting in plain text on the filesystem.

Which is a common outcome if you advise people against using an agent and they don't share your opsec priorities.

[tialaramex]

For (4) and (5) set IdentitiesOnly as well as Identity (IdentityFile or IdentityAgent). This tells SSH that you've specified the exact identity you want used, not just a hint at an identity that might help.

Note that having "trouble with active firewalls" is a sign that the security posture is garbage, those aren't "authentication attempts" the SSH protocol explicitly has a step where the client proposes authentication keys it's interested in trying WITHOUT authenticating, counting each such key as an "attempt" is like counting up how many keys a person has in their pockets and arresting them for attempted burglary if they have more than ten different keys.

[inetknght]

That's an interesting perspective. Nonetheless, if you load up your agent with a dozen keys and try to log in to a remote server, it will deny you after (typically) three keys being presented. That will show up in the logs as a failed login attempt. Something such as fail2ban will then spot failed login attempts and take action.

Edit: +1 about IdentitesOnly and Identity. I use that in my ssh_config, particularly when I need to alias one name to another.

[tialaramex]

By default OpenSSH _logs_ after three keys but it only gives up (if you don't have a fail2ban script blowing everything up) after six keys. And you can reconfigure the server as appropriate, unlike whatever this "active firewall" (which by the sound of things may just be a fail2ban script) does.

This is a bad fail2ban script, it's inconveniencing real users rather than targeting the bots you care about since they are doing password guessing anyway.

[andrewshadura]

Seahorse is not an agent.

[inetknght]

https://linux.die.net/man/1/seahorse-daemon

Seahorse is a GNOME application for managing encryption keys. This is the daemon program which provides services to other parts of Seahorse, and shares your keys over the network if so desired.

It doesn't have agent in its name but it sure sounds like the behavior of a key agent.

[giggles_giggles]

If you use ssh-agent with default settings it's very easy to accidentally expose access to systems you would not expect via the agent.

This seems to be a good post about the problem: https://heipei.io/2015/02/26/SSH-Agent-Forwarding-considered...

The key takeaway is that using ssh -A with default settings allows root on the system you've connected to "to impersonate you to any host as long as you’re connected".

[yjftsjthsd-h]

Ah, okay; so it's not the agent that's the problem, but the agent with forwarding. That is a fair point, and probably needs saner defaults or messaging. That said, since I don't use forwarding that should be fine for me.

[deathanatos]

Agent forwarding defaults to off, AFAIK. You have to ask for it specifically by either requesting it at the CLI with -A, or adding it to .ssh/config.

It would be nice if people understood the consequences of it, and I do find in my conversations with developers that people generally do not understand that by forwarding the agent, anyone with sufficient access on the remote can use the agent. (E.g., another user w/ sudo.)

[tialaramex]

It would be nice if GUI desktop environments that already have miscellaneous notification APIs would give you a transient notification when the agent gets a request. That's a low impact change (you can just ignore it) that highlights to users what's actually going on. It improves security passively by giving users awareness.

Your agent _should_ always be where you are (ie not inside a container, a bastion host, or whatever else) because otherwise that means you aren't actually in possession of the key material and there's plenty of opportunity for much _worse_ surprises than with SSH agents if somebody else has the key material.

Because it's where you are, and you're probably not on a 1970s video terminal link but a laptop or something, the agent could just ask you to OK each request out of band, e.g. popping up a "Really log into machine X?" request. Once such a mechanism existed it could be refined (should it let you say "Yes always to requests from machine X" ? How about "Yes always for the next five minutes" ?) and if necessary SSH auth could even be tweaked to better support any real world behaviours that are popular (e.g. I don't recall off the top of my head if the agent can tell from what it's signing either where you're signing in, or where that sign-in was used, but the binding mechanism in SSH auth could certainly enforce either of those if they're determined to be important and don't exist today)

[inetknght]

It's not just giving you a transient notification with the agent gets a request. I'd go several steps further:

1) clearly display what "local" machine is making the connection, under what user

2) clearly display what remote machine is the local connecting, to what user

3) allow me to select a specific key for that connection pair, and only present one key to the remote

4) if the key is unlocked (or, gasp not passphrase-protected), then allow me to accept/deny the agent request

5) give me some mechanism to permanently disable the agent for my user if I decide I don't want to risk some software "accidentally" forwarding an agent (pebcak, bug, malice, whatever)

[schoen]

And probably it should have been described as an antipattern rather than a dark pattern.

[inetknght]

I think you're correct, that would be a better description. Unfortunately I think it's too late to edit my original comment: the edit link doesn't show up for me.

[bifrost]

I'll vote yes for this one :)

[bifrost]

Yep! Or worse if you're in a VM/Container...