cloud-sre
When an iTerm SSH Profile Suddenly Stops Working
A short field note on diagnosing SSH profiles that fail with too many authentication failures.
An iTerm SSH profile that used to work can suddenly close immediately after launch. If the terminal also prints OpenSSH’s post-quantum key exchange warning, it is easy to chase the wrong problem and assume the server-side SSH version is broken.
The real error to look for is usually:
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 has a maximum authentication attempt limit, so it disconnects before the intended key is tried.
The useful test is to 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 works, the network path and server are fine. The failure was caused by unintended identities being offered first.
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 prevents SSH from pulling extra keys from the local agent.
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.