Ditch the Server Password: SSH Key Login and Disabling Password Auth, Step by Step

The Direct Answer: Why Replace Passwords With SSH Keys

Logging into your server with an SSH key instead of a password means swapping a guessable secret for a cryptographic key pair that is practically impossible to guess. A password is transmitted, stored, and guessable; an SSH key keeps its secret half on your own machine where it never leaves, and no actual secret crosses the network during login. In practice you generate a key pair on your machine, copy the public half to the server, then disable password login entirely in the sshd_config file. The result is that anyone trying to log in with a stolen or brute-forced password is rejected before they even start.

The security gap here is not cosmetic. A server exposed on port 22 with password login receives, on average, 2,000 to 5,000 automated login attempts per day from botnets cycling through leaked password lists. The moment you disable password authentication, every one of those attempts fails instantly regardless of whether the password is correct, because the server simply no longer accepts that method. An Ed25519 key delivers cryptographic strength equivalent to a 3072-bit RSA key, and breaking it with current computing would take longer than the age of the universe. This article explains the mechanism from the inside, then walks you through setup on a Saudi cloud server, and finally shows how to lock the door on passwords safely without locking yourself out.

How Public-Key Cryptography Actually Works

SSH key authentication rests on asymmetric cryptography, meaning you hold two mathematically linked keys: a public key and a private key. What one locks, only the other opens, and the private key cannot be derived from the public one. You publish the public key freely and place it on the server, while you guard the private key on your machine and never share it with anyone.

During connection, the private key is never sent across the network. Instead a challenge and response is exchanged: the server sends random data, your machine signs it with the private key, and the server verifies that signature using the stored public key. If the signature checks out, access is granted. This process repeats every session with fresh random values, so even if an attacker captured the entire network exchange, it would be useless for a future session.

Why a Key Beats a Password by Orders of Magnitude

• A 12-character random password gives roughly 72 bits of entropy at best, while an Ed25519 key delivers a security level equivalent to 128 bits, a gap of about 72 decimal digits in the number of possibilities.
• A password can be cracked by dictionary or brute-force attack; a 256-bit private key sits outside the reach of any realistic guessing attack.
• A password gets retyped on machines that might carry a keylogger; a private key is never typed by hand.
• A password often gets reused across services and leaks from the weakest one; each server gets its own independent key with no reuse.

Key Types: Which to Choose in 2026

Not all algorithms are equal, and the wrong choice leaves a hole. The rule today is simple: use Ed25519 as your first choice, or RSA at 4096 bits if you need compatibility with older systems, and ignore the rest.

Ed25519 (the recommended choice)

A modern algorithm built on elliptic curves, its key is small (about 68 characters on the line) yet its strength matches RSA-3072. Signing is faster, verification is faster, and its resistance to certain side-channel attacks is higher by design. Any modern server running OpenSSH 6.5 or newer (released in 2014) accepts it, and that covers every Linux distribution used on Cloud servers.

RSA-4096

The classic choice compatible with nearly everything, though its key is bulkier and its signing slower. Do not drop below 3072 bits, and 1024-bit RSA keys have been considered practically broken for years and are rejected by updated systems. If you have an old 2048-bit RSA key, treat it as tolerable for now but plan to upgrade it.

The DSA and ECDSA algorithms are best avoided: DSA was formally removed from OpenSSH as of version 7.0, and ECDSA relies on curves that raise concern about how their constants were generated. Sticking with Ed25519 spares you all of that. For context, more than 90% of newly generated SSH keys on GitHub today are either Ed25519 or RSA-4096.

Generating the Key on Your Machine

The process takes under a minute. On macOS or Linux open the terminal, and on Windows use PowerShell or Windows Terminal, since OpenSSH has shipped built in since Windows 10. The core command is:

ssh-keygen -t ed25519 -C "laptop-2026"

