4 ms·
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
by dsr_ 4y ago
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.
- throwaway894345 4y agoI'm not following. How does double encryption help to avoid a password compromise if everything is authed with tailscale in the first place?
- xgbi 4y agoSomebody listening on local connections can sniff your password.
- throwaway894345 4y agoHow 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?
- 8organicbits 4y agoI 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.
- throwaway894345 4y agoIsn'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).