Before you begin
Start with working server access and an account permitted to sign in. Keep the current session open until testing is complete. The private key stays on your device; only the .pub file belongs on the server. A key passphrase protects the local key file and is separate from the server account password.
Create and install a key
Run these commands on the client. Replace host.example and the account name. If the requested key file already exists, select another filename rather than overwriting it.
ssh-keygen -t ed25519 -f ~/.ssh/mermiko_ed25519 -C "my-laptop"
ssh-copy-id -i ~/.ssh/mermiko_ed25519.pub [email protected]Without ssh-copy-id, an administrator can append the public key as a separate line in ~/.ssh/authorized_keys. Ownership must match the account. Common permissions are 700 for .ssh and 600 for the authorized-keys file.
Test from a second terminal
ssh -i ~/.ssh/mermiko_ed25519 -o IdentitiesOnly=yes [email protected]On the first connection, compare the host-key fingerprint with one obtained through a trusted channel, such as the server console. Do not dismiss a changed fingerprint merely to remove the warning. A reinstall can explain a change, but the cause must be checked.
Change login policy only after testing
Disabling password authentication is a separate step. First verify key access in a new session and retain an emergency console. Check configuration with sshd -t before reloading the daemon; the service name varies by distribution. Open another new connection after the change before closing the original session.
- Keep private keys out of repositories and support tickets.
- Create a separate key for each device so one access grant can be revoked.
- Remove the corresponding public key from authorized accounts if a device is lost.
Sources and documentation
Source links are retained for checking dates, availability and original context.