I'm one of the authors of this. Happy to answer any questions. One of the fun technical details is that, when enabled on a machine (tailscale up --ssh), the userspace tailscaled process takes over all TCP port 22 packets after the WireGuard decryption and doesn't even feed them into the kernel over TUN. We use gVisor's netstack to handle the TCP connections in-process. So it doesn't matter whether you have other proc…
quick question. Does this do user (de)provisioning like Jumpcloud? I.e. if the target machine doesn't have a /home/someuser but someuser is in my tailnet ACL, will it create the account?
I'm not entirely convinced I want a feature that adds even more exposure to the sort of goofy login flow Tailscale has.
Totally meta to this discussion: I am disturbed by the SSO/IAM trend because it gives root on the entire universe to a small collection of companies. We are looking at a future where a security breach or misbehavior by one of a handful of companies could mass-compromise millions of businesses and critical infrastructure and possibly hundreds of millions to billions of devices. Even worse this permission is clandestin…
>Wait... why did I get a macOS update and none of my friends did?
That's an easy one to circumvent if you don't need to install the malware Right Now: just wait until the next update cycle and slipstream your targeted malware in with it.
I'm not following. How does double encryption help to avoid a password compromise if everything is authed with tailscale in the first place?
I suspect they mean that if you have rsh installed for tailscale you need to be very careful with how you run it. If you accidentally let rsh listen on 0.0.0.0 and don't firewall it then you've given attackers a way to guess passwords. Forgetting to firewall services or accidentally exposing services to the internet is pretty common. ssh is more hardened than rsh, especially with key based auth, so the risk is lower.
Isn't this true of SSH as well? What's stopping someone from letting sshd listen on 0.0.0.0 with password auth? Anyway, I would expect that whether you're using ssh or rsh/telnet/etc that you're not configuring it for password auth, but rather using tailscale authentication. Specifically, I would expect (perhaps naively) that tailscaled handles the ssh/telnet/rsh/whatever connections rather than passing them off to another process (sshd, telnetd, etc) and thus allowing it to handle the authentication and daemon configuration (e.g., what address it listens on).
I'm not following. How does double encryption help to avoid a password compromise if everything is authed with tailscale in the first place?
Somebody listening on local connections can sniff your password.
How does that work? First of all, I would expect that rsh-over-tailscale doesn't use password authentication, and secondly can a local user sniff traffic before it hits tailscaled?
Is there an option to avoid double encryption on systems that do have e.g. rsh?
I might be misunderstanding the question but ... just use rsh?
I think for the same reasons I wouldn't "just use ssh" over tailscale--I don't want to have to manage an sshd that doesn't require key or password auth but listens over tailscale (and nothing else!). Basically, what I want is for tailscaled to be my rshd (appropriately configured for connections over tailscale network only, etc) or in other words to avoid double-encryption (it's not the end of the world, but ideally we don't need to doubly-encrypt).
You're right, it's not at all the same. The Tailscale bypass exists (1) only for traffic traversing Tailscale interfaces (by design, that's the only traffic it can impact, because Tailscale can't run a userland TCP/IP stack for non-Tailscale traffic), and (2) only for this one feature, and (3) only if you've explicitly allowed it for particular users in your Tailscale ACLs. It's not clear to me how you could screw it…
All I'm trying to point out is that advertising "this bypasses the firewall, by design" has been abused in the past. [edit] It boils down to principle of least surprise, managing expectations, etc. - proper documentation is indeed key.
This sounds like more of a marketing thing, where the wording needs to employ care?
I'm one of the authors of this. Happy to answer any questions. One of the fun technical details is that, when enabled on a machine (tailscale up --ssh), the userspace tailscaled process takes over all TCP port 22 packets after the WireGuard decryption and doesn't even feed them into the kernel over TUN. We use gVisor's netstack to handle the TCP connections in-process. So it doesn't matter whether you have other proc…
What would we need to have open in our security groups for this to work? I think ingress wouldn't be necessary since tailscaled creates a tunnel right? But how about egress traffic? UDP for WireGuard or something else?
Security groups where? On the Tailscale ACL side, you need to allow tcp/22 in.
On your host where you're running Tailscale, usually nothing. You can keep everything locked down for ingress. Outbound UDP only, but usually cloud VMs allow outbound traffic already. (This is covered more in https://tailscale.com/kb/1082/firewall-ports/)
Looks interesting, but it seems that this doesn’t work well for servers where every user has a personal account. It appears that this use case would require a separate ACL entry for every user, which a) can get slightly annoying to manage and b) requires a business plan. It would be nice if something like `"users": ["autogroup:emailuser"]` was supported to allow `alice@example.com` to connect as the user `alice`, but that would probably cause issues with e.g. Github organizations, where email addresses can have different TLDs.
I'll have to ask this since it's bothering me for quite a while… If I connect to a server via WireGuard, would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? It's kinda pointless to double encrypt.
Double encryption is twice as effective. I use double ROT-13 for double the security.