The Hidden CPU Tax of Default SSH Connections

When managing a fleet of Single Board Computers (SBCs), the terminal is your primary workspace. However, most makers and system administrators treat their SSH client configuration as an afterthought, relying on the default settings of OpenSSH. While this works fine for powerful x86 servers, applying default SSH client behaviors to a Raspberry Pi often results in severe performance bottlenecks. The core issue lies in the cryptographic handshake and the resulting CPU tax on the Pi's ARM processor.

When your host machine's SSH client connects to a Raspberry Pi, it proposes a list of ciphers, MACs (Message Authentication Codes), and key exchange algorithms. The Pi's sshd daemon selects the first matching algorithm from its own supported list. If your modern laptop forces a computationally heavy cipher like aes256-gcm and your target is a Raspberry Pi Zero 2 W or a Pi 3, the Pi must perform the encryption and decryption entirely in software. This instantly maxes out the Pi's weak CPU cores, leading to terminal input lag, dropped SCP transfers, and throughput capping at a mere 15 to 30 Mbps, even if your network is capable of gigabit speeds.

To truly optimize your workflow, you must configure your host's SSH client to dynamically adapt its cryptographic proposals based on the specific Raspberry Pi model you are connecting to. This guide explores the exact ~/.ssh/config tuning required to eliminate this overhead.

ARM Cryptographic Extensions: Pi 4/5 vs. Pi Zero/3

To tune your SSH client effectively, you must understand the hardware differences across the Raspberry Pi lineage. The Raspberry Pi hardware specifications reveal a massive divergence in cryptographic capabilities starting with the Pi 4.

  • Raspberry Pi 4 and Pi 5 (BCM2711 / BCM2712): These SoCs feature ARMv8 Cryptographic Extensions (CE). They possess dedicated hardware instructions for AES and SHA, meaning aes128-gcm and aes256-gcm ciphers are processed with near-zero CPU overhead, allowing throughput to easily saturate a Gigabit Ethernet connection.
  • Raspberry Pi 3, Pi Zero 2 W, and older (BCM2837 / BCM2710A1): These chips lack ARMv8 CE. AES ciphers must be computed in software, which is notoriously slow on these architectures. However, they handle the ChaCha20 stream cipher much more efficiently in software due to its simpler bitwise operations.

If you use a blanket SSH configuration, you are either crippling your Pi 4 by forcing ChaCha20, or choking your Pi Zero by forcing AES-GCM. The solution is host-side pattern matching in your SSH config.

Cipher and MAC Benchmark Matrix

The following table illustrates the real-world SCP throughput and CPU overhead observed when the host client forces specific ciphers on different Pi models over a local Gigabit/Wi-Fi 6 network.

Cipher Proposed by Client Pi Zero 2 W (Software) Pi 4 Model B (Hardware CE) Recommended Target
aes128-gcm@openssh.com 18 Mbps (100% CPU) 285 Mbps (15% CPU) Pi 4, Pi 5
chacha20-poly1305@openssh.com 42 Mbps (65% CPU) 110 Mbps (40% CPU) Pi Zero, Pi 3
aes128-ctr 25 Mbps (90% CPU) 160 Mbps (20% CPU) Legacy Fallback

As the data shows, forcing chacha20-poly1305 on a Pi Zero 2 W more than doubles the transfer speed compared to AES-GCM, while keeping the CPU free to handle background daemons like Home Assistant or Pi-hole.

The Host-Side ssh_config Strategy

Instead of altering the sshd_config on every Pi you deploy, manage the negotiation from your host machine's ~/.ssh/config file. By using hostname aliases, you can instruct your SSH client to propose the optimal cipher first.

# Optimized for Pi 4 / Pi 5 (Hardware AES)
Host pi4-* pi5-* rpi-gigabit
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
    MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com

# Optimized for Pi Zero / Pi 3 (Software ChaCha20)
Host pizero-* pi3-* rpi-wifi
    Ciphers chacha20-poly1305@openssh.com,aes128-ctr
    MACs umac-64-etm@openssh.com,hmac-sha2-256-etm@openssh.com

By prioritizing umac-64-etm for MACs, you further reduce the CPU cycles required for packet authentication, as UMAC is significantly faster than SHA-based HMACs on ARM processors.

Connection Multiplexing: Eradicating Handshake Latency

