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.
It's not the only solution but something that can be used to at least drastically reduce the amount of noise in logs.
> I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest.
That does sound more efficient but what if someone connecting doesn't have a static IP?