Live data from Hacker News

Tailscale SSH

tailscale.com

151–160 of 311 posts

Re: Tailscale SSH

#151

But you still can't have multiple tailnets. The strategy of "have hobbyists try out the software themselves, like it, then implement it at their work" seems incompatible with this fact.

Agreed this is a big limitation.

The only way to do it is if you have secondary email address domains. Say mdeeks@company.com and mdeeks@company.team. You can create a separate tailnet for company.team but you also have to roll out additional subnet routers (if you use them) that are authed on that second tailnet. Also you wont be able to easily write rules that interact with things that are not authed onto the second tailnet.

They need a first class concept of "canary" or "beta" that applies to ACLs, DNS configs, client versions, and all sorts of other toggles in the UI. It's a hard product problem and I'm not even sure how some of it should work.

I just know I need a way to test changes before I roll it out to everyone at the company. Right now there aren't good options for that.

Re: Tailscale SSH

#152
post #14

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.

In this case, double encryption is a good idea though. Tailscale is a great way to reduce exposure of your infrastructure from the public internet, but it’s not without flaws. In theory, it should be possible for Tailscale and your SSO provider to add new nodes to your Tailnet. Though I don’t believe this is something that they’re actually willing to do, it’s definitely something to keep in mind if you’re planning on…

Double encryption doesn't actually help in that case though - if tailscale (maliciously) added nodes to your network the ssh session being encrypted wouldn't change the fact that they can run commands on your machines. And if they wanted to actively MITM you they could do so (by redirecting your wireguard connection to a server owned by them) even with encryption (presuming they can fake the host key, which they could do at worst by running code on your server to steal it).

To be clear I implicitly and explicitly trust tailscale not to tamper with my networks and if your threat model includes tailscale becoming a bad actor you should remember that in that case running their binary in the first place could already be game over.

Re: Tailscale SSH

#154

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…

So we have no way to secure this besides disabling wireguard ?

Re: Tailscale SSH

#155
post #148
post #77

Earlier quoted context omitted.

How do you figure? The idea is that Tailscale is bypassing the kernel, which it can only do for requests coming in over the tailnet --- it gets those packets raw, directly from WireGuard, unlike the normal IP packets your kernel routes to/from localhost or an egress interface.

> [only for..] requests coming in over the tailnet Well, that's certainly different from "all TCP port 22 packets" - I suppose some emphasis should be on "after the WireGuard decryption" (ie: over the wireguard interface). It's not entirely clear from the comment (but probably clear to engineers working on the tailscale code). I read it as if tailscale snapped up packets before the kernel from (all) network interface…

How could it possibly work otherwise? Tailscale owns the WireGuard connection, so it gets raw packets from WireGuard before the kernel.

Re: Tailscale SSH

#156
post #153
post #78

Earlier quoted context omitted.

It took us about an hour.

That's shocking considering my experience of weeks, nice.

We thought it was going to be a whole huge project and budgeted a week for it. It was not a whole huge project.

Re: Tailscale SSH

#157

I know this opinion comes up every time Tailscale is mentioned, but requiring SSO _and_ only supporting companies like Google and Microsoft on the free tier means a lot of people can't use it without being exposed to a ton of risk in the form of automated moderation/deletion decisions. I want to be excited about this stuff, but it just won't fit into my risk profile until that changes. Hell, I'd be happy to pay $5/mo…

This is a workaround, but could you minimize that risk by signing up for both Microsoft and Google? It should help for any policy / moderation / "computer says no" decisions that are vendor-specific.

(On the other hand, for security risks, it means that a security hole in either one would be a problem.)

Re: Tailscale SSH

#158

I know this opinion comes up every time Tailscale is mentioned, but requiring SSO _and_ only supporting companies like Google and Microsoft on the free tier means a lot of people can't use it without being exposed to a ton of risk in the form of automated moderation/deletion decisions. I want to be excited about this stuff, but it just won't fit into my risk profile until that changes. Hell, I'd be happy to pay $5/mo…

I can see some risk with say Google as the surface area is much larger (maybe they don’t like some play store activity or some ads activity or YouTube activity, etc). But I use my GitHub account and I’m really not worried about automated moderation locking me out of my account.

Re: Tailscale SSH

#159
So @bradfitz when are you releasing https://tailscale.com/connect/ for real? :)

Context for the uninitiated - as a crazy idea on the podcast Security Cryptography Whatever (hosted by tptacek and others less well known on HN) Avery and Brad of tailscale imagined an ssh client in the browser with QR code authentication to SSO to allow you to connect to your tailscale network (over tailscale SSH) from untrusted computers such as internet cafes. (Or mostly untrusted - safe from keyloggers but maybe not from a dedicated active malware that injects into your browser and tries to inject secret commands into your ssh session).

I created a silly PoC here (video instead of link because don't try it for real) https://twitter.com/jgeralnik/status/1487913797155233798 back when tailscale ssh was a secret binary in the tailscale github repo

Re: Tailscale SSH

#160
post #8

Never login as root… even over secured links!

Why? To me it doesn’t make sense not to do so. What kind of security gives you logging it as non root user and then using sudo (maybe even without a password) to become root?

Root makes everything more easier, for example to copy a file on a server with scp if you don’t have root login you first has to copy it to /tmp and the copy it in the right directory by logging in as normal user and elevating with su/sudo.

Also you have to remember which username was chosen when the server was installed, was it user, admin, or pi, or some default?

I get not using root for everyday usage on a desktop, but for a server having a non root user is not that useful.

Of course you have to know what you are doing, but sudo doesn’t protect you from stupid mistakes anyway (especially if configured with NOPASSWD as I always see doing because having to continuously type the password is annoying and password tends to be forgotten)

Post reply on HN