Disable password-based SSH logins and use certificates

Once key-based login works, the server no longer needs to accept passwords over the network. This stops anyone from attempting to guess passwords. In this section, you will securely disable password and root logins. Finally, you will see how SSH certificates make it easier to manage access across multiple servers.

Prerequisites

• Key-based login works, see [[SSH Level 2 - Keys instead of passwords|SSH Level 2]].
• Your user has sudo privileges, see [[Server Installation Level 4 - Prepare the Server|Prepare the Server]].
• The console in Proxmox is open. It serves as a backup method if you lock yourself out of SSH.

Disable password and root login

The SSH service reads settings from /etc/ssh/sshd_config and files in the directory /etc/ssh/sshd_config.d/. Create a separate file so it is easy to see what you have changed and how to revert it:

sudo nano /etc/ssh/sshd_config.d/10-sikker.conf

Enter:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no disables standard password authentication. KbdInteractiveAuthentication no also disables keyboard interactive authentication, which otherwise can accept passwords through PAM. PermitRootLogin no completely disables root login.

For most SSH settings, the first value read by the service applies. Your file therefore does not automatically override other files: the placement of Include, previous settings, and any Match blocks may affect the outcome. Verify the effective values before applying the change.

Verify the settings before loading them in:

sudo sshd -t

If no message is returned, the syntax is valid. Then check which values the new configuration produces:

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

All three should show no. If you get other values, inspect /etc/ssh/sshd_config and the files it includes before proceeding. With Match rules, also verify the current connection using sudo sshd -T -C user=user,addr=CLIENT_IP,host=HOSTNAME; replace the example values with the user, client address, and hostname for the login you are testing. Perform the same check on the three settings.

Once the values are correct, apply the change by reloading:

sudo systemctl reload ssh

Do not close the window you are logged into. Open a new terminal window and test:

ssh debian-vm                 # should work
ssh root@SERVER-IP            # should be rejected
ssh -o PubkeyAuthentication=no user@SERVER-IP   # should be rejected, no password prompt

You still need the user’s password for sudo. It is written on the server, not over the network.

Deep Dive: SSH Certificates

With ten servers and five administrators, each key must reside on every server. This results in fifty entries in authorized_keys, and when someone leaves, their key must be removed everywhere.

With certificates, a certificate authority (CA) signs your key. The servers trust the CA, not each individual key. The certificate also contains:

• principals: the names the certificate applies to, for example admin
• validity period: when the certificate stops working

Set up the server

You need the public key from whoever operates the CA (for example, the teacher). Place it on the server:

sudo nano /etc/ssh/lab_user_ca.pub

Determine which principals are allowed to sign in as user user:

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Tell the SSH service about the CA:

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u is replaced with the username being logged in as. Verify and load with sudo sshd -t and sudo systemctl reload ssh.

Log in with the certificate

The certificate is located next to the private key and ends with -cert.pub. See what it contains:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Look for Principals, Valid, and Signing CA. Add the certificate to ~/.ssh/config:

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Now you log in with ssh debian-vm even though your key is not present on the server’s authorized_keys.

How a CA signs (from the perspective of the CA operator)

ssh-keygen -t ed25519 -f lab_user_ca                  # create the CA key once, store it securely
ssh-keygen -s lab_user_ca -I student@school -n admin -V +52w id_ed25519.pub

-n is for principal names, -V is for validity period, and -I is an ID that appears in the server logs. The private CA key provides access to all servers that trust it, so it should never be stored on a server or shared.

If something goes wrong

1. You are locked out: Log in to the Proxmox console, delete the file you created in /etc/ssh/sshd_config.d/, and run sudo systemctl reload ssh.
2. sshd -t returns an error message: The message shows the file and line number. Fix the typo before loading it.
3. The certificate is not accepted: Check that the principal in the certificate (ssh-keygen -L) is listed in /etc/ssh/auth_principals/user, and that the certificate has not expired. On the server, sudo journalctl -u ssh -n 20 will show why the login was rejected.

Key concepts

Checks

• ssh root@SERVER-IP is rejected.
• Password login via SSH is rejected.
• You can explain why you tested in a new window before closing the old one.
• Deep dive: you can explain why a CA is simpler than authorized_keys on many servers.

Source: OpenSSH – sshd_config.