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

31–40 of 311 posts

Re: Tailscale SSH

#31

Post by [deleted] »

api wrote: post #21
dsr_ wrote: post #19

Earlier quoted context omitted.

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.

[deleted]

Re: Tailscale SSH

#32

Post by runjake »

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

FWIW for those reading (I figure Brad already knows):

    echo "alias telnet=nc -v" >> ~/.zshrc && source ~/.zshrc

Re: Tailscale SSH

#33

Post by runjake »

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.

    > would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`?
No, because ssh has evolved to be so much more than "rsh with encryption".

Re: Tailscale SSH

#34

Post by 8organicbits »

edf13 wrote: post #8

Never login as root… even over secured links!

I think in this context, I'd worry about attributing any actions taken on the root account back to a named user. I suppose tailscale keeps an auth log (anyone know details?) so you likely could determine "root"="alice" by looking across different log files. Attributing privileged commands to an employee is critical for security.

In other contexts you want to avoid shared root accounts, as you'd want to block access for former employees, but you don't want to rotate credentials every time. SSO for tailscale makes that easier.

Re: Tailscale SSH

#35

Post by apenwarr »

runjake wrote: post #32
bradfitz wrote: post #16

Earlier quoted context omitted.

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

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.

Re: Tailscale SSH

#37

Post by 8organicbits »

throwaway894345 wrote: post #25
dsr_ wrote: post #18

Earlier quoted context omitted.

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?

I suspect they mean that if you have rsh installed for tailscale you need to be very careful with how you run it. If you accidentally let rsh listen on 0.0.0.0 and don't firewall it then you've given attackers a way to guess passwords.

Forgetting to firewall services or accidentally exposing services to the internet is pretty common. ssh is more hardened than rsh, especially with key based auth, so the risk is lower.

Re: Tailscale SSH

#38

Post by jsmith45 »

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…

There is a reason why many companies (especially those with few developers, artists etc, so most people run Windows), go with Azure AD as their SSO solution. Then they are only depending on Microsoft not being compromised. But they are already relying on other parts of Microsoft not being compromised, so it feels like less of a risk to those companies.

Re: Tailscale SSH

#39

Post by oefrha »

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

From the blog post on TLS support:

> However, if your service doesn’t have a valid TLS certificate, despite the fact that your connection is encrypted using Tailscale, your browser will warn you that the connection is not secure (it’s doing the right thing—it doesn’t know about Tailscale!). So, to avoid confusing your users, you might want to provision a TLS certificate to validate your internal services.

Browser warnings and user confusion aren’t the only consequence of not using HTTPS. The more concrete impact is that you lose access to a large and growing number of web APIs that are restricted to secure contexts.

https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

Post reply on HN