5 ms·
SSH is rarely a public service. What's the motivation for making it so public?
by tquai 14y ago
SSH is rarely a public service. What's the motivation for making it so public?
- skatepark 14y agoLaziness. It, like all other non-public services, should be hidden behind a VPN that reduces the attack surface to the absolute minimum. Ideally you should use something like OpenVPN's PSK HMAC support, which reduces the total code surface visible to external attackers to only the HMAC validation code paths. If the HMAC does not validate, OpenVPN doesn't even try to interpret the contents of the packet (including authentication/authorization). Couple that with setuid+chroot of the OpenVPN server, and you've further reduced your attack surface. If you're actually serious about running a larger secure infrastructure, you also shouldn't be using passwords at all. Your servers shouldn't support them, and password authentication should be disabled in the SSHd configuration. You should use SSH keys. You also shouldn't be sending plaintext passwords to random servers, and you should prefer alternatives such as x509 auth to the VPN, coupled with SSH key auth (or kerberos) to the actual servers. If you can't use x509/pke/kerberos for VPN/server authentication, then you should restrict the surface of the machines that handle plaintext passwords to just the VPN and web SSO hosts, rather than exposing user passwords to every single server in your deployment. The goal is to compartmentalize access to sensitive data, such that you 1) reduce the overall attack surface (including by reducing the visibility of centralized hosts managing sensitive data) and 2) reduce the damage that can be done by compromising a hosts, especially hosts that are visible via the internet (and similarly in a large enterprise, visible company-wide).
- lmm 14y agoThe whole point of ssh is to be able to log into one's machine from elsewhere on the wide internet. I find it's precisely when I'm somewhere public (i.e. coffee shop or public transport wifi) that I want access to my home machine - on my work machine (i.e. in the office) anything I need is already there. If you don't need it to be publicly accessible, why would you be running sshd at all?
- tquai 14y agoBefore I can respond to that, I think there's a misunderstanding about what "public service" means. HTTP is a public service: you open it up to the world, and want anyone to be able to connect to it. It is intended and hoped that as many people use it as possible. If your website is slashdotted, then that's GREAT! In contrast, I don't want 100000 people to try logging in over SSH to my private server. To put it another way, SSH is only a public service in the cases of: * CVS over SSH * rsync over SSH * Commercial SSH tunnels Logging into my authoritative nameserver over SSH, however, is not a public service. And since it's not a public service -- that is, intended for the public -- I don't treat it like one.
- lmm 14y agoIf you're trying to tell the rest of us something you're going to have to be more concrete. So you "don't treat it like a public service". Great. What does that actually mean? ("I don't make it accessible on a public port from the public internet" was the most obvious technical interpretation, but it sounds like you didn't mean that)
- snowwrestler 14y agoYou could block all but whitelisted IPs at your firewall, then get a VPN and add the endpoint IP to your whitelist. This way ssh (and anything else you don't want the public to access) is protected from random drive-bys, but you can still get to it from pretty much anywhere. VPNs are a good idea in general if you are doing anything from a public access point that involves logging in.
- lmm 14y agoAs far as I can tell, SSH is my VPN. What would I get from a VPN that I don't get with SSH? And whatever VPN solution I used would still have to offer me a way to log in to the VPN from random public IPs, on a standardized port (or via some standardized discovery mechanism) - so I don't see how it could possibly be any more secure.
- 14y ago