LWN: Comments on "Restricting SSH agent keys"

Restricting SSH agent keys

misc — Fri, 25 Feb 2022 19:48:53 +0000

Or doing git commit or git clone with a repo served over ssh, on that remote server.

Restricting SSH agent keys

djm — Fri, 21 Jan 2022 23:18:59 +0000

Yes, you should definitely use ProxyJump over agent forwarding if you can. There are some circumstances where that isn't possible or convenient though.

physical ssh keydevices - not an issue?

djm — Fri, 21 Jan 2022 23:17:35 +0000

It's of benefit to FIDO security keys too. ATM for forwarded agents, it's possible for an attacker to "phish" FIDO key touches. E.g. they wait for you to do something that will require a touch and jump in first with their own request. These protocol changes make this more difficult.

physical ssh keydevices - not an issue?

Klavs — Thu, 20 Jan 2022 13:12:56 +0000

This only works at solving the problem which only (as I understood it) is relevant for on-disk private keys.
So for those of us, using ssh-keys via gnupg daemon (backed by a hardware key like yubikey) - this feature is not a security benefit at all?

Restricting SSH agent keys

NYKevin — Sun, 09 Jan 2022 05:07:00 +0000

This is a good example, but I also think that there's an element of pets-vs-cattle here. In the cattle case, you're absolutely right: Ideally, you never SSH into cattle at all. If you need to SSH into something, it's broken and you should probably either redeploy the offending container or just reimage the silly thing, but in practice that's not always the case (You use containers, right? You can safely and easily reimage everything whenever you want, right?).

But the other practical reality is that not everything is going to be cattle in the first place. Some machines (workstations, mostly) are pets, and will always be pets, because each individual machine has slightly different requirements and there's no reasonable way to fully and completely standardize them. For those machines, a certain amount of manual remote administration is inevitable, especially in the brave new world of everyone working from home. Once you realize that this is a real use case, then ProxyJump starts to look a lot less reasonable as (the only) solution. Sometimes, manual multi-hop SSH is just *easier* in the context of everything else you're doing at the time.

Restricting SSH agent keys

tiwe — Sat, 08 Jan 2022 23:58:59 +0000

Some years from now this might make many uses of ssh-agent-filter obsolete.

Restricting SSH agent keys

atnot — Sat, 08 Jan 2022 17:46:44 +0000

One example might be to run programs like ansible that uses ssh to manage a large number of machines at once. Scripts that rsync data between two servers are also not that uncommon in oldschool sysadmining. There's definitely better solutions for those things these days but it'll take a while for everyone to get there.

Restricting SSH agent keys

droundy — Sat, 08 Jan 2022 03:18:56 +0000

One scenario where that wouldn't help is if you want to scp between two remote hosts. I think.

Restricting SSH agent keys

NYKevin — Thu, 06 Jan 2022 18:21:05 +0000

If you need to run a long-lived thing on the bastion, you may have no choice but to SSH into it in order to configure that long-lived thing. At that point, it's largely a matter of convenience.

Another possibility is that there are internal services which are inaccessible from your local host, and you need to SSH to a bastion just to do anything interesting at all. It just so happens that one of the various interesting things you need to do is SSH into other servers. But you also need to be on the bastion to do things like send RPCs, check out (proprietary) source code, etc., because your local host is not trusted enough to do those things itself.

Restricting SSH agent keys

pj — Thu, 06 Jan 2022 15:10:45 +0000

