Hacker News Reader

Comment by jsn | Hacker News Reader

It's called secure shell for a reason. You know your ProxyCommand isn't tampered with because your ssh client has successfully matched the remote system key against your known_hosts file.

View on HN

Looks like I slightly misunderstood how the command functioned, what with proxying the traffic back to your local ssh client.

I thought it was more like `ssh hosta 'ssh hostb'`, which would be problematic, but that's not the case. Phew.

So while non-secure protocols through ProxyCommand could still get MITM'd if they own hostA's sshd, proxying ssh itself would be fine, assuming you already had fingerprints. Much less worrisome. :)

Yeah, exactly, only your machine and the endpoint have to be secure for your application to be secure. I frequently run something like plain HTTP, netcat and other stuff over a ProxyCommand-initiated session.

Um, you realize that you're still relying on the mid-point SSHD to relay TCP packets without MITMing you though, right?

The only reason ProxyCommand to tunnel SSH would be safe is because your local SSH uses authentication, and you would get the freaky WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED, IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! warning. (eg known_hosts)

Netcat and plain HTTP don't have an authentication layer, so if your proxy server is compromised, so is your plain traffic.

EDIT: see this other reply for another source: https://news.ycombinator.com/item?id=9428518

Reply on news.ycombinator.com