SSH Connection Multiplexing: The Config That Saves You From "Too Many Authentication Failures"

You've been there. You're SSH'ing through a jump host to reach a fleet of servers, and suddenly every connection starts failing with "Too many authentication failures." You check the logs, nothing obvious. You restart sshd, same problem. You start questioning your life choices.

It's your SSH config. Specifically, how ControlMaster interacts with ProxyJump chains and the identity ordering that quietly overrides your explicit settings.

The Multiplexing Basics

If you're not using connection multiplexing, you should be. It reuses a single TCP connection for multiple SSH sessions to the same host. First connection authenticates, subsequent ones are nearly instant.

# ~/.ssh/config
Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 600

This creates a Unix socket at ~/.ssh/cm-user@host:22 that stays open for 10 minutes after the last session closes. Your second, third, tenth connection to that host? Instant.

Where It Breaks With ProxyJump

Here's the catch. When you chain ProxyJump, each hop needs its own control socket. But the Host * pattern above creates one socket pattern for everything, and the jump host and target host can end up fighting over the same socket path.

# This looks fine but causes problems
Host bastion
  HostName bastion.example.com
  User deploy

Host app-*
  HostName %h.internal.example.com
  User deploy
  ProxyJump bastion

When you ssh app-01, the multiplexing socket for bastion and app-01 can collide if your ControlPath doesn't distinguish them properly. The result: "Control socket connect failed" or the authentication failure cascade.

Fix: Unique ControlPath Per Hop

Host bastion
  HostName bastion.example.com
  User deploy
  ControlPath ~/.ssh/cm-bastion-%r@%h:%p

Host app-*
  HostName %h.internal.example.com
  User deploy
  ProxyJump bastion
  ControlPath ~/.ssh/cm-%h-%r@%h:%p

Notice the bastion prefix on the jump host's socket. Now they're completely separate.

The IdentityFile Trap

Another silent killer: ssh-agent forwarding with multiple keys. You have three keys in your agent. The target server only accepts one. SSH tries them in order, hits the limit, and you get "Too many authentication failures" before it ever tries the right key.

Host *
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_ed25519
  IdentityFile ~/.ssh/id_rsa_backup

IdentitiesOnly yes tells SSH: only use the keys I explicitly list here, ignore whatever's in the agent. Combined with explicit IdentityFile ordering, you control exactly which key gets tried first.

The Host * Catch-All That Overrides Everything

This one bites people constantly. You have a specific Host app-01 block, but somewhere earlier in your config (or in a included file) there's a Host * that sets User root or Port 2222. SSH processes config top-to-bottom, first match wins for each option. Your specific block never gets a chance to override.

# At the TOP of your config, or in an included file
Host *
  User deploy
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 600

# Later, your specific config
Host app-01
  HostName 10.0.1.5
  User admin        # This WILL apply (not set in Host *)
  Port 2222         # This WILL apply

But if Host * sets IdentityFile, your specific block's IdentityFile gets ignored. The fix: put your Host * defaults at the bottom, or use Include to separate concerns.

Using Include for Team vs Personal

# ~/.ssh/config
Include config.d/team/*
Include config.d/personal/*
Host *
  # Your personal fallbacks here

Now team configs (shared, version-controlled) load first, personal overrides load second, and your Host * catch-all is truly last.

Debugging Commands You'll Actually Use

# Check if a control socket exists and is alive
ssh -O check app-01

# List all active multiplexed connections
ssh -O exit app-01  # closes the master connection

# Verbose multiplexing debug
ssh -vvv -O check app-01

The -O check tells you if the master connection is up. -O exit tears it down cleanly. The -vvv shows you exactly which config options are being applied and in what order.

The Practical Pattern

Here's a working template I use:

# Team-shared jump hosts and defaults
Include ~/.ssh/config.d/team/*

# Personal overrides
Include ~/.ssh/config.d/personal/*

# Global fallback - LAST
Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 600
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

Team configs define the jump hosts with explicit ControlPath prefixes. Personal configs add per-host tweaks. The global Host * only applies where nothing else did.

Bottom Line

SSH multiplexing saves enormous amounts of time, but the default examples assume simple single-hop connections. Once you add ProxyJump chains and multiple keys, the config needs to be explicit about socket separation and identity selection. The debugging tools (ssh -O check/exit) are built in—use them before you blame the network.

Next time "too many authentication failures" shows up, check your control sockets and your identity ordering. It's usually one of those two.