Concurrent SSH connections Limit on Linux Jump Host

Latest response

We are setting up the RHEL-7 Jump-Host VMs on ESXi cluster and want to know how much vCPU and RAM will be required for users more than 200+, taking SSH session to this Jump-Host at the same time.
Pls Consider below,
1) those users will be utilizing this session to access associated network devices
2) this is average user count and sessions for a shift
3) all users will login at the same time when shift starts.
4) Available sizing we have - total vCPUs 32 and total RAM in GB 256

I am new to the Linux and from core networking background.

Thanks in advance.


That's more than enough resources to handle the concurrent SSH workload. Each user will run an SSH connection and a shell which consumes only kilobytes of RAM. The RAM workload for 200 users will be in the order of megabytes, probably under 100 MiB.

The question will be what those users do with their sessions.

If this is a bastion box where the users simply SSH somewhere else, then the workload is very light. You could possibly get away with a lot less resources if this system just shuffles interactive SSH around.

However, if this is the user's working system where each user will be opening large processes and consuming a lot of CPU time and wirespeed network bandwidth, you may need to load test to find out the maximum concurrent users for your environment before problems start.

I'd recommend that you let your users know that after they "jump" to that system, to consider when they go to the "next system" they consider using "tmux" so if their connection to the bastion (or their local system has issues), that their session remains active. This would be particularly more important if one or some of your users runs a process that should not be interrupted. This will of course vary based on the needs of those using it, and maybe this is needed, and maybe not.


For an SSH bastion, you can even make the middle system transparent with ProxyCommand in ~/.ssh/config. Assuming you have SSH keys setup on each, the following lets you ssh remoteserver and appear to connect to it directly. I'd then run tmux or GNU Screen on the remote server, not the bastion.

Host bastion
 User myusername

Host remoteserver
 Hostname remoteserver.example.local
 ProxyCommand ssh bastion -W %h:%p
 User myusername

Of course there are many ways to set this up, that's just my preference :)

Great point Jaime - thanks for that great tip!


Sometimes there is more than just one potential server one could go to...

Jamie, is there a way to shape the ssh command with the config you mention such that you could automagically go to the host of your intention (namely if it is more than one potential host, or a new host established an hour ago??)


Hi Ankush,

RJ and Jamie gave you good advice.

Your VM sizing for the jumphost is more than enough (actually oversized!).

Some items you need to plan in design:

a) What kind of applications jumphost needs to offer to your users. Are some of them GUI-based and resource-hungry (for example, network analysers and sniffers).

b) If a user loses SSH connection to jumphost, how do they reconnect.

There are various commercial tools to fight this problem (SecureCRT is one of them).

c) Should same jumphost be used for Prod and Non-Prod environments.

d) Do you need additional jumphost servers to ensure resiliency.

e) Should you use 2FA (Two Factor Authentication) or even MFA (Multi Factor Authentication).

f) Centralised logs for all events on jumphost. Where and how.

and more...

Personally, here are some items I provided to a special customer not long ago on this topics: replace jumphosts with containers. Here are my views why:

When one looks at the growing popularity of hybrid ecosystems, where organizations mix in the cloud, third party contractors, and many third party services/connections, jumphosts starts to become harder to implement and significantly less effective. And with DevOps popularity, having a one-off solution that generally needs to be manually controlled and updated is directly opposite from direction of consistency and automation.

1. As the IT landscape evolve, it is time to abandon the concept of perimeter security in favour of more dynamic methods such as zero trust security, in which all network traffic is untrusted by default. An emerging cloud architecture enables organizations to take a zero trust approach, increase their flexibility, and grant granular server access permissions for each user - entirely from the cloud.

This architecture, which drives the domainless enterprise model, is built around a cloud directory service. From a cloud directory service, admins can establish a secure channel directly between their directory and each server, regardless of where it is located. They can then systematically provide and revoke access to those servers with granular access permissions tailored to each individual’s role.

2. Individual jumphosts built as, for example, containers on demand, which are shut down and destroyed once given user finished their work.

3. “Privileged Access Workstations” (PAW) or “Secure Access Workstations” (SAW) - dedicated operating system used to securely access privileged resources, similar to a jump server. Instead of living in the datacenter, a PAW is a workstation that is dedicated solely to accessing sensitive tasks and information. These devices are typically locked-down and therefore insulated from Web-based attacks and other threat vectors. Recommended by Microsoft.

PAW can be even an individually-built on-demand container for each user!

4. LDAP or Active Directory (AD) infrastructure. Designed to manage user access and control, but to do that through a centralized directory, not a centralized “choke point” like jumphosts.

“Directory-as-a-Service” can replace jumphosts and enhance IAM across an environment.


Dusan Baljevic (amateur radio VK2COT)

Very nice tips Dusan!