How to create and secure an SSH key pair

Topic: Accounts access

Create an Ed25519 SSH key pair, set correct permissions and optional passphrase, and verify passwordless login to a remote server. Use this guide before adding keys to servers or GitHub.

Intent: How-to

Quick answer

  • Check for existing keys, then generate a new Ed25519 pair with ssh-keygen.
  • Secure the private key with 700 permissions and a strong passphrase.
  • Add the public key with ssh-copy-id (or manually), then test login.

Steps

  1. Check for existing SSH keys

    List keys in ~/.ssh and decide whether to reuse or create new.

  2. Generate a new SSH key pair (ed25519)

    Run ssh-keygen with -t ed25519; store in default location unless you need a different path.

  3. Secure the private key (permissions + passphrase guidance)

    Set private key to 600 and directory to 700; add a passphrase for extra protection.

  4. Add the public key to the remote server (ssh-copy-id and manual fallback)

    Use ssh-copy-id if available, otherwise append the public key to ~/.ssh/authorized_keys on the server.

  5. Test passwordless login

    Run ssh with the key and confirm no password prompt; verify with whoami or hostname.

Summary

You will create an SSH key pair (Ed25519), lock down the private key with correct permissions and an optional passphrase, install the public key on a remote server, and confirm passwordless login. Use this guide when you have terminal access and need key-based SSH for a server or service.

Prerequisites

  • A Unix-like system (Linux or macOS).
  • Terminal access and permission to run commands.
  • SSH installed (ssh and ssh-keygen available).
  • Access to the remote server (username and hostname or IP) and a way to log in once (e.g. password) to add the key.

Steps

Step 1: Check for existing SSH keys

List existing keys so you can reuse one or create a new pair.

ls -la ~/.ssh

Look for files such as id_ed25519 / id_ed25519.pub or id_rsa / id_rsa.pub. If you already have a key you want to use, skip to Step 4. If you are creating a new key, continue to Step 2.

Step 2: Generate a new SSH key pair (ed25519)

Ed25519 is preferred: it is fast, secure, and produces short keys. Avoid RSA unless a system explicitly requires it.

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519
  • -t ed25519: key type.
  • -C: comment (often your email) to identify the key.
  • -f: path; omit to use the default ~/.ssh/id_ed25519.

When prompted, choose a strong passphrase (recommended) or press Enter twice for none. You will get id_ed25519 (private) and id_ed25519.pub (public).

Step 3: Secure the private key (permissions + passphrase guidance)

Wrong permissions can cause SSH to refuse the key. Set them explicitly.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
  • 700 on ~/.ssh: only you can read/write/enter the directory.
  • 600 on the private key: only you can read or write it.

Use a passphrase if the machine is shared or portable; you can cache it with ssh-agent so you type it once per session. Never share the private key or commit it to a repo.

Step 4: Add the public key to the remote server (ssh-copy-id and manual fallback)

Option A — ssh-copy-id (preferred when you can log in with a password once):

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostname

Replace user and hostname with your server user and host (or IP). Enter your password when asked. This appends your public key to ~/.ssh/authorized_keys on the server.

Option B — Manual: If ssh-copy-id is not available, copy the public key and append it on the server:

cat ~/.ssh/id_ed25519.pub

Log in to the server (e.g. with password), then:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "PASTE_THE_FULL_LINE_FROM_id_ed25519.pub" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Step 5: Test passwordless login

Connect; you should not be prompted for a password (only for the key passphrase if you set one).

ssh -i ~/.ssh/id_ed25519 user@hostname

Confirm you are on the server, for example:

whoami
hostname

Then exit:

exit

Verification

  • Key files exist: ls -la ~/.ssh shows id_ed25519 (600) and id_ed25519.pub.
  • Permissions: stat -c '%a' ~/.ssh is 700; stat -c '%a' ~/.ssh/id_ed25519 is 600 (Linux). On macOS use stat -f '%A' ~/.ssh and ~/.ssh/id_ed25519.
  • Login: ssh user@hostname (or ssh -i ~/.ssh/id_ed25519 user@hostname) succeeds without a password prompt and whoami on the server shows the correct user.

Troubleshooting

“Permission denied (publickey)“
The server is not accepting your key. Check: (1) the correct public key is in ~/.ssh/authorized_keys on the server (one full line, no line breaks); (2) ~/.ssh is 700 and authorized_keys is 600 on the server; (3) you are connecting as the user that owns that authorized_keys file. Enable server-side debug with ssh -v user@hostname to see which key is offered and why it is rejected.

“WARNING: UNPROTECTED PRIVATE KEY FILE!”
Your private key has overly open permissions. Run chmod 600 ~/.ssh/id_ed25519 (and chmod 700 ~/.ssh). SSH will not use keys with permissions like 644 or 755.

“Could not open a connection to your authentication agent”
You are trying to use ssh-add but no agent is running. Start one with eval "$(ssh-agent -s)" (or ssh-agent $SHELL), then run ssh-add ~/.ssh/id_ed25519 and enter your passphrase. On macOS, the agent often runs automatically when you need it.

Next steps

Continue to