Linux SSH Key Login: Set Up ed25519 Keys and Disable Password Authentication

Password logins are the number one target of SSH brute-force bots, and any server with a public IPv4 address starts seeing them within minutes of going online. This guide shows how to set up Linux SSH key login with a modern ed25519 key and then disable SSH password authentication without locking yourself out. The steps work on Debian 11/12, Ubuntu 20.04/22.04/24.04, CentOS 7 and Rocky Linux / AlmaLinux 8 and 9, whether your JUSTG cloud server runs in Johannesburg, Moscow, Tokyo or Seoul, or on a dedicated server.

Step 1: Generate an ed25519 SSH Key Pair on Your Computer

Create the key on the machine you connect from, never on the server. ed25519 keys are short, fast and supported by every current OpenSSH release. A passphrase protects the private key if your laptop is lost or stolen; an SSH agent can remember it so you only type it once per session.

# On your own computer (Linux, macOS, or Windows 10/11 PowerShell)
ssh-keygen -t ed25519 -C "laptop-2026"
# Press Enter to accept ~/.ssh/id_ed25519, then set a passphrase

You now have two files: id_ed25519 (private, keep it secret) and id_ed25519.pub (public, safe to copy to servers).

Step 2: Copy the Public Key to the Server

The easiest method on Linux and macOS is ssh-copy-id. It logs in with your current password one last time and appends the key to ~/.ssh/authorized_keys on the server.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
# Custom port example:
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

Windows does not ship ssh-copy-id, but you can pipe the key over SSH from PowerShell:

# Windows PowerShell (ssh-copy-id is not included on Windows)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 3: Add the Key Manually and Fix authorized_keys Permissions

If you prefer to paste the key yourself, or you are working in the VNC console, create the file by hand. OpenSSH silently ignores authorized_keys when the directory or file is writable by other users, so the permissions matter as much as the key itself.

# On the server, as the user that will log in
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys      # paste ONE key per line, then save
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
# CentOS / Rocky / AlmaLinux with SELinux enforcing:
restorecon -Rv ~/.ssh

Step 4: Test SSH Key Login Before Changing Anything

Open a new terminal and connect while forcing key-only authentication. If you are logged in without a password prompt (other than the key passphrase), the key works.

ssh -i ~/.ssh/id_ed25519 -o PasswordAuthentication=no [email protected]

Step 5: Disable SSH Password Authentication in sshd_config

Modern distributions read /etc/ssh/sshd_config.d/*.conf through an Include line at the top of the main file, and sshd keeps the first value it reads for each option. That is why a file such as 50-cloud-init.conf containing PasswordAuthentication yes can quietly override your edit further down in sshd_config. A drop-in whose name sorts first avoids this problem.

# Check that the drop-in directory is included
grep -i '^Include' /etc/ssh/sshd_config

# Create a drop-in that sorts first (sshd keeps the FIRST value it reads)
cat > /etc/ssh/sshd_config.d/01-key-only.conf <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

# Look for files that still turn passwords back on (e.g. 50-cloud-init.conf)
grep -ri 'PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

On CentOS 7 and other older systems without the sshd_config.d directory, put the same four lines directly into /etc/ssh/sshd_config and comment out any earlier PasswordAuthentication yes. PermitRootLogin prohibit-password keeps root login available with a key only; use no if you log in as a normal sudo user.

Step 6: Validate the SSH Config and Reload the Service

# Validate syntax first - no output means OK
sshd -t
# Show the effective values
sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin|kbdinteractive'

# Debian / Ubuntu
systemctl reload ssh
# CentOS / Rocky / AlmaLinux
systemctl reload sshd

A reload keeps your current session alive, but it is still only half the test.

Step 7: Test in a Second Session Before Closing the First

# From a NEW terminal on your computer
ssh [email protected]
# Must be refused:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]
# Expected: Permission denied (publickey).

If something fails, use the still-open first session to fix the drop-in file and reload again. If you have already lost access, log in to the JUSTG client area, go to My Products & Services, select the VPS and open its management panel to use the VNC console; if you cannot find it, submit a ticket.

FAQ

Is ed25519 better than RSA for SSH keys?

For new keys, yes. ed25519 offers strong security with a much shorter key and faster handshakes. Use RSA 4096 only if you must connect to a very old system that does not support ed25519.

I still get a password prompt after setting everything up. Why?

Run sshd -T | grep -i passwordauthentication. If it prints yes, another file in sshd_config.d is read before yours. Also check /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (Rocky/AlmaLinux) for "bad ownership or modes" messages about ~/.ssh.

How do I use the same key on several JUSTG servers?

Copy the same public key to each server with ssh-copy-id. Keep the private key only on your own devices, and remove a lost device by deleting its line from authorized_keys.

If you still cannot log in with your SSH key, please submit a ticket at https://www.justg.com/submitticket.php and the JUSTG technical support team will help you.