Security through obscurity is not the solution, though. Sooner or later someone does a port scan and finds that port. I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest.
Edit: I didn't mean changing the port is a bad thing. You can and should do it, and it will help a bit - just that it shouldn't be the only thing to rely on for your SSH security.
> Security through obscurity is not the solution, though
Security is about layers. Nothing is foolproof. It's about implementing layers of controls to reduce your attack surface to an acceptable level, with the trade-off that many controls increase the complexity of your setup or compromises the convenience for your users.
For example, for SSH, this probably includes
* changing the default port
* enforcing SSH key authentication
* enforcing passwords on SSH keys
* implementing fail2ban
* installing jump hosts for internal machines
* implementing a VPN rather than external facing hosts (and with that comes all the additional layers for the VPN)
I think you mean the server can't enforce ssh key encryption/passphrase protection (next point down)?
And 2 or even 3 factor should maybe be on the list (key+pw, key+totp, key+pw+totp).
For keys, it's in theory possible to ease management with using ssh certificates and a CA - anyone know of a convenient way to manage totp secrets across multiple servers and users?
It is part of it in this case. You've just eliminated most of non-targeted scanners. Your log is much more readable and what is left will probably be dedicated attackers.
This might help in forensic investigation afterwards. Less crap to wade through.
Security through obscurity is definitely not the solution, but I'll tell you that I've been running SSH on a non-WKS port since the mid '90s as a standard practice, and the number of attackers attempting to connect there seems to have been 0, even during the "lets try all sorts of common logins" crazy days.
Let's face it, the sort of person who moves SSH to a different port probably is also the sort to disable password logins. So the effectiveness of searching for their SSH daemon is probably pretty low.
I don't consider it better, I consider it an additional barrier to attacking the production systems. Everyone authorised to access the servers (prod or non-prod) has to have an SSH key, protected by passphrase, to access the servers. This in addition to the requirement that they are either in the office or logged into the VPN means that any attacks have to come via that funnel.
Attackers who are not specifically targeting the company are unlikely to bother or to have the skills necessary. It's too much hassle and attackers scanning around for a random victim don't even see that the ports are open since they're behind a firewall.
So, it's not about this protocol vs that protocol for authentication, there certainly shouldn't be open access just because you got past the VPN auth, it's about layering your security to shrink the surface area and make it simpler to identify the entry points.
Alright, so you use VPN as your bastion server - effectively.
I guess I never considered the need to SSH directly to machines. I completely agree security is defense in depth through layers.
I brought up the question since I was just at a client site that required VPN to ssh to their single bastion (jumpbox) ssh host, which then you used to further ssh to production machines. The VPN layer in that architecture seems rather silly - just lock down your bastion server (SSH) in the same way!
> Alright, so you use VPN as your bastion server - effectively.
No, I apologise if I wasn't clear, the bastion server is accessible only after you are either also within the office or logged in via the VPN. It's an additional hoop to jump through, not a replacement. The point being, the bastion server is locked down in addition to the requirement to be logged into the VPN or being physically located at the office. IP locking is not a replacement, it's a sensible addition. I think perhaps this is why you think it's silly; you're misunderstanding that it's not a different layer it's an additional one.
> what if someone connecting doesn't have a static IP?
Whitelist your ISPs subnet then, at the very least - there's much lower probability of an attacker coming from just your ISPs, and, of course, use other measures too - I didn't mean that to be the only solution for the problem.
Edit: I didn't mean changing the port is a bad thing. You can and should do it, and it will help a bit - just that it shouldn't be the only thing to rely on for your SSH security.