Live data from Hacker News

Tailscale SSH

tailscale.com

141–150 of 311 posts

Re: Tailscale SSH

#141
post #102
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…

curious what 'dead simple' means re: clients. Do your users still need to login like openvpn, or is it always on?

It's a small icon in the top bar on macOS. You click login, it opens your browser, you Google/Okta auth in your browser using any factor you want (push, totp, yubikey), and you're done. Login literally takes seconds and there is little chance for confusion.

Re: Tailscale SSH

#142
post #98

Earlier quoted context omitted.

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.

You have to explicitly enable Tailscale SSH, both on the host and in the ACLs that allow users to use the feature. Tailscale's ACLs are much, much better than iptable rules (for instance: they have built-in unit testing).

(I'm not impartial about Tailscale.)

Re: Tailscale SSH

#143
post #133

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. A…

Depending on which part of those things you find painful, you might want to look into ssh certificates? They're pretty easy to work with, much easier than most kinds of certificate systems.

Re: Tailscale SSH

#144

I'm very interested in Tailscale for both personal and business use-cases, but I'm rather put off by the stark centralization of offered identity providers: Microsoft, Github (Microsoft), Google, okta (?). What are the chances that Tailscale would offer authentication using decentralized/self-hosted identity providers like Ory ( https://www.ory.sh/ )?

There is also the self-hostable Headscale implementation.

Note before anyone gets too excited: doesn't work on iOS, and you have to sideload an app on Android, if you want to use it from a phone.

These aren't problems for everyone but I think they should be front and center when suggesting it.

Re: Tailscale SSH

#145
post #32

Earlier quoted context omitted.

FWIW for those reading (I figure Brad already knows): echo "alias telnet=nc -v" >> ~/.zshrc && source ~/.zshrc

Alas, the real “telnet” protocol has considerably more fanciness than nc. It’s just that the telnet cli command degrades into a simple line-oriented mode if it doesn’t see the telnetd init sequence.

For example window size negotiation

Re: Tailscale SSH

#146
post #136

Earlier quoted context omitted.

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.

wait so if i authenticate tailscale using google and enable tailscale ssh's google can just log into any of my tailscale ssh servers?

Re: Tailscale SSH

#147
post #62

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…

This is neat. I've used Cloudflare's Zero-Trust SSH, but I've been frustrated that it interacts poorly with sftp and scp because of the client-side changes that they make to ~/.ssh/config Does tailscale have the same issue?

For what it's worth I encountered the same issue and came up with a solution:

https://github.com/cloudflare/cloudflared/issues/574

Cloudflare have ignored the github issue (which includes a solution) but at least 3 other people seem to have found my solution helpful.

Re: Tailscale SSH

#148
post #77
post #71

Earlier quoted context omitted.

> (...) 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.

> [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 interfaces...

Re: Tailscale SSH

#149
post #120

Another question, can this be used to create SSO-enabled SFTP? Isn't SFTP just ftp over SSH?

> Isn't SFTP just ftp over SSH?

FTP is a wholly different protocol, that has aged rather poorly. You might be thinking of FTPS, which is FTP with TLS. SFTP is its own thing and is actually decent/sane.

> can this be used to create SSO-enabled SFTP?

From another reply somewhere else in the comments, apparently yes.

Re: Tailscale SSH

#150

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.

Do you use the same Google/Github/Microsoft/whatever account for both work and personal stuff?
Post reply on HN