SSH keys: create, install on the server and turn off password login

Updated 4 October 2026 10 min read Читати українською

Contents

For an administrator who still signs in to a Linux server with a password. By the end you will sign in with an ed25519 key, and password login over SSH will be turned off.

What you need#

The server address, user name and password — support sends you these access details. The examples use the documentation values 203.0.113.10 and admin.
An OpenSSH client on your computer. macOS and Linux already have one; in Windows 10 (version 1809 and later) and Windows 11 it is built in. To check, open PowerShell and run ssh -V. If the command is missing, search the Start menu for “Optional features” and add “OpenSSH Client”.
A server running Debian or Ubuntu. On other distributions the steps are the same, but the service may be called sshd. If you work as root, you can leave out sudo.
An open SSH session on the server that you will not close until the final check.

A key is a pair of files. The private key stays on your computer and is never handed to anyone. The public one (.pub) can be copied freely: it is written to the file ~/.ssh/authorized_keys on the server.

Step 1 Generate an ed25519 key#

The command is the same in PowerShell on Windows and in the terminal on macOS and Linux. Run it on your own computer, not on the server:

ssh-keygen -t ed25519 -C "admin@example.com"

The -C option sets a comment that identifies the key on the server: say whose it is. State the key type explicitly: OpenSSH before 9.5, still found on Windows 10 and older Linux releases, creates an RSA key by default.

When asked for a file, press Enter: the key is saved as ~/.ssh/id_ed25519 (on Windows, %USERPROFILE%\.ssh\id_ed25519). If that file already exists, do not overwrite it — choose another name with -f. Next to it appears id_ed25519.pub, the public key: a single line starting with ssh-ed25519.

Windows PowerShell may not expand ~ in command arguments: if a file is not found, write $env:USERPROFILE\.ssh\ instead of ~/.ssh/.

Step 2 Passphrase and ssh-agent#

At the Enter passphrase prompt type a passphrase; do not leave it empty. It encrypts the private key on disk: if the laptop is stolen or the file is copied, the key is useless without the passphrase. You can change the passphrase with ssh-keygen -p -f ~/.ssh/id_ed25519.

To avoid typing the passphrase on every connection, add the key to ssh-agent, which keeps the decrypted key in memory.

Linux#

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

macOS#

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

The passphrase is stored in the macOS Keychain.

Windows#

The ssh-agent service is disabled by default in Windows. Enable it once in PowerShell started as administrator:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Then, in an ordinary PowerShell window:

ssh-add $env:USERPROFILE\.ssh\id_ed25519

ssh-add -l shows which keys the agent holds.

Step 3 Copy the public key to the server#

On macOS and Linux ssh-copy-id does this: it creates the ~/.ssh directory and the authorized_keys file on the server if they are missing, and appends the key.

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

Windows has no such tool, so do the same by hand from PowerShell:

$key = Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"
ssh admin@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '$key' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

In both cases the server asks for the password one last time.

Directory and file permissions#

The server ignores authorized_keys if that file, the ~/.ssh directory or the home directory is writable by other users or owned by someone else (the StrictModes option, on by default). Fix and check the permissions on the server:

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

All three lines must show your user as the owner. If the directory was created with sudo and belongs to root, fix it: sudo chown -R admin:admin /home/admin/.ssh.

Step 4 Describe the server in ~/.ssh/config#

To avoid memorising addresses and names, create the file ~/.ssh/config on your computer (on Windows, %USERPROFILE%\.ssh\config, with no .txt extension):

Host srv-pl
    HostName 203.0.113.10
    User admin
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Now typing ssh srv-pl is enough. The line IdentitiesOnly yes makes the client offer only the named key, which matters once you have several. On macOS, add a Host * block at the end of the file with the lines AddKeysToAgent yes and UseKeychain yes so that the passphrase comes from the Keychain. Linux and Windows have no UseKeychain option — do not add that line there.

Do not close the current session. Open a new terminal window and connect so that the client cannot fall back to the password:

ssh -o PreferredAuthentications=publickey srv-pl

If you land on the server, the key works. An Enter passphrase for key prompt asks for the key’s passphrase and is expected. An admin@203.0.113.10's password: prompt must not appear with this option. Permission denied means the server did not accept the key: find the cause (see “Common mistakes”) and do not move on to the next step.

Step 6 Turn off password login#

Warning. A mistake at this step can lock you out of the server. First make sure key login worked in step 5 and read the rollback procedure at the end of this step. Do not close the current session until you have completed “How to check the result”.

