4 ms·
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 aga
by jsn 11y ago
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.
- scott_karana 11y agoLooks 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. :)
- heipei 11y agoYeah, 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.
- scott_karana 11y agoUm, 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 https://news.ycombinator.com/item?id=9428518