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

291–300 of 311 posts

Re: Tailscale SSH

#291

Post by soraminazuki »

jgeralnik wrote: post #261
soraminazuki wrote: post #214

Earlier quoted context omitted.

Double encryption should help as long as the Tailscale client installed on your own machines is safe. Without double encryption for SSH, Tailscale and your SSO provider can theoretically run commands on your machines without involving malicious client software. But that's not possible if you encrypt your SSH connection with your own keys. Also for Linux, the Tailscale client is fully open source and I obtain the bina…

But that's the thing - even with double encryption tailscale and your SSO can run commands on your machines 1) Run tailscale --ssh on your server 2) A malicious SSO or tailscale add a new machine to your network and update your ACL such that the new machine can connect to your server 3) ssh from the new machine to run code on your server The fact that the connection between the malicious machine and your server is do…

By double encryption, I mean using an SSH server other than "tailscale --ssh". No one except yourself can have SSH access if you disable Tailscale's builtin SSH server, use OpenSSH, and generate your own keys for authentication.

Re: Tailscale SSH

#292

Post by tptacek »

mike_d wrote: post #276
tptacek wrote: post #258

Earlier quoted context omitted.

If you're unwilling to trust Tailscale and their processes, you can't run Tailscale right now. That's obvious. It's part of the premise. The idea that ACLs "mean nothing" is risibly reductive; the ACLs protect our team members from each other and mistakes they might make with their environments. (We don't use Tailscale SSH, and are unlikely ever to; we have a separate source of authentication truth for SSH, and a sep…

They built a footgun into a toaster, and victim blame when people complain that they thought it was just supposed to make toast. Users should not be put into a situation where they need to configure ACLs in anticipation of undocumented features. My hope was that with a little public prodding they would do better in the future. It is a product I want to like, maybe not for what you or I do, but lots of folks out there…

"Victim blame". They announced an opt-in feature.

Re: Tailscale SSH

#293

Post by dekhn »

tptacek wrote: post #205
dekhn wrote: post #191

Earlier quoted context omitted.

Ohhh, this explains why my corporation placed a total firewall block on the Tailscale website. This is a postmortem-worthy incident on Tailscale's part.

If you're not already using Tailscale, with your security or IT teams controlling it, it would be malpractice to allow it on a controlled network. No competent security team allows people to introduce their own VPNs.

The way it works in enterprise that is principal engineers like me are generally given some freedom to explore new technologies responsibly. In my mind, that includes visiting the Tailscale website (which started being blocked by our IT yesterday) to gather information about whether this would be a good alternative technology for our research teams.

Now what I have to do is file a bunch of tickets and take a bunch of meetings to get a block removed from the overall site. Really, what I was trying to do is provide nformation to the Tailscale developers that enterprise already considers their website/product scary enough to do a whole block, and if they want to expand into enterprise, they may want to understand the reasons for that.

Re: Tailscale SSH

#294

Post by dekhn »

tptacek wrote: post #202
dekhn wrote: post #193

Earlier quoted context omitted.

> Tailscale's ACLs are much, much better than iptable rules (for instance: they > have built-in unit testing). Humility helps a lot on the internet- the important thing about iptables is that it runs on millions, possibly billions of machines. Production systems that don't have unit tests but run at scale aren't worse than systems which are newly introduced but have fairly unknown implications.

I'm sorry, I really don't know what you're trying to say here. I'm evaluating a set of engineering tradeoffs and reaching a conclusion about them; I'm not trying to psychoanalyze them.

Im trying to say you're better than iptables because your code has unit tests makes you look arrogant because iptables is a production system that operates successfully at such a large scale that it shows unit tests aren't an accurate measure of quality. I'm saying that when people talk like you did and criticize prod systems, you look arrogant, and humility- using terms like "we believe" rather than "is" help a lot in building user confidence.

Re: Tailscale SSH

#295

Post by mdeeks »

dx034 wrote: post #268
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…

The last point is a good one, I'm not sure how that makes tailscale usable for big orgs. Imagine a company with 10k+ people using it, I guess you'd need to build a lot of own tooling to avoid breaking the whole corporate network because of a mistake in setting an ACL.

I'm somewhat more comfortable with making ACL changes because they have tests I can write in the ACLs themselves, plus I can specifically target users with new ACLs.

I'm more concerned about making any DNS changes at all. Or adding/modifying subnet routers.

Re: Tailscale SSH

#296

Post by ryanisnan »

fladrif wrote: post #186
ryanisnan wrote: post #59

Earlier quoted context omitted.

I'm curious, what's really clunky about SSM? Other than ensuring the pre-requisites are met, and knowing the instance-id, SSM works pretty flawlessly. You can easily write a wrapper that looks up the instance-id from the hostname, if you prefer to use it that way.

Haha I'm not sure if you were being serious, but the workflow you just outlined is the clunky part of SSM. The pre-requisites are getting all the IAM roles and permissions setup (no mean feat), installing the agent, configuring it with keys generated by another user, and getting the connection information back from the aws console. This promises to be a lot easier to setup and authenticate, install tailscale, login.

I think I see what you're saying. Usually though, a lot of that stuff is single-setup. E.g., all OS's that we have deployed have the agent installed and running by default.

Additionally, the instance roles are already pre-configured.

There's almost zero overhead in ensuring SSM gets installed on new instances.

One small benefit over TailScale here, I would think, is that I don't have to rely on another tool to gain shell access. Probably a minor win, if you're running a TailScale deployment. In either case, I'd probably want to go with a single tool just to minimize the attack surface area.

Re: Tailscale SSH

#297

Post by tptacek »

dekhn wrote: post #294
tptacek wrote: post #202

Earlier quoted context omitted.

I'm sorry, I really don't know what you're trying to say here. I'm evaluating a set of engineering tradeoffs and reaching a conclusion about them; I'm not trying to psychoanalyze them.

Im trying to say you're better than iptables because your code has unit tests makes you look arrogant because iptables is a production system that operates successfully at such a large scale that it shows unit tests aren't an accurate measure of quality. I'm saying that when people talk like you did and criticize prod systems, you look arrogant, and humility- using terms like "we believe" rather than "is" help a lot…

Again: these are engineering details, not people; they aren't "arrogant". There is lesser engineering and there is better engineering. As someone who does quite a bit of work with iptables and who has used ACL systems like Tailscale's, I can tell you right off the bat that Tailscale's system is better, and if you have the option of using one or the other --- there are good reasons you might not be able to --- you should use something like Tailscale's, which is identity-aware, testable, dynamic, and simple. Obviously, if you're not using Tailscale at all, this is a moot point, for many reasons, including the fact that if you're not using Tailscale, you don't have to think about how it interacts with your iptables rules.

I'm not making a value judgement about people who need to keep using iptables. I might be making a value judgement about people who demand that everyone else keep using iptables.

Re: Tailscale SSH

#298

Post by dekhn »

tptacek wrote: post #297
dekhn wrote: post #294

Earlier quoted context omitted.

Im trying to say you're better than iptables because your code has unit tests makes you look arrogant because iptables is a production system that operates successfully at such a large scale that it shows unit tests aren't an accurate measure of quality. I'm saying that when people talk like you did and criticize prod systems, you look arrogant, and humility- using terms like "we believe" rather than "is" help a lot…

Again: these are engineering details, not people; they aren't "arrogant". There is lesser engineering and there is better engineering. As someone who does quite a bit of work with iptables and who has used ACL systems like Tailscale's, I can tell you right off the bat that Tailscale's system is better, and if you have the option of using one or the other --- there are good reasons you might not be able to --- you sho…

OK, you're free to completely ignore my advice that you look arrogant, and that it might affect the uptake of your product from the very people who could lead the way to increased adoption.

But, my point still stands. You can't simply assert your system is better, it has to be proven at a scale similar to iptables before you can say that.

Re: Tailscale SSH

#299

Post by alex_dev »

viraptor wrote: post #245
alex_dev wrote: post #184

I've been having trouble adopting Tailscale. As so many others say, relying on another identity provider is unfortunate - I, too, worry what happens when Google decides to lock me out because some algorithm decided my account is fishy. The biggest blocker has been the issues with the Android client. I'm either hitting https://github.com/tailscale/tailscale/issues/915 or https://github.com/tailscale/tailscale/issues/4…

Are you after the LE part specifically? If not, I'm quite happy with mdns and the seems to be a unicast version available too: https://www.zerotier.com/2021/05/06/zeronsd-unicast-dns-reso... For public domains, I've got a quick script which mirrors what appears in avahi to route53, so that's one way to deal with certs.

I appreciate that Tailscale runs the DNS server so it's one less thing for me to manage. Similarly, the built-in LE is just icing on the cake as it's one less thing to think about. Once https://github.com/hassio-addons/addon-tailscale/pull/89 is merged, running Home Assistant on a VPN with a LE certificate, would be such a quick setup for anyone.

Indeed, you can do all that yourself as you point out. Just last night I manually created a public domain to point to a ZeroTier address and ran the Lets Encrypt addon in Home Assistant to generate a certificate via the DNS challenge. Didn't take long, but there were many steps involved (creating a Google Cloud service account and configuring everything).

Re: Tailscale SSH

#300

Post by tptacek »

dekhn wrote: post #298
tptacek wrote: post #297

Earlier quoted context omitted.

Again: these are engineering details, not people; they aren't "arrogant". There is lesser engineering and there is better engineering. As someone who does quite a bit of work with iptables and who has used ACL systems like Tailscale's, I can tell you right off the bat that Tailscale's system is better, and if you have the option of using one or the other --- there are good reasons you might not be able to --- you sho…

OK, you're free to completely ignore my advice that you look arrogant, and that it might affect the uptake of your product from the very people who could lead the way to increased adoption. But, my point still stands. You can't simply assert your system is better, it has to be proven at a scale similar to iptables before you can say that.

It's not my product.

(I'm not impartial about Tailscale, but I don't work there).

Post reply on HN