Cloud / SRE

Fixing Too Many Authentication Failures in an iTerm SSH Profile

Why an SSH agent can exhaust MaxAuthTries before the intended key is offered, and how IdentitiesOnly and IdentityAgent fix the profile.

Published Jun 15, 2026Updated Sep 06, 2026
SSHiTerm2SREtroubleshooting
On this page
  1. Terms used here
  2. Compare identity selection
  3. References

When an iTerm SSH profile closes during authentication, a nearby post-quantum key-exchange warning can distract from the disconnect reason. These messages describe different stages. Check whether the server reports:

Too many authentication failures

This happens when the local machine has an SSH agent, 1Password SSH Agent, or many private keys loaded. The SSH client may offer several agent keys before it reaches the key specified by -i. The server can limit authentication attempts with MaxAuthTries, so it may disconnect before the intended key is tried.[1]

Terms used here

TermMeaning
SSH agentA local process that stores private keys and offers them to SSH clients.
1Password SSH Agent1Password’s SSH agent integration. It can make keys available to SSH without writing them as plain files.
IdentitiesOnly=yesSSH option that tells the client to use only the identities explicitly configured for this command or host.
IdentityAgent=noneSSH option that disables the local agent for this connection.
Post-quantum key exchange warningA security notice about future-safe key exchange algorithms. It is separate from authentication failure.

Compare identity selection

This test assumes the intended private key is available as a local file. If the key is held only in an agent, disabling that agent removes the required signing path. Inspect the host’s configured identity selection instead.

Compare these two commands:

ssh -i "/path/to/key.pem" user@private-host

and:

ssh -o IdentitiesOnly=yes -o IdentityAgent=none -i "/path/to/key.pem" user@private-host

If the second command succeeds while the first fails, the comparison supports unintended identity selection as the cause. It also verifies that the tested network and authentication path works with the explicit key; it does not assess the server’s overall health.

The durable profile command is:

ssh -o IdentitiesOnly=yes -o IdentityAgent=none -i "/path/to/key.pem" user@private-host

IdentitiesOnly=yes tells SSH to use only explicitly configured identities. IdentityAgent=none disables the authentication agent for that connection.[2]

The post-quantum warning is a separate security notice. It may be worth addressing as part of server hardening, but it was not the reason this profile failed to log in.

References

[1] OpenBSD. “sshd_config(5): MaxAuthTries.”

[2] OpenBSD. “ssh_config(5): IdentitiesOnly and IdentityAgent.”