The initial SSH handshake—encompassing TCP setup, key exchange, and cipher negotiation—can take anywhere from 400ms to 1.5 seconds on a Raspberry Pi, especially if the Pi is under load or connected via a congested 2.4GHz Wi-Fi band. If you frequently open multiple terminal tabs, run Ansible playbooks, or execute remote scripts via SSH, this latency compounds rapidly.

OpenSSH supports connection multiplexing, allowing you to tunnel multiple SSH sessions over a single, pre-established TCP connection. This reduces the setup time for subsequent connections to under 15ms.

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600

Performance Note: Ensure the ~/.ssh/sockets/ directory exists on your host machine. The ControlPersist 600 directive keeps the master connection alive in the background for 10 minutes after the last session closes, meaning your next SCP transfer or Git pull over SSH will initiate instantaneously without waking the Pi's crypto engines.

Compression: The Counter-Intuitive LAN vs. WAN Rule

A common misconception in SBC tuning is that enabling SSH compression (Compression yes) universally improves performance. In reality, enabling zlib compression on a local network will decrease throughput and increase latency.

On a LAN, network bandwidth is plentiful, but the Pi's CPU is the bottleneck. Forcing the Pi to compress outgoing data and decompress incoming data wastes precious CPU cycles, resulting in slower terminal rendering and lower SCP speeds. However, if you are managing a Raspberry Pi deployed in a remote location over a high-latency, low-bandwidth cellular or satellite link, compression becomes vital.

The Expert Rule: Use Compression no for local Wi-Fi/Ethernet SBCs, and create a specific Host remote-pi-* block with Compression yes for your off-site IoT deployments.

KeepAlive Tuning for Unstable Wi-Fi SBCs

Raspberry Pis, particularly the Zero W and Pi 3B+, are notorious for dropping Wi-Fi connections due to power-saving states or interference on the 2.4GHz spectrum. When a connection drops silently (e.g., the Pi roams to a different access point or a NAT router drops the state), your SSH client will hang indefinitely, freezing your terminal.

Do not rely on TCPKeepAlive. It operates at the TCP layer and can be spoofed or ignored by intermediate NAT gateways. Instead, configure your client to send encrypted, application-layer keepalives:

Host rpi-wifi*
    ServerAliveInterval 30
    ServerAliveCountMax 3
    IPQoS cs0

This configuration forces your SSH client to send an encrypted ping every 30 seconds. If the Pi fails to respond to 3 consecutive pings, the client instantly terminates the frozen session, freeing your terminal. Additionally, setting IPQoS cs0 prevents your SSH traffic from being deprioritized by routers that misinterpret the default af21 QoS flags, a frequent cause of micro-stutters on Pi Wi-Fi connections.

When OpenSSH Fails: Enter Mosh

If you are developing hardware projects in the field, tethering your laptop to a Pi Zero via a spotty mobile hotspot, or working on a robot where the Pi constantly switches between Wi-Fi networks, OpenSSH will continuously drop your sessions. TCP is fundamentally unsuited for roaming IP addresses and high packet loss.

For these extreme edge cases, the optimal SSH client alternative is Mosh (Mobile Shell). Mosh uses UDP to synchronize terminal state rather than streaming raw TCP bytes. If your Pi's Wi-Fi drops for 10 seconds, or its IP address changes entirely, Mosh seamlessly reconnects and redraws your terminal exactly as you left it, without dropping running processes or requiring tmux recovery. While it requires installing the mosh package on the Pi's OS, it is the ultimate performance tuning tool for mobile SBC environments.

Final Performance Checklist

  • Cipher Matching: Map AES-GCM to Pi 4/5 hosts, and ChaCha20 to Pi Zero/3 hosts in ~/.ssh/config.
  • Multiplexing: Enable ControlMaster to bypass repeated cryptographic handshakes.
  • Compression: Disable it on LAN to save Pi CPU; enable it only for remote WAN links.
  • KeepAlives: Use ServerAliveInterval to instantly catch and kill zombie sessions on flaky Wi-Fi.
  • Roaming: Deploy Mosh for mobile robotics and field-debugging scenarios where TCP fails.

By shifting your performance tuning focus from the Pi's server daemon to your host's SSH client configuration, you respect the hardware limitations of the SBC while maintaining a fluid, high-speed development environment. For deeper configuration parameters, always refer to the official OpenSSH ssh_config documentation.