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.
> 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/, 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).
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?!).
I wasn't asking about -w - I'm specifically asking about ssh'ing directly to target servers, not ssh'ing to bastion boxes and making an ad-hoc VPN. The BeyondCorp ethos is not that everyone should put their ad-hoc VPNs on the internet, it's that you should ditch your VPN and put your actual services on the internet and secure them because your internal network isn't meaningfully more secure than the internet (especially if you have personal devices connecting to the VPN).
I'll try to blog about it this weekend! It is sort of like the BeyondCorp model (see the paper https://storage.googleapis.com/pub-tools-public-publication-... if you haven't read it) but taken to a bit more of an extreme - instead of having servers on a trusted network and clients, either on the office network or elsewhere, have some proxies before hitting internal services, everything is on an untrusted network.
This was the traditional model of the internet, from before NATs and VPNs were invented. This was the model under which Kerberos was developed - remote processes should only talk to each other over secured connections after authenticating each other, because their transport is the public internet, and there's no distinction between human-to-server and server-to-server in this regard. It was the model under which SSH (trust-on-first-use with no authorities), the HTTPS PKI (fully-qualified hostnames only), etc. were designed.
It's also sounds like a model I've recently advocated for and implemented in software I'm working on. And AFAICT it also lines up with the IPv6 model of the internet. It's great to know there's support for this style of identity management and I hope it proliferates. Looking forward to the blog!
