How to Generate SSH Key in Linux: The Complete Security Guide

I’ve watched too many servers get hammered by brute force attacks because someone thought “password123” was secure enough. Here’s the truth: if you’re still using password authentication for SSH, you’re playing Russian roulette with your server security. Let me show you how to generate SSH keys in Linux the right way – the way that’s saved my infrastructure countless times.

Why SSH Keys Beat Passwords Every Single Time

Before we dive into commands, let’s talk about why this matters. Password authentication is fundamentally broken for server access. I’m not being dramatic – the numbers back this up.

Research from USENIX shows that SSH brute force attacks are not only still prevalent but actually increasing on the IPv4 Internet. In one documented incident, analysts discovered 8,114 failed login attempts in just one minute. That’s your server being pummeled by automated bots trying to guess passwords around the clock.

SSH keys eliminate this risk entirely. Instead of a password that can be guessed, you’re using cryptographic keys that are mathematically impossible to brute force. A typical 4096-bit SSH key is the equivalent of a password that’s over 600 characters long. Good luck guessing that.

Understanding SSH Key Pairs: The 30-Second Version

When you generate an SSH key, you actually create two files:

• Private key – Stays on your local machine, never shared with anyone
• Public key – Gets copied to servers you want to access

Think of it like a lock and key system. The public key is the lock you install on your servers. The private key is the only key that can open it. When you connect, the server challenges your private key to prove it matches the public key – all without ever transmitting the private key over the network.

How to Generate SSH Key in Linux: The Modern Way

Here’s the command I use for generating SSH keys in 2025. Open your terminal and run:

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

Let me break down what’s happening here:

• ssh-keygen – The SSH key generation utility
• -t ed25519 – Specifies the Ed25519 algorithm (more on why this matters below)
• -C "your_email@example.com" – Adds a comment to identify your key

When you run this command, you’ll see a prompt asking where to save the key:

Enter file in which to save the key (/home/username/.ssh/id_ed25519):

For most cases, just hit Enter to accept the default location. Your SSH client automatically looks in ~/.ssh/ for keys, so using the default makes authentication seamless.

Setting a Strong Passphrase (Yes, You Should)

Next, you’ll be prompted to enter a passphrase:

Enter passphrase (empty for no passphrase):

Here’s where people get lazy. I get it – you want convenience. But adding a passphrase creates a second layer of security. Even if someone compromises your laptop and steals your private key, they still can’t use it without the passphrase.

Pick something strong but memorable. You can use ssh-agent to cache the passphrase so you only enter it once per session. More on that in a moment.

Ed25519 vs RSA: Why Your Key Type Matters

You might see older tutorials recommending RSA keys like this:

ssh-keygen -t rsa -b 4096

RSA still works fine, but Ed25519 is the better choice for 2025. According to cryptographic analysis, a 256-bit Ed25519 key provides equivalent security to a 3072-bit RSA key. That means:

• Faster key generation – Ed25519 keys are created almost instantly
• Faster authentication – Quicker logins and a smoother user experience
• Smaller key size – Less storage, easier to manage
• Modern cryptography – Based on elliptic curve cryptography that’s resistant to timing attacks

The only reason to use RSA is if you’re dealing with ancient systems that don’t support Ed25519 (anything before OpenSSH 6.5, which came out in 2014). For everything else, Ed25519 is the way to go.

What Just Got Created: Understanding Your New Keys

After generating your key, check what was created:

ls -la ~/.ssh/

You should see two new files:

• id_ed25519 – Your private key (keep this secret!)
• id_ed25519.pub – Your public key (safe to share)

The permissions on these files matter. Your private key should be readable only by you:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

If your private key permissions are too open, SSH will refuse to use it as a security precaution. I’ve seen this trip up beginners more times than I can count. If you need a refresher on file permissions, check out our Linux chmod command guide.

Copying Your Public Key to a Remote Server

Generating the key is only half the battle. Now you need to install your public key on the servers you want to access. The easiest way is using ssh-copy-id:

ssh-copy-id username@remote_server

This command does three things:

1. Connects to the remote server (using your password one last time)
2. Creates the ~/.ssh/authorized_keys file if it doesn’t exist
3. Appends your public key to that file with the correct permissions

