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

71–80 of 311 posts

Re: Tailscale SSH

#71

Post by e12e »

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…

> (...) 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 processes (or iptables rules, etc) that would prevent the Tailscale SSH server from binding to port 22.

This sounds like a great feature when exploiting buggy WordPress/php apps! /s

I realize this is a feature - but it's a bit sad that the standard package handling isn't up to the task; leaving (I expect) the tailscale daemon as a "magic" netcitizen - not featuring in neither "ss" or "iptables" output (why can't I login to opensshd?).

Re: Tailscale SSH

#72

Post by infocollector »

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…

Hi Brad: Thanks for helping out with this feature! I've been one of the early users of tailscale. My network is around 50 machines. I've recently started having issues with ssh on some of my machines, especially from mac m1 -> some ubuntu boxes. Could this be related to this new feature? Any suggestions/pointers on how to debug these issues?

Re: Tailscale SSH

#73

Post by sandstrom »

sandstrom wrote: post #70

Good! Boundary ( https://www.boundaryproject.io/ ) by Hashicorp needs some healthy competition. Teleport is also a tool in this space, for those looking for alternatives.

And for anyone looking at Tailscale, I should also mention ZeroTier (https://www.zerotier.com/).

In my opinion they have better tech, but they are pretty bad at packaging it, and bad at making it work for actual use-cases.

Tailscale seems to be much more clever around building out stuff (like this one, SSH) that actually goes all the way for a particular use-case. ZeroTier feels more like a building block, where you need to bring more stuff yourself.

Either way, both are awesome pieces of technology, and really useful!

Re: Tailscale SSH

#74

Post by aidos »

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…

Just a quick thank you to the team working on Tailscale. It’s hands down the most seamless dev experience I’ve ever seen. Every time I think “such and such would be nice”, I search the docs, and it’s already implemented better than I could have expected (eg the stateless mode for ephemeral servers).

I tinkered with cloudflare before that but just couldn’t get on with the interface of the admin tooling.

With Tailscale I have a lot more confidence that I’ve set up the access rules as I need them. It’s all just a lot more obvious.

Re: Tailscale SSH

#75

Post by dstaley »

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…

Could you share some details about the embedded SSH server? I'm curious if this would work to add SSH capabilities to devices that run Tailscale but don't include a built-in SSH server. Previously I've used dropbear, so it'd be really nice to be able to drop that requirement!

Re: Tailscale SSH

#77

Post by tptacek »

e12e wrote: post #71
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…

> (...) 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 processes (or iptables rules, etc) that would prevent the Tailscale SSH server from binding to port 22. This sounds like a great feature when explo…

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.

Re: Tailscale SSH

#78

Post by tptacek »

swozey wrote: post #43
danousna wrote: post #13

What would be the advantages of this compared to say Teleport ? Teleport is working fine for us, but I wonder if the network based approach (+ wireguard) of Tailscale would be better in terms of network redundancy ?

Well, how long did it take you to set up Teleport?

It took us about an hour.

Re: Tailscale SSH

#79

Post by dave_universetf »

tptacek wrote: post #68
danousna wrote: post #13

What would be the advantages of this compared to say Teleport ? Teleport is working fine for us, but I wonder if the network based approach (+ wireguard) of Tailscale would be better in terms of network redundancy ?

The big thing you get with Teleport that you don't yet get with Tailscale --- apart from entirely owning the source of truth for SSH authentication on your own infra, which is a very minor issue for almost everyone but is a major issue for some people --- is that Teleport gives you transcript-level audit logs of your SSH sessions. Teleport also has that web-based SSH console (it's one of the better web-based consoles…

Session recording's actually already in the network engine for SSH, we just haven't plumbed the whole "push recordings somewhere and surface them" yet. Soon :)

Re: Tailscale SSH

#80

Post by tptacek »

RL_Quine wrote: post #3

I'm not entirely convinced I want a feature that adds even more exposure to the sort of goofy login flow Tailscale has.

It's helpful for people to know, from context later in the thread, that one of the core concerns behind this comment is the idea of using SSO at all, and thus giving "the keys to the kingdom" to Google.

Of course, it's also worth knowing that SSO is basically a universal best-practice for security teams, and while it's not de jure required by SOC2, it's almost de facto required. For once, I think the best-practices and compliance people have this one right: you are extraordinarily unlikely to get burnt for trusting Google in this instance, and the security track record of ad-hoc authentication is worse than abysmal (ad-hoc authentication is probably implicated in a plurality of all major incidents).

Post reply on HN