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

171–180 of 311 posts

Re: Tailscale SSH

#171

Post by raggi »

dangerlibrary wrote: post #48
throwaway894345 wrote: post #29

Earlier quoted context omitted.

Is there an option to avoid double encryption on systems that do have e.g. rsh?

I might be misunderstanding the question but ... just use rsh?

Around the time I joined Tailscale, actually just before, I had a look at rsh with an eye in this direction.

The problem is that rsh is very stale and unmaintained - even those versions that have had releases in recent years (e.g. GNU Inetutils) are very old inside - even if they've kept up with patches, they have not kept up with features e.g. modern user session construction.

It also turns out that ssh the client, much more so than ssh the protocol, is really a key integration point and API that users end up needing. It has a broad feature set that turns up in use cases all over, many of which rsh does not handle.

Re: Tailscale SSH

#172

Post by structural »

titanomachy wrote: post #150
quartzic wrote: post #134

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?

It's more than just a work/personal split. Even at work, having "development" and "production" tailnets so that things like testing complex ACLs, inhouse apps that use tailscale via its API, etc. are possible without having everyone on the devops team create an unmanaged/non-company email so they can create their own development tailnet, and then deploy a bunch of company IP using this rogue account.

It's a pain point.

Re: Tailscale SSH

#173

Post by bhawks »

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…

Any interest in adding mosh like features (https://mosh.org/)?

Low latency typing, session resumption etc

Re: Tailscale SSH

#174

Post by structural »

throwaway894345 wrote: post #125
dangerlibrary wrote: post #48

Earlier quoted context omitted.

I might be misunderstanding the question but ... just use rsh?

I think for the same reasons I wouldn't "just use ssh" over tailscale--I don't want to have to manage an sshd that doesn't require key or password auth but listens over tailscale (and nothing else!). Basically, what I want is for tailscaled to be my rshd (appropriately configured for connections over tailscale network only, etc) or in other words to avoid double-encryption (it's not the end of the world, but ideally…

Double (or more) encryption ends up happening a lot in larger networks not for technical reasons but for policy ones.

This is unsurprising, because it is used for different purposes in different layers of the stack. It is not at all a black and white state of "encrypted" vs. "not encrypted".

For example, in one organiztion I've worked with, Wireguard (generally, including Tailscale) is approved for restricting connections only to authorized network devices/users and that data maintains integrity in transit, but is not approved for protecting the confidentiality of sensitive information. Connections which access specific resources are required to be encrypted at the application level using a mechanism which has been approved for that information type (given a specific threat model).

So you could transmit very small amounts of data over TCP/IP, over a Tailscale network, using a set of pre-shared, one-time pads. And you might actually want to do this! It's really not ridiculous, but you do need to assess whether you really do have a threat model that needs it.

Re: Tailscale SSH

#175

Post by justinsaccount »

Syzygies wrote: post #167
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 have Tailscale on all my Macs. I use MacOS default SSH between my machines, but only via the Tailscale interface. Nevertheless, I had to open SSH on each machine, and it's a nightmare to close up the firewall so only Tailscale gets through. You'd think this was the whole point of Tailscale; there should be a one click lock to restrict to Tailscale. But the Tailscale documentation is wanting. I actually paid for a c…

You don't really need a firewall to do that. putting

  ListenAddress 100.x.x.x
where 100.x.x.x is the address on the tailnet, into your sshd_config would do what you want. Unfortunately you can't specify an interface, but if you have any sort of automation in place this is easy enough to template in.

Re: Tailscale SSH

#177

Post by dave_universetf »

birdyrooster wrote: post #91
mountainriver wrote: post #64

Tailscale is my absolute dream networking solution, I would go as far as to say it will ultimately change how we develop applications in the future

If the auth flow was as good as Touch ID and no window switching, yeah it would be acceptable but this flow would give me a headache with all the flashing.

TouchID and related are on the list. Hooking into the existing auth flow was the easiest to get this out the door (and more desirable for some companies who want the audit event in their SSO stack, arguably), vs. figuring out when to nudge people to enroll physical factors and so forth. But I definitely also want "tap your security key please" as an option :)

Re: Tailscale SSH

#178

Post by kortilla »

bradfitz wrote: post #165
mike_d wrote: post #163

Earlier quoted context omitted.

How was the decision made to roll this functionality out before announcing it to customers (we found it during a previous security audit)? While it might seem logical in your mind to bolt on extra features and add value, your customers evaluate risk based on functionality of the software they are approving. Customer buys a VPN solution, magically gets remote access that bypasses firewalls. Can we trust Tailscale to n…

There are two things have have to be enabled to turn it on: (1) a target server needs to run "tailscale up --ssh" to enable the SSH server (2) your Tailscale ACLs have to permit it. Our default, if you've never set your ACLs (as is usually the case for personal users), is that you're allowed to SSH to your own untagged devices only. For an org that's already using ACLs, you won't have any SSH rules defined and thus n…

Concern more around what looks like an ssh backdoor showing up unannounced. How would they know the subtleties of what it takes to enable it when it wasn’t announced yet?

Re: Tailscale SSH

#179

Post by andymac4182 »

Sytten wrote: post #10

This seems like the perfect complement to replace the SSM Agent / bastion instance currently used to access AWS VPC (it is super clunky to use). This should allow an easier time to do reverse tunnelling to databases without having to manage SSH keys.

That feature was recently added to SSM https://aws.amazon.com/about-aws/whats-new/2022/05/aws-syste...

Using something like gossm which I just put a PR in for this feature also makes this easier https://github.com/gjbae1212/gossm/pull/54

Re: Tailscale SSH

#180

Post by dave_universetf »

atonse wrote: post #120

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

SFTP is a sub-protocol of SSH (technically a "subsystem" in the RFC-speak), which implements features similar to "legacy" FTP.

Anyway, our ssh server knows about sftp, so `sftp ` should just work.

Post reply on HN