* The SSH codebase is much, much more complicated than WireGuard's (but it has a very strong track record at this point).
* The underlying SSH protocol dates back into the 1990s, is cryptographically inferior to WireGuard, and does not have an especially strong track record (it's record is similar to that of TLS).
* SSH is opt-in secure for a selection of ports; WireGuard (really, any real VPN) is default secure for all traffic, which is why you use it.
Mostly, though, the reason you'd use a VPN instead of SSH is that VPNs are easier to use. The reason people use SSH instead of VPNs is that most VPNs are hard to set up. That's a big part of what WireGuard fixes.
Another stated reason is that SSH runs on TCP and running TCP apps on a TCP VPN is inefficient. It’s two layers of reliable delivery. It’s better to use UDP in the VPN which is what WireGuard does.
That's not the entire truth. TCP over TCP is not a good mix, but SSH tunnels are different.
SSH tunnels are not VPN tunnels. SSH will act as the endpoint for your TCP application and only tunnel the application payload over SSH (TCP). On the other side a new TCP session will be opened over which that payload is sent. So you never do TCP over TCP.
It's more so a proxy than a tunnel and that avoids the real issue, which is nested congestion control. In addition SSH should also be able to do so with less overhead (in bytes) than a VPN (which need to forward the IP and TCP header intact), but I don't know how well SSH takes advantage of that.
SSH tunneling can outperform OpenVPN running in TCP or UDP mode.
By SSH tunneling, I assume you mean SSH port forwarding (-R/-L). Recent OpenSSH also has Tunnel (-w) which provides an IP-level VPN, in which case it does do TCP over TCP.
Would you say this is true even if you configured openssh to only use the more modern options?
In recent years they've added a chacha20+poly1305 option as well as Curve25519 for key exchange and ed25519 for host and user authentication.
This would seem to bring it up to about an equivalent level cryptogtaphically speaking, in terms of application security, it's definitely more complicated, but it's also one of the most proven pieces of software around and much of that complexity is post-auth. The wireguard site itself pretty clearly states that it hasn't seen much in the way of field testing, though it does look extremely promising. I'll definitely be keeping on eye on it once it's available on more platforms.
Yes. The primitives aren't where protocols tend to go wrong; it's the joinery that's the problem. WireGuard is Noise, which was designed with 20 years of hindsight into what breaks transport protocols.
* The underlying SSH protocol dates back into the 1990s, is cryptographically inferior to WireGuard, and does not have an especially strong track record (it's record is similar to that of TLS).
* SSH is opt-in secure for a selection of ports; WireGuard (really, any real VPN) is default secure for all traffic, which is why you use it.
Mostly, though, the reason you'd use a VPN instead of SSH is that VPNs are easier to use. The reason people use SSH instead of VPNs is that most VPNs are hard to set up. That's a big part of what WireGuard fixes.