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

61–70 of 91 posts

Re: SSH Bastion Host Best Practices

#61

Post by killingtime74 »

s-xyz wrote: post #52

Newbie here to VPCs, bastion hosts, VPEs, etc. After spent a while on the topic, some questions arise that you might find redundant or can answer. I am wondering why we need to configure this many steps as outlined in the article, and in general. What is the point of Teleport in the first place? Why is there no managed service that takes care of all of that, with me focusing on just deploying an app and running it in…

This is the aws managed service (it’s free). https://docs.aws.amazon.com/systems-manager/latest/userguide...

Re: SSH Bastion Host Best Practices

#63

Post by suifbwish »

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…

Realistically what is the risk of ssh being exposed if white listing is done, 2 factor auth and key auth are used? I suppose someone using a zero day, spoofing or from a whitelisted IP may successfully exploit but really?

Re: SSH Bastion Host Best Practices

#64

Post by darkhelmet »

nolta wrote: post #37

It recommends: # Configure idle time logout ClientAliveInterval but i don't think this is correct. AFAICT, this is a keep-alive mechanism, not a timeout. I don't think openssh has an option to kill idle sessions.

You are correct. This is widely copy/pasted bad advice and does the exact opposite of what the comment says.

It is not an idle timeout logout at all. Instead, it causes sshd to periodically send probes to the client. This has a couple of effects, most notably keeping tcp sessions "active" and frequently exchanging packets (this can be useful to keep connections through statefull firewalls alive if you are genuinely idle), and to rapidly detect and disconnect a client that has actually gone away.

I think the origin of this incorrect description is the CIS documents. They have the exact same gross mistake in them.

I think the ClientAlive probes are useful and should be on, but it's definitely not an "idle logout" as claimed.

Re: SSH Bastion Host Best Practices

#66

Post by geunsgucndb »

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…

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

Re: SSH Bastion Host Best Practices

#67

Post by mlyle »

sigjuice wrote: post #59
vngzs wrote: post #22

Earlier quoted context omitted.

From a defense standpoint, one should consider "shell on a box" to usually mean attackers can get root on a box. If they can get persistence, they can wait for a kernel CVE to abuse. Now, if you're just using a bastion as a jump host, you don't need to offer shells on it. Just allow people to proxy a port to behind the bastion and be done with it. PermitTTY no ForceCommand /usr/sbin/nologin AllowTcpForwarding yes All…

Is finer grained control over TCP forwarding possible? e.g. allow forwarding only to certain TCP ports?

"PermitOpen *:22"

Re: SSH Bastion Host Best Practices

#68

Post by mlyle »

vngzs wrote: post #22
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.

From a defense standpoint, one should consider "shell on a box" to usually mean attackers can get root on a box. If they can get persistence, they can wait for a kernel CVE to abuse. Now, if you're just using a bastion as a jump host, you don't need to offer shells on it. Just allow people to proxy a port to behind the bastion and be done with it. PermitTTY no ForceCommand /usr/sbin/nologin AllowTcpForwarding yes All…

I suggest:

   AllowAgentForwarding no
   AllowTcpForwarding yes
   X11Forwarding no
   PermitTunnel no
   GatewayPorts no
   PermitOpen *:22
   ForceCommand echo 'Nope'
Then:

    ssh -J finaluser@finalhost user@bastion
You can nicely use your local agent, etc. Bastion is relatively hardened. Etc.

Re: SSH Bastion Host Best Practices

#69

Post by fulafel »

The premise sounds iffy ("SSH bastion hosts are an indispensable security enforcement stack for secure infrastructure access").

Every time you build some infrastructure, you expend scarce resources like engineering effort (=opportunity cost), time, money, and complexity by adding moving parts to your christmas tree of technology. You should always critically evaluate what's the most low hanging fruit you can invest in for a given end goal (eg improving security) considering the complexity costs. SSH bastions can be worth implementing in some situations, but not top of the list in many cases.

The next sentence starts talking about "security compliance standards" - you sometimes have to submit to doing stuff for reasons of ticking boxes, but it's important to remember when you're doing what's best for security and when you're going through motions mainly to tick boxes for someone else.

Re: SSH Bastion Host Best Practices

#70

Post by eitland »

whynotminot wrote: post #24
tsuraan wrote: post #20

Earlier quoted context omitted.

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

TIL! Thank you very much

See also the answer from mindcrime.

There's also one very important difference between those two:

- others can see your favourites.

- you can see both your upvotes and your favourites

so only use favourites for things you don't worry about others seing.

I don't know if this is important for you but for a lot of people here it probably can be.

Post reply on HN