01
Locate the failure before changing permissions
Run one verbose attempt against the intended account and host. Look for whether the identity was found, whether its public key was offered, and whether authentication continued. Logs can contain hostnames and usernames; review them before sharing.
If the account is wrong, perfect permissions on another user’s authorized_keys will not help. GitHub illustrates the same distinction with its service account: SSH to GitHub uses git, not your personal GitHub username. An ordinary Linux host uses the account provisioned by its administrator.
ssh -v -o IdentitiesOnly=yes -i ~/.ssh/app_ed25519 developer@server.example.com02
Check the local private key separately
A private key readable by other users can be rejected by the client before it signs an authentication request. Inspect that particular file. A conventional personal key should be owned by the user running SSH and readable only by that user.
Our lab changed only the disposable client key from mode 600 to 644. The client reported an unprotected private key and refused authentication. Restoring mode 600 allowed the same key and account to connect again. This was a client-side rejection, independent of server key registration.
ls -ld ~/.ssh
ls -l ~/.ssh/app_ed25519
# For your own, correctly owned private key:
chmod 600 ~/.ssh/app_ed2551903
Inspect the server account through authorized access
With an existing authorized session or provider console, inspect the target home directory, .ssh directory, and authorized_keys. Check ownership and unexpected group or other write access along the path. The public key must be registered for the account actually requested.
In our server-side reproduction, authorized_keys was writable by everyone. The login failed, and the server log explicitly identified bad ownership or modes. Restoring that file to mode 600 fixed the login without disabling StrictModes or replacing the key.
# Run on the server through an already authorized channel.
ls -ld /home/developer /home/developer/.ssh
ls -l /home/developer/.ssh/authorized_keys
# Repair only after confirming the intended account and ownership.
chmod 700 /home/developer/.ssh
chmod 600 /home/developer/.ssh/authorized_keys04
Use server evidence when permissions look correct
Review the SSH service logs for the same attempt. Ubuntu installations commonly expose them through the ssh systemd unit, but the service name and log destination vary. A missing key, disabled account, key restriction, or server authentication policy can produce a similar client ending.
If ownership is wrong, correct only the affected files for the verified account; do not run recursive ownership changes over a shared home tree. On systems with ACLs or mandatory access controls, inspect those controls rather than assuming chmod describes all access.
# Ubuntu example; use your distribution’s actual SSH service name.
sudo journalctl -u ssh --since '10 minutes ago' --no-pager05
Verify the identity, then close the recovery path
Repeat the original command and run a harmless identity check such as id -un. Confirm that it returns the intended user. A successful SSH connection to a different account is not a successful repair.
Keep public keys in authorized_keys and private keys on the client. Permission changes cannot repair a mismatched pair. If the server still rejects a usable key, compare its public fingerprint with the registered key and continue from the server’s recorded reason.
Sınırları bil
The reproduction uses Linux OpenSSH 9.2p1, regular Unix permissions, StrictModes enabled, and a disposable account. Windows ACLs, SELinux policies, external key stores, and restricted accounts need additional checks. We did not change a real user’s SSH files.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet