A password is a single secret. Anyone who has it can log in, and it can be guessed, phished, reused from a breach somewhere else, or brute-forced given enough attempts. An SSH key pair works differently, and that difference is why keys are the recommended way to reach a server, not just a more technical alternative.
How SSH keys work
A key pair has two halves: a private key that never leaves your computer, and a public key that you upload to the server. When you connect, the server sends a cryptographic challenge that only the matching private key can answer. Your private key is never sent over the network, so there is nothing for an attacker to intercept, even on a compromised connection.
Why this beats a password
- Nothing to guess or brute-force. A password is a string an attacker can try to guess. A modern key is a cryptographic proof they simply do not have.
- It cannot be reused from a breach. Passwords are reused across sites and leaked in unrelated breaches. A key pair is generated fresh and is not tied to anything else you use.
- Revoking is instant and clean. Removing one public key from the server cuts off that access at once, without changing a password that other people or tools also use.
- The private key can have a passphrase. If the key file is copied off your machine it is still unusable without the passphrase, a second layer a plain password lacks.
- It resists the login attacks WordPress sites see. The constant guessing described in the brute-force guide is pointless against a service that only accepts keys.
How to switch to key-based access
1. Create a key pair. On macOS, Linux, or Windows 10 and later (PowerShell), run:
ssh-keygen -t ed25519 -C "my-laptop"
Accept the default location and set a passphrase when asked. This creates a private key (id_ed25519) and a public key (id_ed25519.pub). Never share or upload the private one. On older Windows, PuTTYgen does the same job.
2. Add the public key to your host. In cPanel, open SSH Access, then Manage SSH Keys, choose Import Key, and paste the public key text. After importing, click Manage next to it and Authorize. Other hosts have an "SSH Keys" or "SSH Access" section that works the same way. On a VPS you add the line to ~/.ssh/authorized_keys instead.
3. Test it. Connect with ssh -i ~/.ssh/id_ed25519 username@yourserver, adding -p and the port if your host uses a non-standard one. Make sure the key works before you change anything else, so you cannot lock yourself out.
4. Then turn off password login, if you control the server. On a VPS, set PasswordAuthentication no in the SSH server configuration and reload it. On shared hosting you usually cannot change this, so rely on the key plus a strong, unique account password.
Good habits with keys
- Use one key per device and per purpose. A separate key for each laptop and each service limits the damage if one is lost, and lets you revoke one without breaking the others.
- Keep a passphrase on every private key, and use an SSH agent so you only type it once per session.
- Label keys clearly so that in a year you know which one belongs to which tool or person.
- Remove keys you no longer use. Review the authorized list when a person leaves or a laptop is retired.
- Back up the private key safely, or be ready to generate a new one. If you lose it, you replace it; nothing on the server needs to change except the authorized list.
What if my host has no SSH?
Most shared, VPS and managed WordPress hosts support SSH, though some budget shared plans restrict it. If yours does, SFTP with a strong unique password, ideally with two-factor login on the hosting account, is the next best option. Check the install guide for how SSH access looks on different host types.
SiftWP connects the same way: with a dedicated SSH key created just for it and imported through your host's control panel. It never sees your WordPress admin password or your hosting account's main password. The key gives shell access to that one account only, never to server-wide controls, and you can revoke it at any time by deleting that single key in cPanel.