Restricting SSH agent keys

Posted Jan 6, 2022 9:31 UTC (Thu) by taladar (subscriber, #68407)
In reply to: Restricting SSH agent keys by NYKevin
Parent article: Restricting SSH agent keys

Personally I would find having to type any commands on the bastion host a lot less convenient than just putting whatever ProxyCommand or (in newer versions) ProxyJump configurations into my ~/.ssh/config and literally forgetting about which hosts even need one or more levels of connections via bastion hosts.

Restricting SSH agent keys

Posted Jan 6, 2022 18:21 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

If you need to run a long-lived thing on the bastion, you may have no choice but to SSH into it in order to configure that long-lived thing. At that point, it's largely a matter of convenience.

Another possibility is that there are internal services which are inaccessible from your local host, and you need to SSH to a bastion just to do anything interesting at all. It just so happens that one of the various interesting things you need to do is SSH into other servers. But you also need to be on the bastion to do things like send RPCs, check out (proprietary) source code, etc., because your local host is not trusted enough to do those things itself.

Restricting SSH agent keys

Posted Jan 8, 2022 17:46 UTC (Sat) by atnot (subscriber, #124910) [Link] (1 responses)

One example might be to run programs like ansible that uses ssh to manage a large number of machines at once. Scripts that rsync data between two servers are also not that uncommon in oldschool sysadmining. There's definitely better solutions for those things these days but it'll take a while for everyone to get there.

Restricting SSH agent keys

Posted Jan 9, 2022 5:07 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

This is a good example, but I also think that there's an element of pets-vs-cattle here. In the cattle case, you're absolutely right: Ideally, you never SSH into cattle at all. If you need to SSH into something, it's broken and you should probably either redeploy the offending container or just reimage the silly thing, but in practice that's not always the case (You use containers, right? You can safely and easily reimage everything whenever you want, right?).

But the other practical reality is that not everything is going to be cattle in the first place. Some machines (workstations, mostly) are pets, and will always be pets, because each individual machine has slightly different requirements and there's no reasonable way to fully and completely standardize them. For those machines, a certain amount of manual remote administration is inevitable, especially in the brave new world of everyone working from home. Once you realize that this is a real use case, then ProxyJump starts to look a lot less reasonable as (the only) solution. Sometimes, manual multi-hop SSH is just *easier* in the context of everything else you're doing at the time.