After this completes, try logging in again:

ssh username@remote_server

If everything worked, you’ll authenticate with your key instead of a password. If you set a passphrase, you’ll be prompted for it (but only once if you’re using ssh-agent).

Manual Key Installation (When ssh-copy-id Isn’t Available)

Sometimes ssh-copy-id isn’t installed, or you’re setting up a service like GitHub that requires manual key upload. Here’s how to do it manually:

First, display your public key:

cat ~/.ssh/id_ed25519.pub

Copy the entire output (it should start with ssh-ed25519). Then on the remote server, add it to the authorized_keys file:

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

Those permissions are critical. SSH is paranoid about security (in a good way) and will refuse to use keys if the permissions are too permissive.

Using ssh-agent to Manage Your Passphrase

If you set a passphrase on your key (and you should), entering it every single time you connect gets old fast. That’s where ssh-agent comes in.

Start the agent:

eval "$(ssh-agent -s)"

Then add your key:

ssh-add ~/.ssh/id_ed25519

You’ll be prompted for your passphrase once. After that, ssh-agent remembers it for the duration of your session. No more repeated passphrase prompts, but you still get the security benefit.

Most modern Linux distributions start ssh-agent automatically when you log into your desktop environment, so you might not even need the first command.

Disabling Password Authentication: The Final Step

Once you’ve confirmed SSH key authentication works, you should disable password authentication entirely. This is what actually locks down your server against brute force attacks.

On your server, edit the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Find and modify these lines:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Then restart the SSH service:

sudo systemctl restart sshd

Now your server only accepts key-based authentication. Those bots hammering away with password attempts? They’re completely blocked. You can verify your SSH service is running correctly with our guide on checking systemd service status.

Managing Multiple SSH Keys

As you work with more servers and services, you might want different keys for different purposes. Maybe one for work servers, one for personal projects, one for GitHub.

Generate additional keys with custom names:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work@company.com"
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_github -C "personal@email.com"

Then create or edit ~/.ssh/config to specify which key to use for which host:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Host work-server
    HostName work.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_work

Now when you run ssh work-server, it automatically uses the correct key. This also works great when you’re managing multiple users on Linux systems with different access requirements.

Troubleshooting Common SSH Key Problems

Permission Denied (Publickey)

This usually means one of three things:

1. Wrong permissions – Check that ~/.ssh is 700 and private key is 600
2. Public key not on server – Verify your key is in ~/.ssh/authorized_keys on the remote server
3. SSH config issues – Make sure PubkeyAuthentication yes is set in /etc/ssh/sshd_config

Enable verbose mode to see what’s happening:

ssh -v username@remote_server

This shows you exactly which keys are being tried and where the authentication fails.

Agent Admitted Failure to Sign

This error means ssh-agent doesn’t have your key loaded. Run:

ssh-add -l

If you don’t see your key listed, add it with ssh-add ~/.ssh/id_ed25519.

Security Best Practices I’ve Learned the Hard Way

After managing Linux servers for over a decade, here are the SSH key habits that have kept my systems secure:

• Rotate your keys every 1-2 years – Security experts recommend creating new keys periodically and embedding the year in the filename (like id_ed25519_2025)
• Never share private keys – If someone needs access, they should generate their own key pair
• Use different keys for different security levels – Production servers get their own key, separate from dev environments
• Back up your private keys securely – I keep encrypted backups of my keys in a password manager. Losing access because your laptop died is not fun
• Monitor SSH access – Regularly check /var/log/auth.log for unusual authentication attempts

You can also verify your network configuration is secure by checking which ports are open on your system. SSH should be the only remote access method running.

The Bottom Line on SSH Keys

Generating SSH keys in Linux takes five minutes but delivers permanent security improvements. I haven’t worried about brute force attacks in years because key-based authentication simply works. Every server I manage has password authentication disabled, and I sleep better knowing that bots can pound on SSH all day long without getting anywhere.

The command is simple: ssh-keygen -t ed25519 -C "your_email@example.com". The impact is massive. Stop relying on passwords and make the switch today. Your future self – the one who doesn’t have to deal with a compromised server – will thank you.