Hardening SSH: ed25519 Keys and Disabling Passwords, Step by Step
Replace password login with an ed25519 key, then disable PasswordAuthentication and root login entirely. This shuts the door on the automated guessing attempts that hit every public server with tens of thousands of tries a month.
The single most important security step on any Linux server is to remove SSH password login and rely on cryptographic keys. The reason is direct: every server with a public address receives constant automated guessing attempts, tens of thousands a month from addresses worldwide trying common usernames and passwords. As long as password login is enabled, your door is open to the strength of your password, and one leaked or weak password is enough to breach you. A key changes the equation: it generates a pair, a private one that stays with you and a public one you place on the server, and only the holder of the private key can log in, a key that is practically impossible to guess. The direct answer in four steps: generate an ed25519 key, deploy the public one to the server, test logging in with it, then disable PasswordAuthentication and root login in the SSH config and restart the service. After that, guessing attempts are meaningless because the server accepts no passwords at all.
Why ed25519 Beats RSA
When you generate a key, you pick its algorithm. ed25519 is the modern recommended choice, and it beats traditional RSA for several practical reasons. An ed25519 key is very short (around 68 characters for the public part) compared to a 4096-bit RSA key, yet it provides equal or higher security. It generates faster, verifies faster, and is less prone to the configuration mistakes that weaken short RSA keys. The simple rule: always use ed25519 for new keys, and never generate RSA below 3072 bits if you must use it for legacy compatibility. The table shows the comparison:
| Criterion | RSA | ed25519 |
|---|---|---|
| Public key length | Long (multiple lines) | Short (one line) |
| Generation and verification speed | Slower | Faster |
| Security at default length | Needs 3072 bits or more | Strong by default |
| Configuration sensitivity | Higher | Lower |
Generating and Deploying the Key
You generate the key on your own machine, not on the server, because the private key must never leave your machine. The generation command creates two files: the private one (kept secret with strict permissions) and the public one with a .pub extension. Protect the private key with a strong passphrase, so even if your machine is stolen the key stays locked. Deploying means adding the public key to the authorized_keys file in the user account on the server, and the ssh-copy-id tool does this in one command. After deploying, test logging in with the key before anything else, this is a critical step: actually confirm you can log in with the key successfully before you disable the password, otherwise you may lock yourself out. This protection is fundamental to running any cloud server carrying your custom system.
Disabling Passwords and root Login
Once you have confirmed key login works, you edit the SSH config file to close the other doors. Set PasswordAuthentication to no so the server refuses any password login attempt entirely, making all guessing attacks futile. Set PermitRootLogin to no to block direct login as root, so an attacker does not even know the correct username, and every administrative action goes through a normal user who elevates with sudo, which leaves a trail in the logs. Also set PubkeyAuthentication to yes for confirmation. After each change restart the SSH service, and keep an open session during testing so you are sure you have not locked yourself out, then open a new session to verify.
The Real Role of Changing the Port
Many advise changing the SSH port from 22 to another number, and it is important to understand what this does and does not do. Changing the port does not raise your real security, since anyone with a scanning tool finds the new port in seconds. Its only benefit is practical: it reduces noise in your logs, because most automated guessing targets port 22 only, so moving off it makes thousands of noise attempts vanish from the log, which makes spotting a serious threat easier. Treat it as cleanup, not protection, and let the real protection come from keys and disabling passwords. Do not rely on port obscurity as a security layer, because it is not one.
Tying This to Server-Level Guess Blocking
Disabling passwords closes the guessing door, but it stays useful to block addresses that keep trying, to ease load and noise. This is where a tool like CrowdSec or fail2ban comes in, watching repeated failed logins and blocking their source at the firewall. The combination is strong: keys make guessing impossible, and the blocking tool ejects annoying scanners before they consume resources or fill your logs. Add regular system updates, and restrict which users may use SSH through AllowUsers, and you build a multi-layer defense around the most important door on your server.
Protecting the Private Key Itself
Your whole security hangs on the secrecy of the private key. Protect it with a passphrase, do not copy it to shared servers or services, and never push it to a code repository. Use a different key per machine where possible, so if one machine is compromised you revoke its key alone without regenerating everything. When an employee leaves, remove their public key from authorized_keys on the servers, since revoking access is done by deleting a key, not by changing a shared password.
Managing Keys in a Growing Team
When your server moves from one person's care to a team, key management becomes a matter of organization, not just security. Each member generates their own private key on their machine and gives you only the public one, so no shared key ever travels between machines. You collect the public keys of everyone who needs access and add them to authorized_keys, so you know exactly who has access by name. When a member leaves, you remove their public key alone, so their access ends instantly without disrupting the rest or changing anything for them. This separation is what makes the key model far cleaner than a shared password everyone knows and that is hard to change when someone departs.
In larger teams manual distribution gets tedious, so you turn to a configuration management tool that pushes the authorized_keys file to all servers from a single source. You edit the key list in one central place, it propagates consistently to dozens of servers, and you revoke someone's access everywhere in one step. This removes the risk of forgetting to delete a key on a forgotten server that stays an open door after its owner leaves.
The Key Agent and Forwarding
An SSH agent keeps your key unlocked in memory after you enter the passphrase once, so you do not retype it every connection. Useful, but be careful with agent forwarding: do not enable it toward servers you do not fully trust, because whoever controls that server could use your agent to connect elsewhere in your name. The rule: enable forwarding only toward servers you manage and trust, and leave it off by default. Good security does not mean complexity, it means clear decisions at the sensitive points.
What If You Lose Your Key
A question that worries many: what if I lose the machine holding my private key? This is why you always keep more than one way in: a backup key on another secure machine added in advance to authorized_keys, or access through the server's control panel that offers a terminal session independent of SSH. When a key is lost, you log in with the backup, remove the lost key from authorized_keys immediately to revoke its access, then generate a new one. Preparing for this scenario before it happens is the difference between a passing inconvenience and a full lockout from your server.
Also keep a clear record of which key sits on which server. Over time and across many servers, it is easy to forget an old key still added on a machine no longer in use, leaving a forgotten door. Review authorized_keys files periodically and remove every key whose owner or need you no longer recognize. Security is not built once and left, it is reviewed the way you review your accounts, since a forgotten key today can become a vulnerability tomorrow.
Conclusion: Practical Steps
Generate an ed25519 key on your machine and protect it with a passphrase, deploy the public one to the server with ssh-copy-id, and actually test logging in with the key. Disable PasswordAuthentication and PermitRootLogin in the SSH config and restart the service with a test session open. Change the port only to reduce noise, not as protection, add a guess-blocking tool like CrowdSec, and restrict users. If you run a custom system or corporate email on a Saudi server with roughly 8ms response time from Riyadh, review the pricing and plans and pick a plan that fits your load, or start with managed cloud hosting where secure access is set up from the start.
