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

21–30 of 311 posts

Re: Tailscale SSH

#21

Post by api »

dsr_ wrote: post #19
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…

This is correct. One answer is to have many, many SSO/IDP systems -- and for anyone technical enough to set up a homelab to be able to be their own IDP.

A lot of people don't let you bring your own IDP. They offer a few choices: Google, Microsoft, Okta, etc.

I can foresee this eventually being a revenue stream for a lot of companies where they charge payola to be listed as an IAM provider, sort of like the browser CA inclusion or browser default search engine list rackets.

Re: Tailscale SSH

#22

Post by sirtaj »

dsr_ wrote: post #19
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…

This is correct. One answer is to have many, many SSO/IDP systems -- and for anyone technical enough to set up a homelab to be able to be their own IDP.

I'd love to know of well supported, secure IDP software to use for this. I'm afraid of OpenLDAP due to its long history of security issues. What are the open source alternatives that are both minimal in configuration and solid enough to be exposed to the internet if necessary?

Re: Tailscale SSH

#23

Post by loriverkutya »

pphysch wrote: post #11

> (SSH certificates are better, but have you tried running your own enterprise CA?) For a small business, what is so hard about keeping a file (CA private key) secure and changing it when required?

Changing it when it is required.

Re: Tailscale SSH

#24

Post by RL_Quine »

api wrote: post #5
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.

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 feel like people should at least understand what they are doing when they choose to delegate all their authentication to Google.

I think this is my biggest concern, it's really scary to have Google Auth as literally the only barrier between no access and complete production access. I understand that a lot of the time Google accounts hold the literal keys to the kingdom anyway (customer data, internal company data, maybe source trees), but SSH was one of the last frontiers remaining.

Re: Tailscale SSH

#25

Post by throwaway894345 »

dsr_ wrote: post #18
riobard wrote: post #14

I'll have to ask this since it's bothering me for quite a while… If I connect to a server via WireGuard, would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? It's kinda pointless to double encrypt.

Yes and no. You shouldn't have rsh on your system at all -- there's a case for telnet to test connections (though netcat is better), but there's no case for rsh. ssh used to allow setting cipher=none, but that's not available anymore. Think of it this way: you're paying the small overhead of double encryption, but you're gaining not fatfingering your way to a password compromise.

I'm not following. How does double encryption help to avoid a password compromise if everything is authed with tailscale in the first place?

Re: Tailscale SSH

#26

Post by mdeeks »

RL_Quine wrote: post #15
tlrobinson wrote: post #7

Earlier quoted context omitted.

> goofy login flow Can you be more specific about your complaints?

I edited the original to contain more detail as I posted it but it seems to have been lost somehow. The login flow for Tailscale is weird due to the need to accommodate things like a headless server being added, when combined with their use of SSO as the only method of authentication things get confused very easily. When I add a new server I get given a URL that looks like https://login.tailscale.com/a/c44a243b to vi…

SSO is not the only method of authenticating things. They have auth keys specifically for the purpose of authing headless servers. e.g. sudo tailscale up --authkey tskey-abcdef1432341818

You can also apply an ACL tag to it so that it is no longer authorized as the user and instead takes on the permissions of the tag.

In our deployments we have the headless servers pull the tagged auth key from secrets manager on boot and then just `tailscale up --authkey `.

I agree the default login flow is usually not what you want for headless servers. It sort of leads you down the wrong path.

Re: Tailscale SSH

#27

Post by dimitar »

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.

Hmm AFAIK you don't need a bastion to use SSM agent - it even allows you access through the browser. I think you meant EC2 Instance Connect which manages temporary SSH keys.

Re: Tailscale SSH

#28

Post by yebyen »

mdeeks wrote: post #17
ratg13 wrote: post #2

Is anyone using tailscale on an organizational level? I'm curious to hear about some of the use cases, and whether some companies and organizations are attempting to adopt this instead of traditional VPN.

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. Alternatively you can paste your TOTP code after your password. Yes, really.

This sounds exactly like my Cisco (anyconnect) VPN experience from a previous job/life, both before and after Okta was introduced... we think it don't be like it is, but it do.

Re: Tailscale SSH

#29

Post by throwaway894345 »

bradfitz wrote: post #16
riobard wrote: post #14

I'll have to ask this since it's bothering me for quite a while… If I connect to a server via WireGuard, would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? It's kinda pointless to double encrypt.

Yeah, but e.g. no rsh (or telnet!) on macOS. It's likewise a bit silly that we had to add TLS support to Tailscale: https://tailscale.com/blog/tls-certs/ But we want to interoperate well with the clients people already have (browsers, their system ssh client, etc...)

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

Re: Tailscale SSH

#30

Post by lloeki »

pphysch wrote: post #11

> (SSH certificates are better, but have you tried running your own enterprise CA?) For a small business, what is so hard about keeping a file (CA private key) secure and changing it when required?

> For a small business, what is so hard about keeping a file (CA private key) secure and changing it when required?

For a small business? Well, keeping a file secure and changing it when required ^^'

I mean, it's not out of this world hard to generate your private CA but there are a thousand footguns, the experience isn't exactly friendly, and it's Yet Another Thing To Do And Keep Track Off, i.e even if there's someone who has the technical chops, they may not have the bandwidth, and also, lottery factor. Let alone keeping it properly secure. There's a whole framework/procedure to create to set that up properly.

(been there done that, I was exactly in the situation above)

Post reply on HN