Do pre-authentication OpenSSH vulnerabilities happen a lot, or something?
If you ever use SSH to tunnel/forward TCP traffic, you should be aware of certain performance issues [1], due to TCP's re-transmit mis-behaving (stacking) in a TCP-in-TCP scenario. Expect seemingly random delays, followed by bursts of transmission even well below the nominal capacity of the connection. This also causes overall increase in amount of data sent.
The same caveat applies to any other TCP-in-TCP tunnel (as opposed to the usual TCP-in-UDP setup), unless one or both tunnel endpoints specifically handle re-transmits properly.
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.
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).
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.
This stuff isn’t that hard.
ackshually.jpg
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.
Having a VPN is a pretty great control for the vast majority of organizations that don’t have the operational maturity to pull the public IP apart of BeyondCorp off. FWIW: we are helping customers with differential access controls (and I love Chromebooks despite the license purchasing experience). But even if you go full public-IP BeyondCorp you’re going to have some machines you’re not exposing (though it should be fine to expose them, as you mention), and occasionally you need to reach them, and VPNs remain great for that. VPNs being unnecessary (and giving a false sense of security) for human-facing endpoints in a company with a multi billion dollar security org? Sure, it’s hard to disagree: to your point Google is working on the proof by construction :-D
(See also: People migrating from FTP to SFTP and haven't heard the good word of rsync with key auth.)