Secure Shell (SSH) keys are a foundational tool for securing remote access. Compared to password-based login, SSH key authentication is safer, more convenient, and ideal for automation. In this guide, you’ll learn how to generate an SSH key pair on Ubuntu, install the public key on a server, and configure things properly.

  • SSH key pairs use public-key cryptography: you keep a private key (secret) on your local machine, and place the public key on remote servers.

  • When you try to log in, the server verifies you have the corresponding private key—without transferring the private key itself.

  • Advantages: stronger security (harder to brute force), passwordless login, better for scripting and automation.

  • Modern recommendations favor algorithms like Ed25519 for key generation (vs older RSA).

Before creating a new key, see if you already have one:

				
					ls ~/.ssh/id_*.pub

  • If the command returns one or more files (e.g. id_ed25519.pub, id_rsa.pub), you already have a public key.

  • You can reuse an existing key (if you trust it) or back it up and generate a fresh one.

  • Note: generating a new key may overwrite the existing default key unless you specify a custom name.

Run the ssh-keygen command. A common and modern approach:

				
					ssh-keygen -t ed25519 -C "your_email@example.com"

Here:

  • -t ed25519 — chooses the Ed25519 algorithm (strong and fast)

  • -C "..." — adds a comment / label (often your email) to identify the key later.

  • You’ll be prompted:

    1. File to save key: press Enter to accept default (~/.ssh/id_ed25519) or specify a custom name.

    2. Passphrase: you can enter a strong passphrase (recommended) or leave blank (not recommended for high-security systems).

If the default file already exists, you’ll be asked whether to overwrite—be careful to avoid losing access tied to old key(s).

After success, you’ll see output like:

				
					Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
Key fingerprint is: ...

Now that you have a public key file (e.g. ~/.ssh/id_ed25519.pub), you need to add it to the authorized_keys file of the remote server and user account.

This will:

  • Prompt for the remote user’s password (one last time)

  • Append your public key to ~/.ssh/authorized_keys of that user on the remote machine

  • Set correct permissions (often) automatically

Method B: Manual method (if ssh-copy-id is unavailable)

1. Display your public key:

				
					ssh-copy-id username@remote_host

Copy the full contents (starts with ssh-ed25519 AAAA… … comment).

2. Log into the remote server (temporarily with password):

				
					ssh username@remote_host

3. On the remote server:

				
					mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

  • Paste your public key as a single line into that file

  • Save it, then:

				
					chmod 600 ~/.ssh/authorized_keys

Important: file and directory permissions are strict. If they’re too permissive, SSH will refuse key authentication

From your local machine:

				
					ssh username@remote_host

  • If it works, you should be logged in without being prompted for the remote user’s password.

  • If you set a passphrase, you’ll be prompted for it (or your SSH agent may cache it).

  • If you see an error like Permission denied (publickey), something is wrong (permissions, key mismatch, missing public key).

To debug, you can use verbose mode:

				
					ssh -v username@remote_host

The -v (or -vvv) flags show detailed debug output which helps trace where the authentication fails (e.g. which keys were tried, if files were rejected, etc.).

Once key authentication is confirmed working, you can disable password-based login on the server. This hardens security (no one can log in with a password).

1. Edit the SSH server config on remote:

				
					ssh -v username@remote_host

2. Locate (or add) these lines:

				
					PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Copy the full contents (starts with ssh-ed25519 AAAA… … comment).

3. Save and exit, then restart SSH:

				
					sudo systemctl restart sshd

⚠️ Warning: Before disabling password login, make absolutely sure your key login works (in a separate session). Otherwise, you may lock yourself out.

  • Use a passphrase: encrypting your private key adds a layer of protection if your machine is compromised.

  • SSH Agent: use ssh-agent to cache decrypted keys so you don’t need to enter your passphrase every time.

  • Different keys per server: for better isolation, you may generate distinct key pairs per server or use a naming convention.

  • Key rotation: periodically replace old keys with new ones and remove old public keys from servers.

  • Backup your private key: store it in a secure, encrypted location. Losing it means losing access.

  • Permissions matter: ~/.ssh should be 700, authorized_keys 600, private key file 600 (only readable by you).

  • Disable root SSH login: force login using non-root user + sudo to improve security.

  • Use secure algorithms: Ed25519, or RSA with 4096 bits, are good choices. Avoid deprecated or weak algorithms.

  • Permission denied errors: often due to incorrect permissions on .ssh, authorized_keys, or private key files. Make sure only the owner has access.

  • SSH not running / port issues: confirm SSH daemon is active on server (sudo systemctl status sshd) and firewall allows port 22 (or whichever port used).

  • Wrong public key or mismatch: ensure the exact public key string from your .pub file is present in authorized_keys (no line breaks or extra spaces).

  • Multiple keys not used: SSH may try other keys first—use ssh -i path/to/key or configure ~/.ssh/config to force a specific key.

  • Agent not forwarding or loaded: ensure ssh-agent is running and your key is added (via ssh-add).

Generating and using SSH keys is an essential skill for anyone managing remote servers. With a secure key pair in place, you eliminate much of the risk associated with password logins, while making your workflow smoother and automatable.

If you like, I can also create a version of this post formatted for WordPress, Markdown, or with your site’s branding and code highlighting. Do you want me to prepare that for you?