[XMPPwocky]

SSH agent forwarding makes your ssh-agent available to (possibly some subset of) hosts you SSH into. This is its purpose. Unfortunately, it also makes your ssh-agent available to (possibly some subset of) hosts you SSH into.

[aidos]

I never quite understand why there’s not a confirm version. ForwardWithConfirmation or something. I’m active when I need forwarding - would be happy to simply be prompted before it’s allowed.

[DblPlusUngood]

OpenSSH does have confirmation: use the '-c' switch to ssh-add.

https://man.openbsd.org/ssh-add

[aquabeagle]

Or "AddKeysToAgent confirm" in ~/.ssh/config

[aidos]

Waaaaaaat?! That could definitely be better known.

[Arathorn]

TIL :|

[acct1771]

Hang in, there.

[felipelemos]

This could be a sane default.

[e12e]

Hm, anything similar for gpg agent (both for gpg, and as a stand-in for ssh-agent)?

Ed: looks like I need to edit my sshcontrol-file

https://www.gnupg.org/documentation/manuals/gnupg/Agent-Conf...

[Leace]

If you use Yubikey with touch-to-use enabled that'll be basically what you're asking - each authentication will require touching the token.

[haasted]

I just enabled that after seeing this incident.

For people in the same boat, it can be done trivially using the YubiKey Manager CLI: https://developers.yubico.com/yubikey-manager/

[rwmj]

Some ssh agent implementations do this, notably the one built into Android ConnectBot can be configured to request confirmation each time it is asked to authenticate. Unfortunately ssh-agent (from OpenSSH) does not as far as I know. It's happy to authenticate as many times as requested without any notification.

[DBFFD990]

It can, and it's determined per key when added to the agent.

Look for -c here: https://man.openbsd.org/ssh-add

[rwmj]

Indeed it is - I even checked the man page before posting the comment and completely missed that option.

[scanr]

Is there a secure alternative that achieves the same outcome?

[metafunctor]

Here are a few ideas that might help.

Use separate keyboard-interactive 2FA (I recommend google-authenticator) for production ssh access.

Use a key system which requires confirmation or a PIN to authenticate (such as a Yubikey). Use a persisting ssh connection with Ansible (ControlPersist) to avoid unnecessary multiple authentications.

Allow connections only from whitelisted IPs, or Uuse port knocking to open temporary holes in your firewall, or require connections to production infrastructure to go through a VPN.

Access production infrastructure from hardware dedicated for that purpose, never do anything else on it.

I wish there was a way in ssh to tag connections and only allow agent forwarding to keys with the same tag. That would prevent agent forwarding production keys from a dev host.

[pas]

https://github.com/StanfordSNR/guardian-agent

[XMPPwocky]

I'm not sure. A secure, backwards-compatible (with older servers) alternative, which only exposes keys you explicitly choose to expose, should be doable and might help.

another option would be for a SSH client to present a full-screen "$HOST is trying to use your your SSH PRIVATE keys. Press enter, then type "~A" to allow." prompt.

[RL_Quine]

`ProxyJump`

[aidos]

Hadn’t seem that before. Article here explains is briefly https://www.madboa.com/blog/2017/11/02/ssh-proxyjump/

[theamk]

This article is .. weird. It mentions SOCKS5, DynamicForwarding and "decent version of nc", while you don't need anything at all for forwarding connection -- SOCKS is not involved in any way, and initial 1995 release of nc would work just fine.

Here is a much better explanation (from [0]):

> ProxyJump was added in OpenSSH 7.3 but is nothing more than a shorthand for using ProxyCommand, as in: "ProxyCommand ssh proxy-host -W %h:%p"

so the same thing that top poster was talking about.

[0] https://superuser.com/questions/1253960/replace-proxyjump-in...

[metafunctor]

Do you keep your keys on the proxy host, then? Otherwise, "ForwardAgent yes" and you're back to the same situation.

[syntonym]

ProxyJump uses the keys from the original host, not the proxy host.

[metafunctor]

I know. That's why I asked. Chained agent forwarding will serve your keys just the same, so ProxyJump is not "a secure alternative that achieves the same outcome".

[syntonym]

Are you disagreeing with the "secure alternative" or the "same outcome"? I thought the difference between ProxyJump and agent forwarding is the following:

Agent forwarding forwards the agent socket to the proxy server. Thus any ssh connection originating from the proxy server can reuse the agent, and with that has the same access to the agent as the originating host.

ProxyJump routes the ssh connection through the proxy host. The crypto takes place between originating host and target host, not between proxy host and target host. ssh connections originating from the proxy host can not access keys from the originating host.

But maybe my understanding of ProxyJump is incorrect?

[pas]

https://github.com/StanfordSNR/guardian-agent

[brunoqc]

That project looks dead.