Jump host sizing and tuning

Reference sshd configuration and sizing limits for tuning a custom jump host VM, including a sample forwarding-only sshd_config and per-SKU load guidance.

When you connect P0 through a custom jump host, you own the jump host VM and its SSH server (sshd). P0 reaches your Azure VMs by opening forwarding-only SSH connections through this host, so the VM's sshd settings and size determine how many concurrent sessions it sustains and how it behaves under load.

This page is a reference for administrators who tune a custom jump host. It provides a recommended sshd_config, a directive reference, and sizing limits you can adapt to your own VM SKU.

These values are recommendations, not requirements. P0 does not manage or apply them. You own the jump host VM, so you set and maintain its configuration. For the connection requirements P0 enforces, see Custom jump host.

Recommended sshd configuration

The following sshd_config tunes a forwarding-only jump host to reap dead tunnels, cap idle forwards, and survive reconnect storms. Add these directives to /etc/ssh/sshd_config (or a drop-in under /etc/ssh/sshd_config.d/), then reload sshd.

# Reap dead or orphaned tunnels - works on all OpenSSH versions
ClientAliveInterval 60
ClientAliveCountMax 3            # Dead peer is gone in ~3 minutes

# Hard idle ceiling - OpenSSH 9.2 or later only (check with sshd -V)
ChannelTimeout direct-tcpip=15m  # Close silent forwards
UnusedConnectionTimeout 10m      # Drop connections with 0 open channels

# Survive reconnect storms
MaxStartups 100:30:200           # Default is 10:30:100

Also generate an Ed25519 host key for the jump host rather than an RSA-4096 key. Ed25519 handshakes are faster and cheaper, which matters on a shared, single-core VM.

Directive reference

Directive	Recommended value	Purpose
ClientAliveInterval	60	Sends a keepalive probe every 60 seconds to detect dead peers.
ClientAliveCountMax	3	Closes a connection after 3 missed probes, so a dead peer is reaped in about 3 minutes.
ChannelTimeout direct-tcpip=15m	15m	Closes a forwarding channel that has been silent for 15 minutes. Requires OpenSSH 9.2 or later.
UnusedConnectionTimeout	10m	Drops a connection that has zero open channels for 10 minutes. Requires OpenSSH 9.2 or later.
MaxStartups	100:30:200	Controls how many pre-authentication connections sshd accepts before it starts dropping new ones. Raises the default of 10:30:100 to absorb reconnect bursts.

ChannelTimeout and UnusedConnectionTimeout are available only in OpenSSH 9.2 and later. Confirm your version with sshd -V before you add them. On older releases, rely on ClientAliveInterval and ClientAliveCountMax alone.

Concurrency and load limits

Sizing depends on your VM SKU. The figures in the following table are a worked example for an Azure B1ms VM (1 vCPU, 2 GiB memory) serving forwarding-only (-W) SSH sessions. Use them as a starting point and adjust for your SKU.

Metric	Guidance for B1ms (1 vCPU / 2 GiB)
Concurrent idle forwards	Plan for 200-300. Memory alone allows about 400 (≈1.4-1.5 GiB usable ÷ 3-4 MB per connection), so cap below that for headroom.
Binding constraint	CPU at connect time, not memory. The B1ms SKU has a 20% baseline vCPU, a 288-credit burst bank, and no Accelerated Networking. A reconnect storm saturates the single core, drains credits, and handshakes start timing out.
Pre-authentication connections in flight	10 by default (MaxStartups). Raise this value, or reconnect bursts get dropped at random before authentication completes.

These limits assume interactive forwarding only. Any bulk transfer (SCP or real port-forwards) makes the jump host bandwidth-bound, and the sustainable concurrent connection count drops sharply. Size for bulk transfer separately, or route it off the jump host.

When to scale up

Move to a larger SKU or add jump hosts when you see any of the following:

• Handshakes time out during reconnect bursts, which indicates the single vCPU and burst credits are exhausted.

• Sustained concurrent forwards approach the memory ceiling for your SKU.

• Users run bulk transfers through the jump host, which shifts the bottleneck from CPU to network bandwidth.

For a larger fleet, choose a SKU with more vCPUs and Accelerated Networking, and scale the sshd limits in Recommended sshd configuration to match.

Related pages

• Custom jump host

• Configure bastion host integration

• Jump host management