How to authenticate with SSH using a private key

Key-based authentication in SSH uses cryptographic keys instead of interactive passwords, reducing the risk of credential theft and automated brute-force attacks while keeping remote administration convenient for both interactive sessions and automation tools.

Public key authentication in OpenSSH is based on a key pair where the private key stays on the local system and the public key is copied to the remote account, usually in the ~/.ssh/authorized_keys file. During connection, the client proves possession of the private key, and the server checks the corresponding public key without ever exposing the private key on the network.

Reliable key-based access depends on strict permissions for the private key file, correct ownership and location, and a server configuration that allows PubkeyAuthentication for the target account. If the private key file is world-readable or group-readable, SSH may refuse to use it entirely, and if the public key is missing or malformed on the server, authentication ends with a Permission denied (publickey) error.

1. Open a terminal on the local system where the private key is stored.

   $ whoami
   user

2. List the contents of the default SSH directory to confirm the private key file name.

   $ ls ~/.ssh
   authorized_keys
   id_ed25519
   id_ed25519.pub
   known_hosts
   known_hosts.old

   The default private key for OpenSSH is often id_rsa or id_ed25519 in the ~/.ssh directory.

3. Inspect the permissions of the private key file.

   $ ls -l ~/.ssh/id_ed25519
   -rw------- 1 user user 399 Jan 10 12:19 /home/user/.ssh/id_ed25519

   The private key should be readable and writable only by its owner, typically with permission mode 600.

4. Tighten the private key permissions if they are broader than owner read-write.

   $ chmod 600 ~/.ssh/id_ed25519

   Overly permissive private key permissions can cause SSH to ignore the key and may expose the key material to other users on the system.

5. Connect to the remote host using the private key with the ssh -i option.

   $ ssh -i ~/.ssh/id_ed25519 user@host.example.net 'hostname'
   host

   Replace user@host.example.net with the actual username and host; when using the default key name in ~/.ssh, the ssh client can often omit the --identity-file (-i) option.

6. Enable verbose output temporarily if authentication fails to see how the key is being used.

   $ ssh -i ~/.ssh/id_ed25519 -v user@host.example.net
   OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024
   ##### snipped #####
   debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:2YSqUgupuHPVO2Ur7z8JFQXILaeTWSxaJH9Bd+d7c3k explicit
   debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:2YSqUgupuHPVO2Ur7z8JFQXILaeTWSxaJH9Bd+d7c3k explicit
   ##### snipped #####

   Lines mentioning Offering public key and Server accepts key confirm that the server is attempting public key authentication.

7. Verify on the remote server that the matching public key line is present in the ~/.ssh/authorized_keys file for the target account.

   $ grep 'ssh-ed25519' ~/.ssh/authorized_keys
   ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKMswzIlIh3kp+xJYbZjGQ3g+PhfA1q13kFJ1sDXjMOV user@host

   Ensure the entire public key line, including the key type (such as ssh-ed25519 or ssh-rsa), key data, and optional comment, is on a single line in ~/.ssh/authorized_keys.

8. Confirm that the session starts on the remote system without a password prompt.

   $ ssh -i ~/.ssh/id_ed25519 user@host.example.net 'whoami'
   user

   A successful connection that reaches a remote shell without prompting for a password indicates that public key authentication is working correctly.