Creating an SSH Key on Linux: Step-by-Step Guide

Introduction / Why This Is Needed

SSH (Secure Shell) is the standard protocol for secure remote management of servers and other devices. Traditional login/password authentication is vulnerable to brute-force attacks. Using asymmetric cryptography (a key pair) significantly improves security: to log in, you need to possess a private key that is never transmitted over the network.

After completing this guide, you will be able to:

• Connect to servers without entering a password every time.
• Set up secure access for automated scripts (CI/CD, backups).
• Eliminate one of the main attack vectors on your systems.

Requirements / Preparation

1. Operating System: Any modern Linux distribution (Ubuntu, Debian, CentOS, Fedora, Arch, etc.).
2. OpenSSH package: Must be installed. It is usually present by default.
3. Access to the target server: You will need:
   • The server's IP address or domain name.
   • The username of the user you want to log in as (usually root or your regular user with sudo).
   • A temporary password for that user (for the initial key copy).
4. Permissions on the local machine: You must have write access to your home directory (~).

Step 1: Checking for an SSH Client

Open a terminal and run the command to check the OpenSSH client version:

ssh -V

Example output:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022

If the command is not found, install the openssh-client package:

• Debian/Ubuntu: sudo apt update && sudo apt install openssh-client
• RHEL/CentOS/Fedora: sudo yum install openssh-clients or sudo dnf install openssh-clients

Step 2: Generating a Key Pair

The basic syntax for the ssh-keygen command:

ssh-keygen -t <key_type> -b <bits_size> -C "<comment>"

Recommended option (Ed25519):

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

• -t ed25519 — Key type. Ed25519 is considered the most secure and efficient today.
• -C "..." — Comment (usually an email or hostname) appended to the end of the public key. Useful for identification.
• By default, keys are saved in ~/.ssh/ with names id_ed25519 (private) and id_ed25519.pub (public).

Alternative option (RSA 4096):

ssh-keygen -t rsa -b 4096 -C "login@server-name"

Generation process:

1. You will be prompted to specify a file path to save the keys. Press Enter to use the default path (/home/username/.ssh/id_ed25519).
2. The system will ask for a passphrase to protect the private key on disk.
   • Recommendation: Set a strong password. This protects the key if someone gains access to your computer.
   • If you are setting up access for scripts or don't want to enter a password on every connection, leave the fields empty (press Enter twice).
3. After successful creation, you will see the key's fingerprint and a random ASCII art image.

Step 3: Setting Permissions (Often Not Required)

Modern versions of ssh-keygen automatically set correct permissions. But it's worth checking. Permissions must be as strict as possible:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519      # or id_rsa
chmod 644 ~/.ssh/id_ed25519.pub  # or id_rsa.pub

Why is this important? The SSH client will refuse to use keys with "weak" file permissions (e.g., if the private key is readable by the group or everyone) to prevent compromise.

Step 4: Copying the Public Key to the Server

The simplest method is the ssh-copy-id utility. It automatically appends the contents of your ~/.ssh/id_ed25519.pub to the ~/.ssh/authorized_keys file on the target server.

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip

• Replace username with your username on the server.
• Replace server_ip with the server's IP address or domain.
• You will be prompted to enter that user's password on the server (the very password you plan to replace with the key).

What the command does:

1. Connects to the server via SSH using the password.
2. Creates the ~/.ssh directory on the server (if it doesn't exist) with permissions 700.
3. Appends your public key to the end of the ~/.ssh/authorized_keys file (creates it if necessary).
4. Sets the correct permissions for files on the server.

If ssh-copy-id is not available: You can do it manually, but this is less reliable due to potential permission issues.

# 1. Copy the public key to the clipboard (or display it)
cat ~/.ssh/id_ed25519.pub

# 2. Manually on the server (via terminal or control panel):
#    mkdir -p ~/.ssh
#    echo "copied_key_contents" >> ~/.ssh/authorized_keys
#    chmod 700 ~/.ssh
#    chmod 600 ~/.ssh/authorized_keys

Step 5: Testing the Connection

Now try connecting to the server:

ssh username@server_ip

Possible scenarios:

1. If you set a passphrase: You will be asked to enter the passphrase (not the server user's password!). After that, you will log in to the server.
2. If no passphrase was set: The connection should be established instantly, without a password prompt.
3. If the connection fails: Proceed to the "Possible Issues" section.

Verifying the Result

You can verify success in two ways:

1. Direct test: Run the command ssh username@server_ip 'echo "Connection OK"'. If you see Connection OK, the connection works.
2. Check logs on the server: On the server, check the ~/.ssh/authorized_keys file. Your public key should be there (a single line starting with ssh-ed25519 AAAA... or ssh-rsa AAAAB3...).

Possible Issues

1. Error Permission denied (publickey,password).

• Cause: The server does not see your key or rejects it.
• Solution:
  • Ensure you copied the public key (.pub), not the private one.
  • Check that the ~/.ssh/authorized_keys file on the server contains exactly one line with your key (no extra spaces or line breaks).
  • Check permissions on the server: ls -ld ~/.ssh (should be drwx------) and ls -l ~/.ssh/authorized_keys (should be -rw-------). Fix with chmod if necessary.

2. Error Could not resolve hostname server_ip: Name or service not known

• Cause: The hostname is incorrect or there is a DNS problem.
• Solution: Verify the server's IP address or domain name. Try pinging it with ping server_ip.

3. Error Connection refused or Connection timed out

• Cause: The server is not accepting SSH connections (port 22 is blocked by a firewall, the sshd service is not running, the server is down).
• Solution: Check the server's status, ensure the SSH service (sshd) is running (sudo systemctl status sshd), and that the firewall rule allows port 22.

4. Prompt for the user's password instead of the key's passphrase

• Cause: The server is not accepting your key (see point 1), so the client falls back to password authentication.
• Solution: Fix the key issue. After that, a passphrase prompt will appear only if you set a passphrase.