Hacker News Reader

Comment by WhackyIdeas | Hacker News Reader

Am I reading this right - any system with ssh-agent installed by default is vulnerable?

The link is short on specifics.

As far as I read it, it's about forwarded ssh agents. Basically, if you `ssh -A user@system`, something might be able to execute commands locally. For example, this might turn messy for infrastructures using jump-hosts extensively, if people are used to <ssh -A jumphost> so they can easily <ssh system> afterwards. If you pop the jump host, you could pivot to the workstations with this.

At the same time, ssh-agent forwarding makes me queasy from a security perspective even without this. As far as I know, if you <ssh -A> into a system, admins with privileges on the system can gain access to your local ssh-agent already. In the example of the jump host, if you popped the jump host and stuck around for a while, you could probably harvest SSH keys and have some fun later.

FWIW, `ProxyJump` is a safer way to go through a bastion without having to expose your agent to either the bastion or the target host behind it.

And since the person you're replying to was mentioning command-line parameters, it's worth mentioning that this can be done with `ssh -J jumphost user@system`.

Useful, I didn't know that so far.

We don't use bastion servers. My only real use case for ssh agent forwarding is if I need some scp / rsync between two remote systems during emergencies and those systems have no trust via SSH keys setup between them. In that very specific case, I don't know a better way than <ssh -A> to the first system and have some <rsync -e ssh> from there to the second system. Still doesn't feel great, even though I know only the people who could steal my keys are on my team.

Ah yeah. Not sure on that one. scp does have the `-3` option to copy between two remote hosts via the local host, but that can be significantly slower if the remote hosts are in the same network and local host is not.

Exactly. If I need to move a few megabytes around, <scp -3> and a coffee or a few simple tickets is a good way. A year ago or so, I needed 600GB moved between two systems ASAP during an outage that'd turn into a money-bleed at 6am. If I piped that through the VPN and my workstation, I'd probably still be waiting today.

Some time take a look at lftp [1] and its mirror subsystem for this. It can break up a batch of files or even one large file into multiple SFTP streams. Another upside is that it can replicate most rsync behavior in a SFTP-Only Chroot account. Downside is that without a corresponding daemon like rsync on the other end directory enumeration is slow which isn't a problem if one does not have a complex directory structure.

Play around with the built in rate limit options total and per thread to keep the network people happy.

[1] - https://linux.die.net/man/1/lftp

Well, any system that auto maps the stack executable when loading a library. There are details on the specific requirements in the advisory.

https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh...

It's exploitable only by a SSH server that you connect to with agent forwarding enabled (i.e. one that you're already trusting with access to your SSH keys).

If I read this correctly it is only when you forward your ssh-agent with the "-A" or "ForwardAgent" option

I’d you forward your agent to a remote host, that host can mess with you.

Reply on news.ycombinator.com