3 ms·
I don't like this approach very much because it's much more complicated than it would have to be. Security is about layers, and this is essentially one layer th
by yabones 6y ago
I don't like this approach very much because it's much more complicated than it would have to be. Security is about layers, and this is essentially one layer that acts as the sole guardian for sshd.
The way that I like to do this is to have a common 'entry point' for all my cloud systems. Instead of whitelisting IPs on every VPS or cluster I build, I just add them to the ACL on my management server. All the other systems only allow SSH connections in from the bastion server. In practice, it works like this:
* Add IP to the whitelist file in my change control
* Run the Terraform script to update the DigitalOcean ACL
* Start an SSH agent locally and add the key for the bastion, as well as the key for the destination
* Connect to the destination server by using ProxyJump
So, connecting to a box would always route through my bastion system first, like this:
ssh -J mgmt.mydomain.net cool-app-server.mydomain.net
I've been doing this for a couple years, and it works great. I practically never have attempted login attempts on my systems. And, since I use an ssh agent to forward the keys through the bastion without ever actually storing them, a compromise of that system doesn't really give the attacker anything other than access to port 22 on a bunch of systems that they wouldn't know where to find. Only the most sophisticated attack (https://xkcd.com/538/ https://xkcd.com/538/) would lead to a real compromise.
- jiggawatts 6y agoI love that XKCD, but this particular cartoon gives a false impression in order to be humorous. (You can't fault a comic artist for this of course.) In my experience the #1 real attack vector is the shouty middle manager demanding that: "Everything be opened right now because some outsourced admin says he needed it". It's nigh impossible to use technological measures to defeat a CxO or a department head.