I've been in the industry for a long, long time, and I would say that use of bastion hosts ranks #2 on my list of things that tell me your environment is not secure (right behind "we use fail2ban to protect us" as the #1 clue).
I've bought a bunch of companies and seriously evaluated hundreds of them, and the ones where people had a bastion host set up commonly seemed to act as if it protected them from everything, to the point where they just stopped worrying about security otherwise.
It gives a false sense of security and makes people put their guard down - like "OK, we have everything secured behind the firewall and only people who can log in to the bastion host, so there's no need for firewall rules or policies on the servers inside our firewall perimeter". Which inevitably breaks down over time as things get opened up to the internet, employees come and go, etc.
I can't tell you the number of companies where I look at their setup and their bastion host itself is root owned - since those hosts are always being used (and are tied to everything so you can't easily reboot or replace them), and are considered nothing more than a "tool" that you rarely actually have to look at, they don't get updated nearly enough and are neglected.
Not saying that bastion hosts are a bad idea - but just like any easy to use, easy to forget, high risk part of the stack, they are often a sign of inexperience and neglect elsewhere in the architecture.
(Yes, I know that there are plenty of big companies that use jump boxes without issue, and this jumpserver product is different, but I'm specifically talking about the idea of having one little machine that is open to SSH and then you bounce off of that to get into the "secured" machines, and all of this just based on my own experience and may not reflect yours)
I think that's because what you're really looking for isn't a jump server but a zero-trust network like cloudflare access or beyondcorp. You want authorized native connections, not proxies in the typical sense (although they do end up being proxies but more like a L3 proxy not L7)
I've been in the industry for a long, long time, and I would say that use of bastion hosts ranks #2 on my list of things that tell me your environment is not secure (right behind "we use fail2ban to protect us" as the #1 clue).
I've bought a bunch of companies and seriously evaluated hundreds of them, and the ones where people had a bastion host set up commonly seemed to act as if it protected them from everything, to the point where they just stopped worrying about security otherwise.
It gives a false sense of security and makes people put their guard down - like "OK, we have everything secured behind the firewall and only people who can log in to the bastion host, so there's no need for firewall rules or policies on the servers inside our firewall perimeter". Which inevitably breaks down over time as things get opened up to the internet, employees come and go, etc.
I can't tell you the number of companies where I look at their setup and their bastion host itself is root owned - since those hosts are always being used (and are tied to everything so you can't easily reboot or replace them), and are considered nothing more than a "tool" that you rarely actually have to look at, they don't get updated nearly enough and are neglected.
Not saying that bastion hosts are a bad idea - but just like any easy to use, easy to forget, high risk part of the stack, they are often a sign of inexperience and neglect elsewhere in the architecture.
(Yes, I know that there are plenty of big companies that use jump boxes without issue, and this jumpserver product is different, but I'm specifically talking about the idea of having one little machine that is open to SSH and then you bounce off of that to get into the "secured" machines, and all of this just based on my own experience and may not reflect yours)
I will never understand why SSH in such tools isn't native but always via some weird web UI...
I used to work for a company who allowed SSH only after jumping through Citrix => RDP => Putty => Jumphost => Target server.
Incredibly painful, also considering that each layer had a different keymap
I think that's because what you're really looking for isn't a jump server but a zero-trust network like cloudflare access or beyondcorp. You want authorized native connections, not proxies in the typical sense (although they do end up being proxies but more like a L3 proxy not L7)