3 ms·

You are partially wrong. OpenSSH, and the SSH standard in general, support "multiplexing SSH connections", where several remote shell sessions share single TCP

by dexen 8y ago

You are partially wrong. OpenSSH, and the SSH standard in general, support "multiplexing SSH connections", where several remote shell sessions share single TCP connection. This is unaffected, as there's only one TCP layer in play. For OpenSSH this is options "-M" and possibly "-J" (not sure). Another, unrelated functionality is a straight-up TCP tunneling over the SSH connection. This is an actual TCP tunnel, with all the advantages and warts of the setup. With OpenSSH, it's options "-L" and "-R". Those options take host:port arguments, and do proper TCP-level forwarding, encrypted and compressed like any other SSH stream, layered over any transport your SSH happens to be using. Which typically is also TCP, thus creating a TCP-in-TCP scenario. There's also "-w" which tunnels tun(4) connection, over which you could end up sending TCP traffic. Note that neither 'authentication agent forwarding' nor 'X11 forwarding' have anything to do with any network tunneling; those just pass small chunks of meta-data out-of-band.

geofft 8y ago
> With OpenSSH, it's options "-L" and "-R". Those options take host:port arguments, and do proper TCP-level forwarding, encrypted and compressed like any other SSH stream, layered over any transport your SSH happens to be using. Which typically is also TCP, thus creating a TCP-in-TCP scenario. I don't believe this is right - the thing tunneled over SSH is the data flowing within the TCP connection, not the TCP connection itself. If I do `ssh -L8080:foo:8080 bar.example.com` and then connect to http://localhost:8080/ http://localhost:8080/, then my browser's TCP connection terminates at my local SSH process, which decapsulates the TCP stream and sends it over SSH. Then the SSH server on bar creates a new TCP connection to foo. Therefore there isn't TCP inside TCP. There are three TCP connections connected in series: my browser to ssh on localhost (HTTP inside TCP, ssh to foo (HTTP inside SSH inside TCP), and sshd on foo to web server on bar (HTTP inside TCP). Therefore the "TCP-in-TCP" problem, where a delayed/dropped packet creates backoff in both the inner and outer TCP connections, doesn't apply. When my browser sends a packet, it is immediately and reliably ACKed by the ssh process running on my local machine. That ssh process might fail to get the resulting encrypted packet to foo, but that only affects a single TCP connection, the one from my laptop to foo:22. The browser sees a slow connection, but it sees it being slow at the application layer, not at the TCP layer. So I think 'sneak is mostly right with the exception of ssh -w, which is a relatively new feature (and not what I was asking about at the top of the thread, in any case).
- sneak 8y ago
  Yes, thank you for typing that out so that I don’t have to. Also, -w is some new nonsense that nobody should really be using except in some super dumb and hacky situations where there is no other option.
sneak 8y ago
As noted below, -L and -R do not have access to raw tcp packet data, only tcp stream contents. Those options do not do TCP-in-TCP. It wouldn’t work anyway as usually the networks you’re forwarding into have entirely different numbering and the bastion host isn’t usually the gateway (did you think sshd has a userspace NAT implementation?!). This stuff isn’t that hard. ackshually.jpg

by dexen 8y ago

geofft 8y ago

> With OpenSSH, it's options "-L" and "-R". Those options take host:port arguments, and do proper TCP-level forwarding, encrypted and compressed like any other SSH stream, layered over any transport your SSH happens to be using. Which typically is also TCP, thus creating a TCP-in-TCP scenario. I don't believe this is right - the thing tunneled over SSH is the data flowing within the TCP connection, not the TCP connection itself. If I do `ssh -L8080:foo:8080 bar.example.com` and then connect to http://localhost:8080/ http://localhost:8080/, then my browser's TCP connection terminates at my local SSH process, which decapsulates the TCP stream and sends it over SSH. Then the SSH server on bar creates a new TCP connection to foo. Therefore there isn't TCP inside TCP. There are three TCP connections connected in series: my browser to ssh on localhost (HTTP inside TCP, ssh to foo (HTTP inside SSH inside TCP), and sshd on foo to web server on bar (HTTP inside TCP). Therefore the "TCP-in-TCP" problem, where a delayed/dropped packet creates backoff in both the inner and outer TCP connections, doesn't apply. When my browser sends a packet, it is immediately and reliably ACKed by the ssh process running on my local machine. That ssh process might fail to get the resulting encrypted packet to foo, but that only affects a single TCP connection, the one from my laptop to foo:22. The browser sees a slow connection, but it sees it being slow at the application layer, not at the TCP layer. So I think 'sneak is mostly right with the exception of ssh -w, which is a relatively new feature (and not what I was asking about at the top of the thread, in any case).

sneak 8y ago
Yes, thank you for typing that out so that I don’t have to. Also, -w is some new nonsense that nobody should really be using except in some super dumb and hacky situations where there is no other option.

sneak 8y ago

As noted below, -L and -R do not have access to raw tcp packet data, only tcp stream contents. Those options do not do TCP-in-TCP. It wouldn’t work anyway as usually the networks you’re forwarding into have entirely different numbering and the bastion host isn’t usually the gateway (did you think sshd has a userspace NAT implementation?!). This stuff isn’t that hard. ackshually.jpg