> For the complete documentation index, see [llms.txt](https://docs.p0.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.p0.dev/integrations/resource-integrations/microsoft-azure/configure-bastion-host-integration/custom-jump-host/jump-host-sizing-and-tuning.md). # Jump host sizing and tuning When you connect P0 through a [custom jump host](/integrations/resource-integrations/microsoft-azure/configure-bastion-host-integration/custom-jump-host.md), 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. {% hint style="info" %} 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](/integrations/resource-integrations/microsoft-azure/configure-bastion-host-integration/custom-jump-host.md). {% endhint %} ## 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`. ```ini # 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. | {% hint style="warning" %} `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. {% endhint %} ## 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. | {% hint style="warning" %} 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. {% endhint %} ### 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](#recommended-sshd-configuration) to match. ## Related pages * [Custom jump host](/integrations/resource-integrations/microsoft-azure/configure-bastion-host-integration/custom-jump-host.md) * [Configure bastion host integration](/integrations/resource-integrations/microsoft-azure/configure-bastion-host-integration.md) * [Jump host management](/integrations/resource-integrations/microsoft-azure/jump-host-management.md)