Live data from Hacker News

SSH Bastion Host Best Practices

goteleport.com

51–60 of 91 posts

Re: SSH Bastion Host Best Practices

#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 the VPC.

Can’t 99% of the use cases be put in a template and managed by a service provider, including the security?

Re: SSH Bastion Host Best Practices

#53
The "how to grant and manage access to resources" issue is still unsolved in my opinion. There is a middle ground somewhere between raw bastions and managed access services or open VPNs that could be filled.

There are a few different players in this space, but the one to watch is Boundary by Hashicorp.

https://www.boundaryproject.io/

Basically managed authenticated proxy connections to any resource you could possibly need. Still young, so it's missing auditing and some of the convenience features, but give it a year and it will be a compelling open source competitor.

Teleport is great, but their centralized model is not suitable for all situations.. and the pricing (at least for kubernetes) leaves a lot to be desired.

There is also StrongDM, which is very similar with a better pricing model.

Re: SSH Bastion Host Best Practices

#54
post #29

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

We still need bastions to connect to RDS. But we connect to the bastions using SSM.

Re: SSH Bastion Host Best Practices

#56
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…

An interesting category of HOWTO have been companies teaching you how to do it yourself, for real. Before you get started, they pitch you at the end offering a paid-for option that has 0 learning curve. That's a good pitch.

Thankfully here the pitch is at the very bottom in the conclusion (although it's also in the sidebar).

Re: SSH Bastion Host Best Practices

#57
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…

A lot of it is. But unless you stick to the big 3 cloud providers, you need this for bare metal / colocation server deployments, which also happen to be much cheaper.

Re: SSH Bastion Host Best Practices

#58

Earlier quoted context omitted.

Thanks a lot, great hardening considerations. It would be interesting to hear what you think of Keykloak.

Sorry I have never used it so I don't have an opinion. That looks like an oauth/openid/saml ssh integration?

Yes and I have met it once when at a huge Telco, while doing my bastion host in AWS a security architect installed this and used Keycloak as the policy engine to allow connections using SSH keys. It worked really well and also gave us a very strong granular control on who could connect, and a great audit trail.

Re: SSH Bastion Host Best Practices

#59
post #22

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…

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

Re: SSH Bastion Host Best Practices

#60
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…

[deleted]
Post reply on HN