Restricting SSH Agent Keys | Hacker News Reader

Restricting SSH Agent Keys

lwn.net

98 pointschmaynard16 comments

Instead of forwarding the ssh agent I use a bastion host and proxycommand. That lets me keep the ssh private key on the outermost host.

The outer system has the key, and the inner bastion system has the acl to connect inward to actual servers. Works well.

My solution to this was to make my SSH agent (Pageant) show a prompt for authorization when a request comes in, since I only use it for interactive sessions it doesn't break anything. Seems like it would be a good feature for any agent software to have.

This. Not proud, but Windows user here: I use KeeAgent Plugin [1] for Keepass to manage my SSH keys (Putty/Pageant). Windows Subsystem for Linux (WSL 1 and 2) connects to the Pageant SSH Agent via a Socket. When I SSH -A into machines on WSL, my KeePass DB opens and I need to confirm each key use (`Always require confirmation when client program requests to use key`). This simply means hitting enter twice, instead of once. The Keepass DB is set to stay unlocked for 6 Minutes when not in use, which is usually enough to not require entering the master key more than once during working hours.

Of course, I still make sure to only use `-A` to servers I trust.

[1]: https://keeagent.readthedocs.io/en/stable/

A perfect solution for me would be something like ssh-add -c (which asks for confirmation on any agent access) but which could distinguish between local and remote agent access.

I want to add every key to ssh-agent on my local machine, be able to login into remote hosts with them but have a pop-up confirmation if there's an agent access from remote host where agent is forwarded.

There is a tool that implements this: https://github.com/StanfordSNR/guardian-agent

The problem basically is the current agent forwarding protocol doesn't have a way to reliably identify the source and remote host that can't be spoofed. guardian-agent tries to do that using some extra software, this linked SSH proposal is to add that to SSH but it will require software upgrades even to the sshd of the intermediate and remote hosts - it's not ideal that it can't just work out of the box - but I welcome this we just need to get it done now for later.

I frequently finding myself thinking about adding useful things to software I want to use now and go well it will be years before its on every host I use and can be used reliably. I have had this thought on and off for more than a decade. Ship some new stuff, it'l be great later :D

https://www.openssh.com/agent-restrict.html just got added to openssh

LWN reporting on these changes:

> OpenSSH 8.9 will include the ability to control how and where keys in ssh-agent may be used, both locally and when forwarded (subject to some limitations).

* https://www.openssh.com/agent-restrict.html

SSH should be a part of any high school (and middle school) CS class. For a young teen, it was perfect for learning the basics of general security practices and provided a pretty quick and fun way to do neat things with computers from a distance. Gave me some motivation to dive into shell scripting and beyond.

What problems are solved by agent forwarding that aren't solved by ssh -J/-o ProxyJump?

I need both agent forwarding and ProxyJump. Imagine there is a bastion host and hosts X and Y (that don't have public IPs and are reachable from bastion)

I use ProxyJump to get to host X, but I also need ssh-agent forwarding to copy files directly from host X to host Y. Luckily I don't need to copy files in such way in every interactive session so I guess I can disable agent forwarding by default

Yeah I can see that. How about something like

    $ ssh -J <bastion> hostX base64 srcfile | ssh -J <bastion> -t "base64 -d /dev/stdin > dstfile"

Having to use the local machine as an intermediary is a bit hacky but I know something like this is how emacs handles remote files (IIRC it also uses gzip).

no, it's way too hacky, don't want to copy several GBs of files through the intermediary

my colleagues used approach with manually launching nc on hosts X and Y to avoid using the intermediate host. But that's also hacky ( though probably faster than ssh due to lack of encryption )

git/hg clone from a remote host (using ssh key auth)

Seems like the answer is, "run arbitrary ssh-based commands on remote1 targeting remote2".

https://en.wikipedia.org/wiki/PKCS_11 which you can still -A just fine. Same goes for ecdsa-sk/ed25519-sk which you can use with modern hardware keys, sensible and practical.

I hope support for these features gets added to GPG's SSH agent soon

Reply on news.ycombinator.com