Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH Bastion Host Best Practices

goteleport.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: SSH Bastion Host Best Practices

#81

Post by e12e »

tptacek wrote: post #9

I think this article has come up before? Either way, it's a quirky thing for Gravitational to post, since their flagship project --- Teleport --- basically eliminates bastion servers altogether (you might think of it as an API-controlled self-contained bastion server). Teleport is free, and worth checking out: it solves a bunch of SSH management problems, not just controlling access, but also linking SSH access to SS…

We've been experimenting a bit with tailscale and ssh access - and I'm not 100% convinced there's a great way to guarantee continued access - if you bind sshd to the tailscale vpn ip, an update that restarts ssh and tailscale could result in sshd not being able to bind the expected IP - leading to ssh being down. I think this is mostly due to sshd listen directive being somewhat limited.

Re: SSH Bastion Host Best Practices

#82

Post by kubanczyk »

rorski wrote: post #32
mrweasel wrote: post #7

There'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).

Nitpick: the aws-connect quickstart suggests to install it through bpkg. But it turns out that bpkg does not have any "uninstall" or anything similar. I ended up doing just:

    rm ~/.local/bin/aws-connect

Re: SSH Bastion Host Best Practices

#83

Post by ludwigvan »

tptacek wrote: post #9

I think this article has come up before? Either way, it's a quirky thing for Gravitational to post, since their flagship project --- Teleport --- basically eliminates bastion servers altogether (you might think of it as an API-controlled self-contained bastion server). Teleport is free, and worth checking out: it solves a bunch of SSH management problems, not just controlling access, but also linking SSH access to SS…

> Either way, it's a quirky thing for Gravitational to post, since their flagship project --- Teleport --- basically eliminates bastion servers altogether

Not quirky at all. Probably the aim is to inform the reader of the myriad things to do to keep bastion server secure, and then suggest there is an easier alternative. :)

Re: SSH Bastion Host Best Practices

#84

Post by wmfiv »

mrweasel wrote: post #76
geunsgucndb wrote: post #66

Earlier quoted context omitted.

If you use SSM instead of a bastion host, how do you tunnel traffic to internal services that are not exposed to the internet?

I haven't actually tried it, but you can use SSM in your ssh config as a ProxyCommand. As I understand it, that will allow you to just use the ssh command as normal, with all the normal ssh abilities to do tunneling and port forwarding.

Yes that's right. You can use SSM to port forward. Here's an example of the SSH configuration.

host i-* mi-*

    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession"

Re: SSH Bastion Host Best Practices

#85

Post by Spivak »

nonameiguess wrote: post #46
staticassertion wrote: post #17

Earlier quoted context omitted.

> 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.

At least in the DoD and IC environments I've worked in that had bastion hosts, the bastion host was severely locked down: - Shell compiled without built-ins - No coreutils - No sudo - Root account disabled - Read-only root filesystem - No user home directories - Destroyed and rebuilt from template every X hours on some maintenance schedule Effectively, all you can do is ssh in, ssh out, and forward ports. It might be…

This setup should be easier than it currently is. Any bastion host that’s used for more than jumping is asking for trouble.

Re: SSH Bastion Host Best Practices

#86

Post by justinludwig »

joshgachnang wrote: post #14

Can 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.

Also adds defense-in-depth against stolen credentials -- it means an attacker can't just exfiltrate stolen SSH credentials to use sometime later from somewhere else on the Internet (or sell them / pass them along to a different specialist) -- the attacker either has to use them in-place, or break into some other machine that's also on the allow-list.

Re: SSH Bastion Host Best Practices

#87

Post by antb123 »

e12e wrote: post #81
tptacek wrote: post #9

I think this article has come up before? Either way, it's a quirky thing for Gravitational to post, since their flagship project --- Teleport --- basically eliminates bastion servers altogether (you might think of it as an API-controlled self-contained bastion server). Teleport is free, and worth checking out: it solves a bunch of SSH management problems, not just controlling access, but also linking SSH access to SS…

We've been experimenting a bit with tailscale and ssh access - and I'm not 100% convinced there's a great way to guarantee continued access - if you bind sshd to the tailscale vpn ip, an update that restarts ssh and tailscale could result in sshd not being able to bind the expected IP - leading to ssh being down. I think this is mostly due to sshd listen directive being somewhat limited.

I am doing a pilot of the same thing.

so far I am mostly using tailscale + firewall. Using a firewall directly on the host as you mentioned seemed a bit dangerous - although we are trying it on a few servers. For now cloud provider firewall + tailscale.

Re: SSH Bastion Host Best Practices

#88

Post by cbsmith »

perlgeek wrote: post #39
cbsmith wrote: post #8

People 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.

That would make a lot of sense if SOCKS5 proxies weren't commonly used for auditing and provide much more transparency about what operations someone is doing on the internal systems.

Re: SSH Bastion Host Best Practices

#89

Post by cbsmith »

noinsight wrote: post #55
cbsmith wrote: post #8

People 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? ;-)

So how do you implement MFA in your SOCKS5 proxy?

Auth method flag for SOCKS5 has 0x08 is for MFA.
Post reply on HN