How to connect with SSH using a private key

Connecting with an SSH private key removes the remote account password from routine logins and remote commands, which makes repeated administration faster and reduces exposure to password guessing or reused credentials.

During login, the OpenSSH client reads a local private key, proves possession of the matching secret, and the remote sshd process checks the corresponding public key against the target account's ~/.ssh/authorized_keys file. When the key matches, the server starts the shell or remote command with public-key authentication instead of prompting for the account password.

This flow assumes the local machine already holds the private key and the matching public key is already trusted by the remote account. The first connection to a new host may still ask to confirm the host key, and a passphrase-protected private key can still prompt locally. When the key is stored under a non-default filename or ssh-agent offers too many identities, connect with -i and add -o IdentitiesOnly=yes so the client offers only the intended key.

1. List the local SSH key files and identify the private key to use.

   $ ls ~/.ssh
   id_ed25519
   id_ed25519.pub
   known_hosts

   Modern OpenSSH clients check default identity files such as ~/.ssh/id_ed25519 and ~/.ssh/id_rsa automatically. Use ssh -i /path/to/key when the key is stored under a different name or outside the default directory.

2. Start the SSH session by pointing ssh at the private key file.

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

   If the server is being contacted for the first time, ssh may ask to confirm the remote host key before the login continues. A prompt for the private-key passphrase is local to the client and is separate from the remote account password.

   If the remote account password prompt appears instead of a shell prompt, the server did not accept the matching public key for that account yet.
   Related: How to copy an SSH public key to a server

3. Force the client to use only the selected identity when ssh-agent is offering extra keys or the server disconnects after too many failed offers.

   $ ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@host.example.net
   user@host:~$

   IdentitiesOnly=yes limits authentication to the configured identity files for that connection instead of also offering unrelated keys from ssh-agent.

4. Verify that the remote account accepts the key by running a simple remote command.

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

   If the command returns immediately without a remote account password prompt, the server accepted the key for that account.

5. Restrict the private key permissions if OpenSSH rejects the file as too open.

   $ chmod 600 ~/.ssh/id_ed25519

   OpenSSH ignores private keys that are readable by group or other users and returns the UNPROTECTED PRIVATE KEY FILE! warning until the mode is reduced to owner-only access.
   Related: How to resolve the "SSH Unprotected Private Key File" warning in SSH

6. Use verbose mode to confirm that the server accepted the key when troubleshooting.

   $ ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -v user@host.example.net true
   debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd explicit
   debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd explicit
   Authenticated to host.example.net ([203.0.113.10]:22) using "publickey".

   Offering public key shows that the client tried the selected key, Server accepts key shows that the server matched it, and Authenticated … using “publickey” confirms that the login succeeded without falling back to a password.
   Related: How to increase SSH client verbosity