I've spent the last 7 years using SSH to get onto a prod box a few dozen times. Less than once a month. When I do have to get on the box, we use signed keys that expire in 24 hours (a manager or SRE is required to sign the key if you need to get on a box).<p>The article is talking about the scaling issues of SSH access via jump boxes or bastions. I'd argue that a better solution to scaling SSH access is to invest in tooling that makes SSH access unnecessary for most of your team. Centralized logs, error reporting, distributed traces, etc. are fairly well solved for most installations. Interactive access to prod (e.g. running DB migrations) requires a little more investment, but tools like ECS Exec make that fairly accessible without requiring SSH access.
Er, so most of those supposed problems sound like you could fix them by just using unprivileged users jumping through the jump server via `ssh -J`/ProxyJump? Or a VPN, which is pretty close to what it sounds like the product they're trying to sell is anyways. And if you're going to try and sell a Teleport competitor, you really should do a better job convincing me that it's going to actually be secure in the first place. I don't see source code or audits anywhere on this website.
Even when using a jump server, I've solved the issue of revoking access in the past by using LDAP to control access to servers. Instead of adding user accounts directly to server, the account information is stored in LDAP -- including public SSH keys. If you want to revoke a user's access across the entire infrastructure, then you can do so in one fell swoop.<p>I also have set this up to restrict SSH access to particular hosts based on the LDAP record.<p>The problem they are describing isn't a problem with Jump servers... it's a problem with distributed authorization.
Google Cloud’s IAP tunneling has basically made this a non-issue. All access is logged and its extremely easy to get around without any public IPs.<p>Also easy to port-forward instances to your local machine.<p>I’m always surprised that other clouds don’t have this.
I am a bit confused about this product. I had once seen a product called Runops [1], the customer list and product testimonials are exactly same as this product Hoop.dev [2].
[1] <a href="https://runops.io/">https://runops.io/</a><p>[2] <a href="https://hoop.dev/" rel="nofollow">https://hoop.dev/</a>
> Jump Servers must be able to reach to a certain private network and this requires specific configuration for each environment;<p>Yup. Use VPNs and firewall ACLs. Jump servers are leftovers of bad practices where good practices were too hard to implement.<p>> Burden of managing SSH keys of users throughout all nodes. Rotation is required when someone leaves or enter the organization;<p>That is extremely trivial if you have (you should) any sensible configuration management in place. We just store them in LDAP with user data and distribute where neede (gitlab, servers)<p>> Role management requires managing sudoers files, making sure file system permissions are properly configured and users are within their proper groups;<p>Ah yes, managing a text file, so fucking hard /s<p>> Nodes must be updated with the tooling necessary to interact with internal services.<p>>Keep a list of updated services (DNS) available to interact with it<p>see the point about CM<p>> Usually, infrastructure enginners are a scarce team and keeping all these components updated are hard to tackle. Over time, these nodes will onboard more users and tooling, which will increase the complexity over managing these resources.<p>Which is why you write it once and use automation. I don't think we touched our sudoers or ssh key management module in years, it was written once then had some small changes but that's about it
AWS Session Manager is great. However, to connect to an RDS/Aurora/Elasticache instance, you must still create an intermediate EC2 instance to run SSM commands against.<p>We use Basti (<a href="https://github.com/BohdanPetryshyn/basti/issues">https://github.com/BohdanPetryshyn/basti/issues</a>) to set up and manage the jump host. The tool automatically starts/stops the instance, which is excellent for irregular access.
I'd rather patch a bunch of openssh servers than a bunch of proprietary software agents that essentially keep reverse ssh tunnels open for me. Or did I miss something?
Use of SSH agent forwarding is dangerous as it allows an attacker to gain access to more key materials to access more servers. Using it casually in an article about SSH security is a bit worrying.