Hacker News Reader

Comment by dsr_ | Hacker News Reader

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.

View on HN

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.

Isn't this true of SSH as well? What's stopping someone from letting sshd listen on 0.0.0.0 with password auth? Anyway, I would expect that whether you're using ssh or rsh/telnet/etc that you're not configuring it for password auth, but rather using tailscale authentication. Specifically, I would expect (perhaps naively) that tailscaled handles the ssh/telnet/rsh/whatever connections rather than passing them off to another process (sshd, telnetd, etc) and thus allowing it to handle the authentication and daemon configuration (e.g., what address it listens on).

Somebody listening on local connections can sniff your password.

How does that work? First of all, I would expect that rsh-over-tailscale doesn't use password authentication, and secondly can a local user sniff traffic before it hits tailscaled?

Reply on news.ycombinator.com