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

131–140 of 311 posts

Re: Tailscale SSH

#131

Post by jsmith45 »

sandstrom wrote: post #117
doublepg23 wrote: post #101

Earlier quoted context omitted.

There is also the self-hostable Headscale implementation.

In case anyone is looking for the URL: https://github.com/juanfont/headscale 5k stars on Github, and lots of activity. Seems very interesting!

While not official, Tailscale themselves are not opposed to this project.

They don't much contribute to it directly, but they have gone out of their way on a few occasions to avoid breaking it or to make it easier for headscale to implement some things (like the new encryption scheme for communicating with the control server).

I imagine they don't see it as much of a business model threat, since it has no commercial support, requires having somebody your organization run and administer it, it is single tenant, not multi-tenant, so not really suitable for AWS to take and use to outcompete Tailscale proper, etc.

The people most likely to use this are the ones too concerned about security to use the official (Tailscale-hosted hosted) control plane, or people/orgs that simply cannot reasonably afford Tailscale's pricing model. In either case, they were not really customers in the first place.

Re: Tailscale SSH

#132

Post by mfsch »

ludsan wrote: post #121
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…

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?

From [1]: “Like other SSH clients, Tailscale will only use user accounts that already exist on the host, not create new accounts.”

[1]: https://tailscale.com/kb/1193/tailscale-ssh/#ensure-tailscal...

Re: Tailscale SSH

#133

Post by tucif »

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…

A nice next step would be tailscale managing an ssh key that's allowed to do interact with a git(hub) repository. So that I wouldn't have to create multiple keys or setup the same key on different machines and still be able to interact with a repo from all of them.

It'd be really nice just using git transparently and having tailscale take over the git ssh connection and authenticate using taliscale access controls.

At least for personal projects or small teams that'd be quite convenient.

Re: Tailscale SSH

#134

Post by quartzic »

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.

Re: Tailscale SSH

#135

Post by Shared404 »

efunneko wrote: post #130
ben174 wrote: post #41

Earlier quoted context omitted.

Double encryption is twice as effective. I use double ROT-13 for double the security.

I find it more efficient to just use ROT-26

ROT-26? Hasn't that been broken for a few years now?

We all need to be shifting to ROT-52 ASAP.

Re: Tailscale SSH

#136

Post by api »

stavrianos wrote: post #119
api wrote: post #5

Earlier quoted context omitted.

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…

I've seen this conversation before, but I've never been clear on what exactly the consequences of the SSO are. I imagined, it might be that the provider gets an IP address when you connect or something. You're saying they potentially get _access as you_? Am I understanding that correctly?

Anything authenticated with SSO can be accessed by the SSO provider since they're able to approve any authorization, which means they can just log into all your stuff.

So e.g. if you use "log in with Google" on a web site, Google now has access to your account too (if they behaved badly or were compromised).

Spreading SSO auth everywhere gives the SSO provider login access to absolutely everything you have.

Re: Tailscale SSH

#137

Post by NoraCodes »

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 or whatever if that meant I could roll my own SSO, or even just use a cheap-per-user, low-volume provider.

Re: Tailscale SSH

#138

Post by mdeeks »

jaywalk wrote: post #94
mdeeks wrote: post #17

Earlier quoted context omitted.

We just adopted it to consolidate multiple different OpenVPN installations. Why? * The Tailscale clients are dead simple and good quality (but not perfect). OpenVPN clients for mac and iOS are pretty bad. Onboarding OpenVPN users was a large document that generated a lot of questions and support issues. Tailscale onboarding is about two minutes for most users and we had nearly no support requests rolling it out widel…

> Users would login with their Okta creds and a push would silently go to their devices. If they didn't know to check their phone it would just fail to login. How would users not know to check their phone? They had to specifically set up this MFA method.

Because they didn't specifically set it up. That is just how Okta MFA over LDAP works: https://help.okta.com/en-us/Content/Topics/Directory/LDAP-in...

Also people just forget. Some people may only need the VPN once per month and in that time they forget about this weird login flow. They just assume they typed their password wrong or that they lost permissions to the VPN or something.

Re: Tailscale SSH

#139

Post by atonse »

bradfitz wrote: post #127
atonse wrote: post #116

Earlier quoted context omitted.

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/ )

I meant AWS, that page explains it all, thanks!

Re: Tailscale SSH

#140

Post by zachallaun »

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 want to say thanks: This is insanely cool/easy. Combined with the VSCode Remote SSH extension and MagicDNS, it's now insanely easy to work on a project in a remote environment. I was recently reading through a relatively long post on setting up SSH through Tailscale to access a WSL2 environment, and now it's literally as easy as popping open VSCode in any environment that I have Tailscale installed on and accessing `user@my-magic-dns-machine`. Great work!
Post reply on HN