[deleted]
SSH Bastion Host Best Practices
11–20 of 91 posts
Re: SSH Bastion Host Best Practices
#12Could someone do me a solid and explain best security practices around bastion hosts and vpn? e.g. - would you still require users connected to the vpn to go through a bastion host? - would you ever run bastion/vpn through the same box? - are there preferred access use cases for each?
Yes, you would still have people connect to the bastion if they're on the VPN; part of the point of a bastion is to have a central place to monitor and control SSH access, which a VPN doesn't really do for you. Additionally, you will inevitably end up with team members who need access to the VPN (to reach staging and test versions of your applications, or to access customer support consoles) but don't get SSH access; a bastion gives you a standard configuration to apply to your fleet to ensure that "on the VPN" doesn't ever equate to "can log into a server".
You should generally do both things.
Wait, I should word that better. You should generally have both sets of controls: network access control with a VPN, and fine-grained, auditable SSH-level access control. I don't love the "Linux shell server" approach to providing those SSH controls.
Re: SSH Bastion Host Best Practices
#13Twice I've seen Bastion Hosts compromised. Both times it practically gave the attackers the highest access. In one case it basically hid where the attack came from (compromised logs and all). In another it let them hijack an admin's password by reading his sudo. IMHE, Bastion Hosts suck. If you are forced to use one, send logs to a safer one-way storage encrypted and put tampering triggers everywhere you can in the B…
Having seen how bastion hosts or “jump boxes” work inside the enterprise I share your view. In practice they are generally not very well protected and are a very attractive target for attackers. It’s better to use a privileged session manager or regular ssh with mfa and ideally some type of identity proofing.
Re: SSH Bastion Host Best Practices
#14Can someone explain to me the benefits of limiting the IPs that can SSH into the bastion? It seems to me the main thing that's protecting against are misconfigurations of SSH (accidentally letting root log in with no password or something) or a zero day in SSH but I'm not convinced by either.
Re: SSH Bastion Host Best Practices
#15Good writup. One thing I would add for bastions if you wanted to harden them would be to disable session multiplexing if you are using MFA/2FA. MaxSessions 1 The default is 10. The plus side of multiplexing is that subsequent connections using the same ssh connection channels are not validated against the authorization mechanisms such as login or 2FA . This reduces friction and speeds up the login process because log…
I wish we could save posts. So this reply is my method… thanks for the write up.
Re: SSH Bastion Host Best Practices
#16very nice writeup - one of the better ones i have seen. you can go a step further and eliminate open inbound port 22 (make the sshd server 'dark' to the network) with open source solutions like this: https://ziti.dev/blog/zitifying-ssh/ disclosure: we build SaaS on top of OpenZiti (the open source) so are opinionated in this domain. and, to be clear, the above is just one layer...other layers of security still apply.
i generally end up liking what teleport is doing and what they are all about... i keep meaning to try their opensource stuff out. does teleport's sshd 'listen' on port 22 and does it need an opening in a firewall?
still, having sshd listen on localhost and not a public ip is pretty cool imo. Ken and I did exactly that on a stream one day https://youtu.be/oSlwZcwZcsU if anyone is interested. The one extra step one could do is to convert sshd to only allow connections from localhost by editing /etc/ssh/sshd_config and set the ListenAddress to only 127.0.0.1
Make those bastions dark!
Re: SSH Bastion Host Best Practices
#17There's a few weird things, but it's mostly okay. Do not trust the firewall on the bastion host, if an attack can get into the bastion host, they can disable the firewall, so it cannot be used to limit egress. It's better than nothing, but consider using a firewall that's managed on a via a separate management network. I do agree that you should only allow SSH from a few known IPs. Limiting the number of users is wei…
> if an attack can get into the bastion host, they can disable the firewall, so it cannot be used to limit egress.
This assumes that the attacker can get unconstrained root access to the system. It's fine to assume that attackers will but it's not as if you can't make that difficult.
Agree with the rest of what you said though.
Re: SSH Bastion Host Best Practices
#18Good writup. One thing I would add for bastions if you wanted to harden them would be to disable session multiplexing if you are using MFA/2FA. MaxSessions 1 The default is 10. The plus side of multiplexing is that subsequent connections using the same ssh connection channels are not validated against the authorization mechanisms such as login or 2FA . This reduces friction and speeds up the login process because log…
Thanks a lot, great hardening considerations.
It would be interesting to hear what you think of Keykloak.
Re: SSH Bastion Host Best Practices
#19SSH Bastion Best Practices --> Don't use one
Re: SSH Bastion Host Best Practices
#20Good writup. One thing I would add for bastions if you wanted to harden them would be to disable session multiplexing if you are using MFA/2FA. MaxSessions 1 The default is 10. The plus side of multiplexing is that subsequent connections using the same ssh connection channels are not validated against the authorization mechanisms such as login or 2FA . This reduces friction and speeds up the login process because log…
I wish we could save posts. So this reply is my method… thanks for the write up.
You can click the timestamp on a post, and then click the "favorite" link, and that'll add the comment to your favorites list (which I think would be https://news.ycombinator.com/favorites?id=whynotminot&commen... for you).