Before you start
OpenSSH client and Linux OpenSSH server. Use the correct host, account, port, and distribution-specific service name.
Commands are examples, not actions run by this page. Replace the sample names and paths. Run related blocks in the same shell. Read the explanations before copying. Logs and configuration can contain private data; keep credentials and unredacted evidence out of public posts.
Validation: documentation-reviewed guidance, not a tested live-cluster repair.
A laptop offers several keys, but the server expects one key for a different account. Regenerating keys or enabling root/password login can create new problems without correcting the account mismatch. Keep a working session or console before touching the server.
1. Identify which stage failed
Do not treat every SSH error as a permissions error. A host-key warning is also a separate trust issue: independently verify the new fingerprint before replacing a known-host entry.
| What you observe | What it suggests | Next step |
|---|---|---|
| Connection timed out | The network path or filtering may be preventing a response. | Verify address, VPN or route, intended port, and authorized firewall rules. |
| Connection refused | The target answered without accepting this TCP connection. | Verify the host and port, then inspect the listener and service through console access. |
| Permission denied (publickey) | The SSH endpoint was reached, but authentication did not complete. | Compare account, offered identity, authorized key, and server restrictions. |
2. Offer the intended identity deliberately
Replace these illustrative values. Use your existing private key; do not upload it to a website or place its contents in a support ticket. Debug output contains hostnames, account names, and key fingerprints that may also need redaction.
REMOTE="student@server.example"
KEY="$HOME/.ssh/id_ed25519"
ssh -G -S none -o IdentitiesOnly=yes -i "$KEY" "$REMOTE"Review hostname, user, port, proxy, and identity settings. Only use trusted SSH configuration: evaluating Match exec can execute local shell commands even with -G. This is not a guaranteed passive file read.
ssh -vvv -S none -o IdentitiesOnly=yes -i "$KEY" "$REMOTE"-S none prevents reuse of an authenticated shared connection. This is a real login attempt and may trigger rate limits. Other configured IdentityFile or certificate entries can still apply; inspect the accepted key fingerprint and method, not just successful login.
3. Verify server evidence before changing access
Use an existing administrator session or recovery console. On Oracle Linux the unit is commonly sshd.service; on other systems it may be ssh.service. Compare the failure timestamp with the correct account and source address.
Inspect the configured AuthorizedKeysFile and the ownership and write permissions of that account’s home, .ssh directory, and authorized-keys file. StrictModes checks are a security control, not an obstacle to disable. A key must also satisfy account, group, certificate, and Match-block policy.
Have the owner correct only the identified key, path permission, or account-policy mismatch. Keep the previous configuration and an independent console path. If configuration is edited, use the installed sshd syntax checker and the distribution’s supported reload procedure before closing the old session.
sudo journalctl -u sshd.service -b --no-pager -n 80Run on the server. If journal retention or the unit name differs, use that system’s configured authentication logs.
sudo /usr/sbin/sshd -tRun the installed sshd binary path. A successful syntax check does not prove remote reachability or that your particular account will be allowed.
Verify the fix
- Open a fresh, non-shared connection with -S none while keeping the original administrator session open. Confirm which key or certificate was actually accepted in the debug output.
- Confirm the expected server host key and the intended account, not merely that some login succeeded.
- Verify unrelated accounts did not gain access, then document the key ownership and recovery route.
Record the evidence, approved change, result, and rollback plan so the next administrator can follow your reasoning.
Avoid these shortcuts
- Never share private keys or disable host-key checking to suppress a warning.
- Do not enable root login, password authentication, or broad firewall access as a shortcut.
- Do not replace authorized_keys wholesale when other legitimate keys must remain.
Primary sources and version checks
Check the documentation for your installed release. Provider, runtime, CNI, storage-driver, and distribution details can differ.