← Back to Linux

SSH Keys: How to Generate, Add and Manage Them

SSH keys are cryptographic credentials that replace passwords for authentication. They consist of a public key (shared with servers) and a private key (kept secret on your machine). SSH keys are faster, more secure, and eliminate the need to remember complex passwords across multiple servers.

If you're managing Linux servers, understanding SSH keys isn't optional—it's essential. This guide walks you through generating, deploying, and managing SSH keys like a professional.

Why Use SSH Keys Instead of Passwords?

Passwords are convenient but vulnerable. Attackers use dictionary attacks, brute-force attempts, and credential stuffing to compromise accounts. SSH keys eliminate these risks through public-key cryptography.

Here's what makes SSH keys superior:

• Immunity to brute-force attacks: Keys are mathematically complex—no amount of guessing helps.
• No password transmission: Your private key never leaves your machine.
• Automation-friendly: Deploy SSH keys to automate deployments and backups without storing plaintext passwords.
• Audit trail: Track which keys accessed which servers and when.
• Per-server rotation: Compromise of one server doesn't affect your access to others if you use different keys.

Most enterprise environments disable password authentication entirely and enforce SSH keys. If you're serious about Linux, adopt this practice now.

Generating Your First SSH Key Pair

The standard tool for creating SSH keys is ssh-keygen. It's installed by default on macOS, Linux, and Windows (if you're using WSL or a recent build).

Basic Key Generation

Open your terminal and run:

ssh-keygen -t ed25519 -C "[email protected]"

This creates an ED25519 key pair, which is faster and more secure than older RSA-2048 keys. The -C flag adds a comment (typically your email) to identify the key later.

You'll see this prompt:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):

Press Enter to accept the default location. Then you'll be asked for a passphrase:

Enter passphrase (empty for no passphrase):

Here's the trade-off: A passphrase encrypts your private key, adding a security layer. Without it, anyone with file access to your private key can use it. With a passphrase, they'd also need to crack it. For most developers, a passphrase is worth the minor inconvenience.

After entering your passphrase twice, you'll see confirmation:

Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abcdef1234567890 [email protected]

Your keys are now generated. The .pub file is your public key—safe to share. The other file (without .pub) is your private key—guard it like a password.

Verifying Your Key Generation

Check what you've created:

ls -la ~/.ssh/

You should see:

-rw-------  1 user user  419 Jul 03 10:45 id_ed25519
-rw-r--r--  1 user user   98 Jul 03 10:45 id_ed25519.pub

Notice the permissions: The private key has mode 600 (read/write for owner only), and the public key has mode 644 (readable by all). SSH will reject your private key if permissions are too loose, so this is a security feature.

Adding Your Public Key to a Server

Now you need to place your public key on the Linux server you want to access. SSH looks for authorized keys in the ~/.ssh/authorized_keys file.

Method 1: Using ssh-copy-id (Easiest)

The simplest approach if you still have password access:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Replace user with your actual username and server.example.com with the server's IP or hostname. You'll be prompted for your password once, and the public key is automatically copied to ~/.ssh/authorized_keys.

Method 2: Manual Copy (When ssh-copy-id Isn't Available)

If ssh-copy-id isn't available, copy the key manually:

cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

This creates the ~/.ssh directory if it doesn't exist, appends your public key, and sets correct permissions. You'll be prompted for the password once.

Method 3: Manually on the Server

If you have direct access to the server or a control panel, connect and paste your key manually:

1. Display your public key: cat ~/.ssh/id_ed25519.pub
2. Copy the output (it's a single long line starting with ssh-ed25519).
3. SSH into the server and edit ~/.ssh/authorized_keys: nano ~/.ssh/authorized_keys
4. Paste your public key on a new line.
5. Save and exit (Ctrl+O, Enter, Ctrl+X in nano).
6. Set permissions: chmod 600 ~/.ssh/authorized_keys

Testing Your Access

Try connecting:

ssh [email protected]

If configured correctly, you'll log in without a password prompt. If it still asks for a password, check:

• Your private key permissions are 600 or 400.
• Your ~/.ssh directory permissions are 700.
• The server's ~/.ssh/authorized_keys has mode 600.
• The public key is exactly one line in the file with no extra spaces.

Enable verbose output to troubleshoot: ssh -vvv [email protected]

Managing Multiple SSH Keys

Most developers work with multiple servers or platforms (GitHub, GitLab, production, staging). Creating separate keys for each reduces risk—if one is compromised, you don't lose access everywhere.

Generating Additional Keys

Create a new key with a descriptive name:

ssh-keygen -t ed25519 -C "github-personal" -f ~/.ssh/github_personal

This saves the key as ~/.ssh/github_personal instead of the default. Follow the same prompts for passphrase.

SSH Config for Easy Management

Manually specifying the right key for each server is tedious. Use an SSH config file instead. Create or edit ~/.ssh/config:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/github_personal
  AddKeysToAgent yes
  IdentitiesOnly yes

Host production-server
  HostName 192.168.1.50
  User admin
  IdentityFile ~/.ssh/production_key
  Port 2222
  AddKeysToAgent yes
  IdentitiesOnly yes

Host staging-server
  HostName 192.168.1.51
  User admin
  IdentityFile ~/.ssh/staging_key
  AddKeysToAgent yes
  IdentitiesOnly yes

Now you connect with simplified commands:

ssh production-server
ssh github.com
git clone [email protected]:username/repo.git

SSH automatically uses the correct key based on the hostname. The AddKeysToAgent yes option adds your key to the SSH agent (explained next) automatically.

Set proper permissions on your config file:

chmod 600 ~/.ssh/config

Using SSH Agent for Passphrase Caching

If you've protected your keys with passphrases (recommended), typing the passphrase repeatedly gets annoying. The SSH agent solves this by caching passphrases for a session.

Start the agent:

eval "$(ssh-agent -s)"

Add your key:

ssh-add ~/.ssh/id_ed25519

You'll be prompted for the passphrase once. After this, SSH uses the cached passphrase until the agent stops (usually when you close your terminal or reboot).

On macOS, the SSH agent starts automatically and integrates with Keychain. On Linux, add the eval command to your shell startup file (~/.bashrc or ~/.zshrc) so the agent starts with every new terminal.

List cached keys with:

ssh-add -l

Security Best Practices

SSH keys are powerful, and mishandling them creates serious vulnerabilities.

Protecting Your Private Keys

• Always use passphrases: A compromised private key without a passphrase is immediately usable. A passphrase adds a second layer.
• Never commit keys to version control: Add .ssh/ and private keys to .gitignore. Use git-secrets or pre-commit hooks to catch accidental commits.
• Limit key permissions: Keep private keys at 400 or 600. SSH refuses to use improperly-permissioned keys.
• Back up securely: Store backups of private keys in encrypted vaults or hardware security keys, not plain cloud storage.

Public Key Distribution

• Share only the public key: The .pub file is meant to be distributed. Never share the private key.
• Verify key fingerprints: When adding a key to a server you don't fully trust, verify its fingerprint: