01
Distinguish an identity-selection failure from a network failure
First capture the exact disconnect reason. A timeout before SSH negotiation is a connectivity problem, while host-key verification failure is a server-identity problem. Neither becomes a key-selection problem merely because a private key file is present.
Use verbose logging for one connection and inspect the order of offered public keys. The diagnostic question is specific: did the client offer the intended identity before the server disconnected? Do not start by increasing server authentication limits or enabling password login.
# Replace example-host with your existing SSH alias.
ssh -vvv example-host
# Inspect the effective host configuration without connecting.
ssh -G example-host02
Compare effective configuration with the agent
An SSH agent may hold keys for multiple hosts. Compare its public-key fingerprints with the identities shown in the verbose connection. ssh-add -l lists fingerprints, not private key material. Even public diagnostics can reveal hostnames and usernames, so redact them before posting logs.
OpenSSH reads command-line options and configuration files with precedence rules. A generic Host * block placed too early can make a later host-specific value ineffective because many options use the first obtained value. Inspect ssh -G rather than assuming the file reads the way it looks.
ssh-add -l
ssh -G example-host | awk '$1 == "hostname" || $1 == "user" || $1 == "identityfile" || $1 == "identitiesonly"'03
Test one identity without disturbing other hosts
Make a one-off connection with the intended key and IdentitiesOnly enabled. This limits which configured identities the client should use for authentication. If the same command succeeds where the original alias failed, the comparison supports an identity-selection explanation.
Do not delete every key from the agent to prove this point. That changes other sessions and hides which host needed a different configuration. A per-command override is easier to compare and reverse.
ssh -o IdentitiesOnly=yes -i ~/.ssh/example_ed25519 user@example.com04
Persist the smallest host-specific change
Once the controlled test succeeds, place the identity selection in the appropriate host block. The example uses a placeholder hostname and account; keep your real values in your local SSH configuration. Leave unrelated host entries unchanged.
An encrypted key may still require unlocking through your normal agent or keychain workflow. If several IdentityFile directives apply, inspect the resulting list and the next verbose attempt. The important property is the actual identity set offered to this host, not merely the presence of IdentitiesOnly in one file.
Host example-host
HostName example.com
User user
IdentityFile ~/.ssh/example_ed25519
IdentitiesOnly yes
# Put broad defaults after host-specific entries.
Host *
ServerAliveInterval 3005
If the intended key is offered and rejected, change the investigation
A log showing that the correct key was offered but not accepted rules out the simple “wrong keys came first” explanation. Check the remote username, the server’s authorized key for that account, permissions and ownership, and applicable server authentication policy.
If you administer the server, correlate the client attempt with server authentication logs through an existing trusted session. Keep that session open while investigating. Do not bypass host-key verification, weaken file permissions, or restart SSH blindly as a workaround for an unproven cause.
06
Verify the ordinary workflow
Retry the normal alias after the configuration change, not only the long diagnostic command. Confirm that the intended user and host are reached and that an authenticated session is established. Then confirm another existing alias still behaves as before.
Keep the evidence small: original disconnect reason, offered-key order, effective configuration, and the result of the one-key comparison. That is more useful than a collection of retries whose configuration was never recorded.
Sınırları bil
This is an OpenSSH public-key authentication workflow. Certificate-based login, hardware keys, bastion policy, and managed access services may add requirements. The commands use placeholder hosts and do not create or distribute keys.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet