Confirm the correct server fingerprint and account name. Keep an existing authorized SSH session open and ensure console recovery is available. Generate a modern key supported by both client and server, with a passphrase or appropriate hardware protection.

1. On your trusted client, identify the intended public-key file and record its fingerprint. Never upload the private-key file or paste it into a support ticket.
2. Use the supported key-installation method, such as ssh-copy-id -i PUBLIC_KEY_FILE USER@HOST, with your actual values. If editing authorized_keys manually, append one complete public-key line instead of overwriting existing entries.
3. Check the target account owns its SSH directory and key file. Typical permissions are 700 on .ssh and 600 on authorized_keys; also check parent-directory ownership and any SELinux labeling.
4. Open a second connection using the intended private key and explicit account. Confirm the client actually authenticates with that key rather than silently falling back to a password or another agent key.
5. Test any required sudo access in the new session. Only after success should you remove an obsolete public key or undertake a separate SSH authentication-policy change.

From your own workstation, test the public key that was installed for the intended server account. Replace the key path, username, hostname and port. Keep the existing working session open while you make this separate connection.

ssh -v -o IdentitiesOnly=yes -i ~/.ssh/nabtech_admin_ed25519 \
  -p 22 [email protected]

Read the result: The verbose log should show the selected public key being offered and, when accepted, successful public-key authentication. IdentitiesOnly reduces confusion from other keys loaded in an agent. Confirm the server fingerprint through your trusted record before accepting a first connection.

If access is denied, inspect the target account and its authorised-key file through the existing session. Do not paste the private key into the server's authorised_keys file. Share only a redacted diagnostic excerpt if support needs to identify the failing authentication stage.

Only after a new independent key-authenticated session and required administrator access succeed. Confirm other authorized operators and automation have an approved access method before changing the policy.

Confirm the expected public-key fingerprint appears in the client authentication trace or server log and that a fresh connection works after the original session closes. Keep the private key backed up or maintain another approved recovery credential.

For Permission denied, compare username, authorized-key path, permissions and the key the client offers. Inspect sanitized SSH logs without publishing private material. Too many offered agent keys can require choosing the exact identity. Do not relax directory permissions broadly or disable all authentication restrictions to make a key work.

• Testing SSH configuration before reloading the service
• Creating a least-privilege sudo administrator on Linux
• Recovering from an SSH lockout using the server console
• Restricting Ubuntu firewall access without locking out SSH

• Ubuntu: Openssh Server
• man.openbsd.org: Sshd

• OpenSSH client reference