The t option sets the algorithm type, and the C option adds a comment that helps you identify the key later, such as the machine name. The command asks where to save, defaulting inside the .ssh folder as id_ed25519 for the private key and id_ed25519.pub for the public one.

The Passphrase: Do Not Skip It

ssh-keygen prompts for a passphrase that protects the private key itself. This is an important second layer: if the private key file is stolen from your machine, the passphrase remains a barrier that prevents its use. Skipping it means anyone who reaches your machine gets straight into your server. Use a strong passphrase and let the key agent (ssh-agent) hold it for the session so you do not retype it on every connection. Enabling ssh-agent and adding the key takes two commands, so you type the passphrase once a day instead of every login.

After generation you have two files. The public key (with the pub extension) is the only part that goes to the server, and the private key stays on your machine with 600 permissions, meaning read and write for the owner only. SSH refuses to work with a private key whose permissions are open to others, and this is a deliberate safety check.

Copying the Public Key to a Cloud Server

The easiest way is one command from your machine:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your-server-ip

It asks for the server password one last time, then adds your public key to the ~/.ssh/authorized_keys file on the server with the correct permissions automatically. Then try to log in: ssh root@your-server-ip, and it lets you in without asking for the server password, prompting only for your local key passphrase if you set one. This moment is the decisive test: do not proceed to the next step until you confirm that key login works.

If ssh-copy-id is not available, which is rare on Windows, you copy the contents of the pub file manually and paste it as a separate line inside authorized_keys on the server. What matters is that the whole key sits on one line, that the ssh folder has 700 permissions, and that authorized_keys has 600, otherwise SSH silently refuses to use it. On managed Cloud servers these permissions are set correctly by default at provisioning time, sparing you these pitfalls.

Disabling Password Login: Locking the Door

This is where the big win lands. As long as password login stays enabled, having a key does not stop anyone from trying passwords. The setting lives in the /etc/ssh/sshd_config file on the server. Edit or add the following lines:

• PasswordAuthentication no: blocks password login entirely.
• PubkeyAuthentication yes: confirms key authentication is enabled.
• PermitRootLogin prohibit-password: lets root in by key only, not password, or set it to no if you use a normal user with sudo.
• ChallengeResponseAuthentication no: closes an alternate auth path that could indirectly reopen passwords.

After editing, restart the service with systemctl restart sshd. The golden rule that saves you from locking yourself out: open a second, fresh SSH session and confirm it logs in by key before you close your first session. As long as your current session stays open, you can still roll back if you got the configuration wrong.

Extra Hardening Worth the Minutes

• Change the SSH port from 22 to a non-standard number; it does not raise security fundamentally but cuts log noise by over 95% because automated scanners target port 22.
• Enable fail2ban to ban any IP that repeats failed attempts, blunting even attempts against keys.
• Use a firewall (ufw or nftables) that allows the SSH port only from trusted addresses where possible.
• Review authorized_keys periodically and remove any key for an old machine or a departed employee.

Security With a Saudi Server: The Complementary Layer

SSH keys protect the way you log in, but the server location protects the data itself. Cloud servers in Riyadh give you around 8ms latency inside the Kingdom versus 100 to 120ms for foreign servers, which means an SSH session responds instantly with no perceptible lag, making interactive work on the server smooth. More importantly, keeping data inside the Kingdom serves National Access requirements and governance compliance, which matters to organizations running sensitive custom systems.

Automatic provisioning on Cloud activates the server within seconds of payment, letting you upload your public key and lock down the password before the server receives any external login attempt. Combining key authentication, a non-standard port, fail2ban, and a firewall shrinks the attack surface to the point where the server is practically invisible to the random automated attacks that make up the overwhelming majority of break-in attempts on the internet today.

The engineering takeaway: generating an Ed25519 key, copying it, and disabling passwords takes no more than five minutes, but it lifts login security from a level that is automatically crackable to one that requires physically stealing your machine. Start with it on the first server you spin up, and make it a fixed habit on every machine you provision.