See where these options are already set:
```
grep -n '^Include' /etc/ssh/sshd_config
sudo grep -rniE 'passwordauthentication|kbdinteractiveauthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
```
The first command should print the line Include /etc/ssh/sshd_config.d/*.conf from the top of the file. If it is missing, sshd does not read the sshd_config.d directory: put both lines from item 2 at the very top of sshd_config instead, and to roll back delete them from there. On Ubuntu the second command often finds the file 50-cloud-init.conf with the line PasswordAuthentication yes: cloud-init creates it on the first boot. Lines starting with # are comments.
Create your own file with a number lower than 50:
```
sudo tee /etc/ssh/sshd_config.d/10-password-off.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
```
The number matters. For each option sshd uses the first value it finds, and it reads the files in sshd_config.d in alphabetical order, before the rest of the main file. So 10-password-off.conf wins over 50-cloud-init.conf, while a 99-… file or a line further down in sshd_config itself does not. Do not edit the cloud-init file: cloud-init may rewrite it when the system is initialised again.
Check the syntax and the effective values:
```
sudo sshd -t
sudo sshd -T | grep -Ei '^(pubkey|password|kbdinteractive)authentication'
```
The first command prints nothing on success. The second should show pubkeyauthentication yes, passwordauthentication no and kbdinteractiveauthentication no. If the password line still says yes, some file sorts before yours — find it with the second command from item 1.
Restart the service. On Debian and Ubuntu it is called ssh:
```
sudo systemctl restart ssh
```
A restart does not drop open sessions. On Ubuntu from 22.10 onwards (so in 24.04 LTS and 26.04 LTS too) systemd listens on the port through ssh.socket and starts sshd on the first connection. For authentication options restart ssh is enough; ssh.socket is restarted (after systemctl daemon-reload) only when you change the port or the address.

Rollback. If a new session will not open, run this in the old one:

sudo rm /etc/ssh/sshd_config.d/10-password-off.conf
sudo sshd -t && sudo systemctl restart ssh

How to check the result#

In a new terminal window on your computer run two commands in turn:

ssh srv-pl
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive admin@203.0.113.10

The first must let you in with the key; leave with exit and run the second. It must end with Permission denied (publickey) without asking for a password. Only then close the old session. Keep the account password: you still need it for sudo and for console login.

A separate key for every administrator#

Each administrator generates a pair on their own computer and hands over only the .pub file. One private key for everyone is a shared password that cannot be revoked for just one person.
Ideally give everyone their own account. If the account is shared, each key is a separate line in the authorized_keys file with a clear comment.
ssh-keygen -lf ~/.ssh/authorized_keys lists keys with fingerprints and comments. To find keys on the server: sudo sh -c 'ls -l /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys'.
To revoke a key, delete its line from authorized_keys on every server and in every account where it was installed. The server refuses new connections with that key at once; no restart is needed. Open sessions are not dropped — check them with who.

If a key is lost#

Keep at least two keys on the server: a second administrator’s, or a spare one stored away from your work computer. Then, if a laptop is lost, you sign in with the other key, delete the lost key’s line and add a new one. The passphrase on the lost key buys you time for that.

If no working key is left, you cannot get in over SSH: password login is off. Contact technical support, available around the clock: phone +38 044 206 08 08, email info@united.net.ua. The remote console is available on request through support: there you sign in with the account password (sshd settings do not affect the console) and add a new key. The Lite line has no remote console: there, on request, support reboots the server into rescue mode — a temporary system reachable over SSH, where you mount the disk and add the key.

Common mistakes#

Wrong permissions or owner: The key has been copied, but the server still asks for the password or answers Permission denied. On the server, sudo journalctl -u ssh -n 20 will show Authentication refused: bad ownership or modes. Repeat the commands from “Directory and file permissions”.
The wrong key: The client offers a different key, or the public key was added to the wrong user (for example root instead of admin). ssh -v srv-pl shows which keys the client offers. Compare the fingerprint from ssh-keygen -lf ~/.ssh/id_ed25519.pub on your computer with the output of ssh-keygen -lf ~/.ssh/authorized_keys on the server. The Too many authentication failures message is cured by IdentitiesOnly yes.
The session was closed before the check: The costliest mistake: there is nowhere left to fix the configuration from. What remains is the console on request through support.
Ubuntu still accepts passwords: The option was written into the main sshd_config or a 99-… file, and 50-cloud-init.conf takes effect first. Check the output of sudo sshd -T.

What next#

Basic protection for a Linux server: SSH, firewall, updates.
First login to a Linux server over SSH: what to do in the first hour.
OpenSSH manual: ssh-keygen, sshd_config, ssh_config.
Servers in stock are in the catalogue; the countries are compared on the locations page.