I am fairly glad I have stuck with stock OpenSSH that ships with Linux. This incident proves I am glad with that choice.
Over the decades, I have maintained remote access through port forwarding on my router - at one point in 2008 I put SSH on port 80 so I could access it from the restricted wifi network at the hospital my grandmother was at. I have also used openvpn. I have also used cloudflare tunnels. But in the end, I always connect to hardened openssh with key only authentication.
Adding complexity would imply you're doing both. In this case it would be more correct to say you're trading the complexity of key distribution and access control via keys for the complexity introduced by tailscale ssh.
No, it doesn't sound like it. Tailscale reduces complexity. It literally is key distribution with an ACL.
I work at a finance org with hundreds of engineers and thousands of technical users. You cannot be compliant with finance compliance frameworks using OpenSSH without audits and traceability and some source of identity management. That is exactly what Tailscale (or an alternative product) provides.
> and now, bugs
If you do it yourself, you now own that software entirely. Your comment lacks understanding of the complexity of real world scenarios.
I gather the bug allows people you've explicitly authorized to ssh into some account on your machine, to access more than that account can. So if you only use ssh yourself, or only give ssh keys for users with sudo, or only to people you trust not to exploit this, or if other vulnerabilities allow local shell users to escalate, or if you only use tailscale for port forwarding, then you're unaffected. Arguably even less exposed than a public openssh instance, though I can't say I have any issue doing that
Of course it is, if you rely on that boundary. The 'consumer' use of tailscale is just as a reverse proxy, and that's how I figured GGP sees it. I don't have anyone on my tailnet, and when I did they didn't have ssh keys, and if they did I imagine there'd be many paths to privilege escalation, certainly it's a bigger surface than sshd. So I was clarifying it seems like an escalation from authorized execution to privileged execution, and not e.g. from unauthorized users to RCE
I run WireGuard VPN on port 443 UDP. Many times I can connect to that from various public WiFi networks like coffee shops and public libraries. And then I ssh into my machines at home over my self-hosted VPN.
I’ve been hoping that HTTP3 adoption would make 443 UDP accessible from even more places. But maybe they already do the kind of thing you said for that too, looking at the traffic flow to determine that it is not HTTPS.
Weirdly sometimes there are WiFi networks where I am not able to connect to my WireGuard VPN on 443 UDP, but I can connect to servers over ssh on standard port 22 TCP. Perhaps they sometimes block all UDP traffic because they don’t want people to use BitTorrent etc, but one would think that with all the online meeting platforms that do video streaming there would be a lot of problems for people if all UDP traffic was blanket blocked.
I might eventually try out AmneziaWG instead of vanilla WireGuard, but at the moment I am fine not being able to Connect to my VPN sometimes. I only use it to connect to my other machines anyway, not as a VPN tunnel for my web browsing etc.
it's possible commercial routers such as the ones utilized by restaurants allow wireguard through these days? wireguard makes no effort to be stealthy when emitting.
some VPN apps bypass wireguard blocks automatically by using https tunnels and whatnot.
Does mosh help with it? Seems to be based on udp, and it looks good. I am not entirely sure if it helps the issue that you are talking about so hoping for someone more experienced to chime in
Naive. There's not much that prevents you from running ssh over https. Not even traffic patterns will give you up in the age of ubiquitous websockets and/or http2 streams.
Its not always the case but many of MITM-ing corporate firewalls are going to immediately drop any TLS connection they can't decrypt on the basis they're coming from an unauthorised device.
> Not even traffic patterns will give you up in the age of ubiquitous websockets and/or http2 streams.
SSH is dead simple to detect, because the server sends an outbound greeting in ASCII text; and the client doesn't send anything until it gets the greeting. The binary protocol does not look like a TLS stream at all either.
Over the decades, I have maintained remote access through port forwarding on my router - at one point in 2008 I put SSH on port 80 so I could access it from the restricted wifi network at the hospital my grandmother was at. I have also used openvpn. I have also used cloudflare tunnels. But in the end, I always connect to hardened openssh with key only authentication.