Log in with SSH keys and disable password authentication

Any server with SSH open to the internet receives automated password-guessing attempts around the clock. With key-based authentication, those attempts are pointless: the server only accepts a login from someone who holds your private key. This guide sets up keys, then disables passwords without cutting off your way back in if something goes wrong.

Generate a key pair

Use Ed25519: the keys are short, fast and supported by every current OpenSSH release. Create the key pair on your own computer, never on the server.

Linux and macOS

ssh-keygen -t ed25519 -C "you@laptop"

Accept the default location, ~/.ssh/id_ed25519, and set a passphrase. The passphrase encrypts the private key on disk; an agent lets you type it once per session instead of on every connection. On macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 stores it in the keychain.

Windows 10 and 11

The OpenSSH client is built in. In PowerShell:

ssh-keygen -t ed25519 -C "you@laptop"

The private key is saved as %USERPROFILE%\.ssh\id_ed25519, the public key as id_ed25519.pub next to it. To use the agent, run Get-Service ssh-agent | Set-Service -StartupType Automatic once in an elevated PowerShell, then Start-Service ssh-agent and ssh-add.

Only the .pub file ever leaves your computer. If a private key is copied somewhere it should not be, treat it as compromised and replace it.

Install the public key on the server

The examples use the account deploy (created in First steps) and the address 203.0.113.10. For root, use root@ instead.

With ssh-copy-id (Linux and macOS)

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

It logs in with the account password once and appends the key to ~/.ssh/authorized_keys on the server, creating the directory and file with safe permissions if they do not exist yet.

From Windows, or by hand

Windows has no ssh-copy-id. This PowerShell command does the same job:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

You can also paste the content of the .pub file, as a single line, at the end of ~/.ssh/authorized_keys on the server.

Check permissions

sshd ignores keys stored in files that other users can write to. On the server, as the user who will log in:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

The home directory must not be group- or world-writable either. On AlmaLinux and Rocky Linux, run restorecon -Rv ~/.ssh if you created or moved the files by hand, so that SELinux lets sshd read them.

Now log in with ssh deploy@203.0.113.10. If you are asked for the key’s passphrase, or for nothing at all, the key works. If you are asked for the account password, it does not: fix that before going further. ssh -v shows which keys your client offers and how the server answers.

Disable password authentication

Run this part as root (sudo -i). Current Ubuntu, Debian, AlmaLinux and Rocky Linux releases include every *.conf file from /etc/ssh/sshd_config.d/ at the top of sshd_config. For most settings, sshd keeps the first value it reads, so a drop-in file whose name sorts first wins. Create /etc/ssh/sshd_config.d/00-keys-only.conf with your editor:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

prohibit-password still lets root log in with a key. Use PermitRootLogin no once you only log in as your sudo user. Look for older settings that could conflict, then validate the configuration:

grep -ri -E 'passwordauthentication|permitrootlogin' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
sshd -t

sshd -t prints nothing when the configuration is valid. Some images ship files such as 50-cloud-init.conf that set PasswordAuthentication yes; the 00- prefix makes your file win, but removing the old line avoids confusion later. Apply the change; open sessions are not interrupted:

systemctl reload ssh

On AlmaLinux and Rocky Linux, the service is called sshd: systemctl reload sshd. Then check the values sshd actually uses:

sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

You should see passwordauthentication no. prohibit-password may be displayed under its older name, without-password.

Test in a second session before you log out

1. Open a new terminal and log in with your key. ssh deploy@203.0.113.10 must work.

2. Check that passwords are refused. Force password authentication:

   Shell

   ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password deploy@203.0.113.10

   The expected answer is Permission denied (publickey).

3. Only then close the original session.

If the first step fails, delete 00-keys-only.conf from the session that is still open, reload sshd, and check the key and the permissions again.

Save typing with an SSH config alias

On your computer, add an entry to ~/.ssh/config (on Windows, %USERPROFILE%\.ssh\config):

Host web1
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Now ssh web1 is enough, and tools that run over SSH, such as scp, rsync and git, accept the same alias. IdentitiesOnly yes stops the client from offering every key in your agent, which avoids “Too many authentication failures” errors.

Locked out? Recover with the IPMI console

sshd settings only apply to network logins. The local console still accepts the root password, so the IPMI/KVM console is your way back in:

1. Open the console. In your dashboard, open the server, then choose Console (IPMI).

2. Log in as root with the root password.

3. Undo the change and reload sshd (sshd on AlmaLinux and Rocky Linux):

   Shell

   mv /etc/ssh/sshd_config.d/00-keys-only.conf /root/
   systemctl reload ssh

4. Fix the cause, usually a missing key or wrong permissions, then put the file back.

The console needs a password, so a root account without one cannot log in there. That can happen when a server was installed with an SSH key only. Set a strong root password now with passwd and store it in your password manager: SSH keeps refusing passwords, but the console will accept it. Without a password, use rescue mode to set one or to repair the files.

Next steps

Continue with server hardening. If you also move SSH to another port, allow the new port in your firewall first. On Ubuntu, check systemctl status ssh.socket: when the socket unit is active, a port change also needs systemctl daemon-reload and systemctl restart ssh.socket.

Still stuck? Open a ticket from Support and include the output of ssh -v.