SSH Bastion Best Practices --> Don't use one
Could you share your reasons for not using one in the provided scenario?
SSH Bastion Host Best Practices
31–40 of 91 posts
Re: SSH Bastion Host Best Practices
#32There'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…
> A final recommendation: If you use AWS though, consider using Session Manager instead of SSH and drop the bastion host. You can still connect using the SSH command, using proxy command in OpenSSH, but no public IP or bastion host is required.
Yes, this. Also check out https://github.com/rewindio/aws-connect for a convenient wrapper around SSM to make it easier to use (I'm not the author).
Re: SSH Bastion Host Best Practices
#33Re: SSH Bastion Host Best Practices
#34Can 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.
> misconfigurations of SSH (accidentally letting root log in with no password or something) or a zero day in SSH
these are entirely valid concerns. defense in depth, principal of least privilege. humans make errors.
Re: SSH Bastion Host Best Practices
#35Earlier quoted context omitted.
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;…
Thanks for the response, that clears things up quite a bit. Would you create jump-boxes per environment or do you generally just have 1 with all the different service/env access logic?
It depends. It's more important to have some controls in place than to make super-complicated controls. Again: shell servers you SSH into to SSH out of are kind of an anti-pattern. See elsewhere on the thread about Teleport, which, combined with Tailscale, is I think a pretty good answer to these concerns.
Re: SSH Bastion Host Best Practices
#36Or you could just use strongdm!
Re: SSH Bastion Host Best Practices
#37It recommends:
# Configure idle time logout
ClientAliveInterval
Re: SSH Bastion Host Best Practices
#38A superset of these best practices in the article would be CIS benchmarks. Collectively agreed on by industry leaders and provide extensive resources that span the gamut of cloud, networking, and storage infrastructure. CIS supported technologies: https://www.cisecurity.org/cis-benchmarks CIS Audit AWS infra: https://github.com/toniblyx/prowler Better to be proactive than reactive :^)
If you are on AWS you dont need bastion hosts anymore. Use Session Manager.
I agree in general but there are a handful of edge cases which Google solved better with IAP: SSM can't forward ports to other hosts or any resource other than EC2. It's great for using SSH, SFTP, even tools like Ansible work fine, but if you need to get a port forward to something like RDS, a service in Fargate, etc. you'll need something else.
Re: SSH Bastion Host Best Practices
#39People still use Bastion hosts? I'm trying to grok why they're better than SOCKS5 proxies... Is it because they provide shell access and a larger attack surface? ;-)
Auditing requirements.
Many certifications or legal requirements demand that you log all changes to your systems, including administrative changes.
Bastion host are a well-understood (both by operators and auditors) way to implement that, so it's still a go-to solution.
Re: SSH Bastion Host Best Practices
#40Could 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?
I run an "internal" set of bastion hosts that are gateways into a system that runs telnet. This internal system is able to run SSH, but connections stop around 100 because of OS limits. We need to support 400-500 logins, and that has to be telnet. Everybody connecting has to go through these bastions, including VPN users.
I recently built an nspawn container with tinysshd server, with a .profile that execs telnet to the relevant system on login.
We had previously used an old version of Microfocus Reflections (terminal emulation) with stunnels deployed on all the clients and bastions. That was not containerized, but the server stunnels were set to chroot() on startup.
I recently was forced to support the latest version of Reflections, and since it doesn't support chacha-poly, I also built dropbear SSH server just for them. Reflections is very expensive (~$500/seat), and the best that it supports is aes256-ctr, using Tatu Ylonen's commercial ssh.com (which appears to be abandonware). I really hope we can get rid of that.