Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tailscale SSH

tailscale.com

Post reply on HN
Print view View original

301–310 of 311 posts

Re: Tailscale SSH

#301

Post by KRuchan »

bradfitz wrote: post #51

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…

I attempted this on a VM inside a Linux host and got a lower privileged user from inside the guest VM to ssh to a root-privileged user outside on the host. Both were authenticated to Tailscale with the same gmail account, so from an OAuth perspective, this is valid. From the OS perspective though, the host SSH port is blocked, and a guest should never get full root access to the host or see the host's resources.

I am not sure if I am confused about something, or maybe there are prod use-cases where the same IDP identity should have different roles/privileges depending on the machine, and Tailscale SSH breaks that?

Re: Tailscale SSH

#302

Post by growse »

dekhn wrote: post #293
tptacek wrote: post #205

Earlier quoted context omitted.

If you're not already using Tailscale, with your security or IT teams controlling it, it would be malpractice to allow it on a controlled network. No competent security team allows people to introduce their own VPNs.

The way it works in enterprise that is principal engineers like me are generally given some freedom to explore new technologies responsibly. In my mind, that includes visiting the Tailscale website (which started being blocked by our IT yesterday) to gather information about whether this would be a good alternative technology for our research teams. Now what I have to do is file a bunch of tickets and take a bunch of…

> Now what I have to do is file a bunch of tickets and take a bunch of meetings to get a block removed from the overall site. Really, what I was trying to do is provide nformation to the Tailscale developers that enterprise already considers their website/product scary enough to do a whole block, and if they want to expand into enterprise, they may want to understand the reasons for that.

Not all large enterprises are this disfunctional. I'm sure Tailscale are doing just fine.

Re: Tailscale SSH

#303

Post by mike_d »

tptacek wrote: post #292
mike_d wrote: post #276

Earlier quoted context omitted.

They built a footgun into a toaster, and victim blame when people complain that they thought it was just supposed to make toast. Users should not be put into a situation where they need to configure ACLs in anticipation of undocumented features. My hope was that with a little public prodding they would do better in the future. It is a product I want to like, maybe not for what you or I do, but lots of folks out there…

"Victim blame". They announced an opt-in feature.

Ah, I see the part you are missing. It was rolled out before it was announced or documented. We found it during a pentest.

Re: Tailscale SSH

#304

Post by [deleted] »

bradfitz wrote: post #51

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…

[deleted]

Re: Tailscale SSH

#305

Post by e12e »

tptacek wrote: post #206
e12e wrote: post #196

Earlier quoted context omitted.

It could work like a full userspace network stack, getting the packets on the wire before (instead of) the kernel (network stack)?

How? (I can think of ways, and they're all horrible).

The fact that all the ways are horrible is indeed why I was so surprised to (mis)read tailscale as having such capabilities... I'm happy I misunderstood.

Re: Tailscale SSH

#306

Post by ithkuil »

pilif wrote: post #281
ithkuil wrote: post #278

Earlier quoted context omitted.

1. api keys != auth keys 2. you can disable key expiry for devices where it makes sense, see https://tailscale.com/kb/1028/key-expiry/#disabling-key-expi...

1. I know. I'm talking about API keys though - they do expire after 90 days. See https://tailscale.com/kb/1101/api/ 2. For API keys, expiration cannot be disabled.

Out of curiosity, what are you using the API for?

Re: Tailscale SSH

#307

Post by jgeralnik »

soraminazuki wrote: post #291
jgeralnik wrote: post #261

Earlier quoted context omitted.

But that's the thing - even with double encryption tailscale and your SSO can run commands on your machines 1) Run tailscale --ssh on your server 2) A malicious SSO or tailscale add a new machine to your network and update your ACL such that the new machine can connect to your server 3) ssh from the new machine to run code on your server The fact that the connection between the malicious machine and your server is do…

By double encryption, I mean using an SSH server other than "tailscale --ssh". No one except yourself can have SSH access if you disable Tailscale's builtin SSH server, use OpenSSH, and generate your own keys for authentication.

Ah, I don't think that's exactly what this thread was about. Ignoring how authorization works, the question was whether there is an advantage to encrypting your commands again (via say ssh) vs. just sending them in plaintext under wireguard (via say rsh)

Re: Tailscale SSH

#308

Post by dx034 »

edf13 wrote: post #271
dx034 wrote: post #270

Earlier quoted context omitted.

I've always heard that and adhered to that, but what's the advantage of me logging in with a user account to then use sudo for every command? It's not like I could break less than being logged in as root.

Lots of reasons… Tracking actions, fine grained policy controls, sharing a root password amongst multiple people, and then there is the risk of accidentally running a cmd as root when you thought you were in your home shell!

Confusing the server I'm on will always cause issues, not matter if I have to sudo for root.

I get the other points, but most servers I encountered don't have these fine grained controls because doing manual work on them only happens for debugging or fixing issues.

And the password doesn't need to be shared with sth like Tailscale.

Tracking actions is a good part though, I wonder if you can still track which tailscale user was responsible for that root login.

Re: Tailscale SSH

#309

Post by woleium »

tptacek wrote: post #207
woleium wrote: post #190

Earlier quoted context omitted.

What are the failure modes? Openssh is a well understood risk, this seems... unquantifiable?

Tailscale is a userland process built in a memory-safe language, which leaves you only the SSH protocol cryptography-type vulnerabilities, which are themselves mooted by Tailscale (see downthread for a discussion about why they didn't simply expose rsh instead of ssh). This is safer than OpenSSH. (OpenSSH, as a piece of software, is extraordinarily safe, and has one of the best records of any memory-unsafe codebases.…

Sure, but how reliable is it. What are the risks that I'm going to get locked out of a production instance and suffer loss of earnings?

Re: Tailscale SSH

#310

Post by bradfitz »

tornato7 wrote: post #244
dbmnt wrote: post #238

Earlier quoted context omitted.

Not really. It messes with DNS big time. Try enabling the "MagicDNS" or "Exit Nodes" features, and watch as /etc/resolv.conf is edited with each change. I can easily reproduce scenarios where it's left empty and there's no working DNS resolution. This is one of the major things I _don't_ like about Tailscale. I wish they'd just stick to enabling Wireguard and making the authentication easier (i.e., where they started…

Consistently I’m unable to use Tailscale on a GCP instance and also use GCP services cleanly, because it messes with the DNS route to the metadata server. Otherwise, it’s a great product.

https://github.com/tailscale/tailscale/issues/4911 is now fixed and will be in the next release.
Post reply on HN