I wonder if the guardian agent project (https://github.com/StanfordSNR/guardian-agent) will take advantage of the agent protocol changes? It's a local agent that pops up a local "did you auth this? Yes/No/AllLikeThis" kind of prompt whenever a remote agent request is forwarded to the local agent. Due to the mentioned agent protocol limitations it currently uses its own encrypted agent channel so it can add that information, but that may not be necessary now.

Restricting SSH agent keys

grawity — Thu, 06 Jan 2022 10:58:22 +0000

The agent protocol has been extended (see session-bind in the PROTOCOL.agent file) to associate that specific socket with a hostkey, so if you connect to host A, your local client informs ssh-agent that future commands will originate from host A.

The publickey SSH auth method has also been extended (well, forked) to make the to-be-signed challenge include the server's hostkey, so the agent knows what server you're authenticating to. I think that's how the destination constraint is enforced; if the final server doesn't support the extended auth method, but only the standard one, then I assume the agent will not allow the key to be used at all.

SSH and ProxyJump

grawity — Thu, 06 Jan 2022 10:52:23 +0000

Realistically, if someone holds valuable SSH keys on the local system, then they're likely using at least OpenSSH 5.2 (2010) which is when the netcat-free -W %h:%p option became available. So I'd rather describe ProxyJump as shorthand for ProxyCommand "ssh <bastion> -W %h:%p". Although netcat-based fallbacks are definitely still useful in situations where the jumphost's admin deliberately disabled TCP tunnelling...

Restricting SSH agent keys

taladar — Thu, 06 Jan 2022 09:37:11 +0000

Unless the agent itself initiates the whole connection how does it know that the SSH process on the compromised server does not present the host key for host A and says it will use user a while actually using the signing result to connect to host B and use user b? Does the content it has to sign to connect contain that information and it inspects it?

Restricting SSH agent keys

taladar — Thu, 06 Jan 2022 09:31:54 +0000

Personally I would find having to type any commands on the bastion host a lot less convenient than just putting whatever ProxyCommand or (in newer versions) ProxyJump configurations into my ~/.ssh/config and literally forgetting about which hosts even need one or more levels of connections via bastion hosts.

Requiring confirmation before using the key

fmarier — Thu, 06 Jan 2022 05:59:28 +0000

There is a related ssh-add option which makes keys subject to a user confirmation (i.e. pressing Enter or clicking a button) via ssh-askpass before using the key for authentication. I have the following in my ~/.bash_aliases:

alias ssh-add='ssh-add -c'

Restricting SSH agent keys

NYKevin — Thu, 06 Jan 2022 01:52:04 +0000

It may be the case that you want to have a long-lived session on the bastion, and a bunch of short-lived sessions on various individual servers, perhaps with -L and/or -R forwarding between the bastion and the servers. I'm fairly certain you can still do that with an appropriate ProxyJump configuration, but it seems like it would be more complicated to set up (as opposed to just typing a bunch of individual ssh commands with appropriate flags after you have ssh'd into the bastion). Meanwhile, if you *mostly* trust the bastion but want defense in depth against extraordinary insider threats, applying ssh-agent key restrictions might be a good compromise for that use case.

SSH and ProxyJump

rra — Wed, 05 Jan 2022 23:47:15 +0000

ProxyJump can be easily simulated with older versions of ssh that don't support it by using ProxyCommand in .ssh/config instead:

ProxyCommand ssh <bastion> nc -w 1 %h 22

ProxyJump is basically shorthand for that, without requiring netcat be installed on the bastion host. (There are variations using other ssh options that were added later, but I think the above ProxyCommand syntax will work with quite old versions of ssh.)

SSH and ProxyJump

nickodell — Wed, 05 Jan 2022 23:30:44 +0000

Glad to see this work being done. I want to mention a more secure alternative to agent forwarding which is easy to set up.

Many people who use agent forwarding are using it to log into a bastion host of some kind, and then logging into a second host, where the second host is not directly accessible from the internet.

For this use case, you can use a jump host instead of agent forwarding. Rather than having the bastion host decrypt and re-encrypt the SSH tunnel, the jump host works by asking the bastion to forward encrypted traffic to the destination server. This way, you don't need to trust the bastion host.

For more information, take a look at the -J option in the ssh manpage, or the ProxyJump option in the ssh_config manpage. It's available since OpenSSH 7.3.

Restricting SSH agent keys

lucaswerkmeister — Wed, 05 Jan 2022 23:14:59 +0000

> A user who remotely connects to HostA, and from there to one or more other hosts using the same SSH key, will likely find it convenient to make the initial SSH connection to HostA with agent-forwarding enabled

Isn’t it usually better to use ProxyJump for such situations, leaving the authentication with the other hosts to the local SSH instance? Or am I missing something?