Halt the SSH logins and use certificates

When key login works, ye no longer need the ship to accept passwords o’er the wire. That stops all them who try guessin’ at passwords. In this part ye shut off password an’ root loggin’ safe-like. At last ye see how SSH certificates make it easier to manage access to many ships.

Prerequisites

• Key login works, see [[SSH Level 2 - Keys instead of passwords|SSH Level 2]].
• Yer be has got sudo on ‘im, see [[Server Installation Level 4 - Make the server ready|Make the server ready]].
• The console in Proxmox is open. She’s yer backup route if ye get locked outta SSH.

Turn off password an’ root loggin’

The SSH service reads its settings from /etc/ssh/sshd_config an’ files in the folder /etc/ssh/sshd_config.d/. Create yer own file, so it’s easy to spot what ye’ve changed an’ undo it if needs be:

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

Avast ye landlubbers! Enter yer orders here, matey!

# No Password Authentication, ye scurvy dog!
# No Keyboard Interactive Authentication, matey!
# Permit Root Login? Nay, avast!
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no shuts down plain password authentication. KbdInteractiveAuthentication no also plugs up keyboard interactive authentication, which otherwise might accept passwords through PAM. PermitRootLogin no blocks root login entirely.

For most SSH settings, the first value the service reads be what stands. Thy file doth not automatically triumph o’er other scrolls: the placement o’ Include, prior configurations, and any Match blocks may alter the outcome. Check the effective values before ye load in the changes.

Check the settings afore ye load ‘em in:

sudo sshd -t

If no message be received, then the syntax be valid. Now see which values the new configuration yield!

# Arr, me hearties! Be checkin' fer root login an' password auth settings, ye scallywag! #
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

All three shall show no. If ye be gettin’ other values, inspect /etc/ssh/sshd_config an’ th’ files it includes afore ye proceed. With Match rules, check th’ current connection usin’ sudo sshd -T -C user=user,addr=CLIENT_IP,host=CLIENTNAME; replace th’ example values with th’ user, client address, an’ hostname o’ th’ login ye be testin’. Do th’ same checks fer all three settings.

Once th’ values be correct, load th’ changes:

# Reloads the SSH service as a mighty captain would command his crew!
sudo systemctl reload ssh

Do ye be shuttin’ the window yer logged into. Open a fresh terminal an’ give this a try:

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

Ye need ye be still got that password fer user t’ use wid sudo. It gets writ on th’ ship’s log, nay sent o’er th’ seas.

Deep Dive: SSH Certificates

With ten servers an’ five administrators, every key’s gotta be on each ship. That makes fifty entries in authorized_keys, an’ when a mate leaves the crew, ye gotta rip that key from everywhere.

With certificates, a Certificate Authority (CA) signs yer key. The ships trust the CA, not each individual key. The certificate also holds:

• principals: the names this cert applies to, like admin
• validity period: when the cert stops workin’

Set up the ship’s riggin’

Ye need th’ public key from whoever runs th’ Certificate Authority (like th’ ol’ captain or first mate). Stow it on board th’ server:

The provided code block contains no comments; therefore, it is returned unchanged as per the requirement to preserve all non-comment content exactly.

sudo nano /etc/ssh/lab_user_ca.pub

Identify which principals be permitted to sign on as the scallywag user.

# Arr! Create the directory for auth principals at the specified location
mkdir -p /etc/ssh/auth_principals
# Shiver me timbers! Pipe the 'admin' credentials into the user file using tee
echo admin | sudo tee /etc/ssh/auth_principals/user

Tell the SSH service about the cap’n:

# Arr, matey! Open up that config file fer editin' with yer trusty editor (nano) at the top o' the mast!
sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

The input does not contain any comments (lines starting with #), so no changes are made per instructions. Here is the exact same content returned as required:

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

Ahoy! %u be swapped fer with the username ye be logged in as. Check an’ load it wid sudo sshd -t an’ sudo systemctl reload ssh, matey!

Log In With the Certificate

Arr, ye’ll find that certificate sittin’ right next to them private keys, an’ it ends with -cert.pub. Go on then, see what’s buried inside o’er there!

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

Look fer Principals, Valid, an’ Signing CA. Put th’ certificate in ~/.ssh/config:

The provided input does not contain any Norwegian text that requires translation into English Piratespeak. The content consists of SSH configuration directives which are standard technical terms (e.g., HostName, User, IdentityFile) and do not include natural-language comments in Norwegian. Therefore, the code remains unchanged.

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

Arrr, ye be loggin’ in with ssh debian-vm, but yer key ain’t listed in authorized_keys on that blasted server!

How tha’ CA signs fer dem who run th’ CA

ssh-keygen -t ed25519 -f lab_user_ca                  # forge the CA key just once, keep it safe
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n be arr’ principal names, -V be arr’ validity period an’ -I be arr’ identifier that’ll show in arr’ logs on arr’ server. Arr’ private CA key grants access to all ships that trust it, so ye best keep her off any vessel an’ never share her with a soul!

If things go wrong

1. Ye are locked out: Ye shall log into the Proxmox konsoll, delete that file ye made in /etc/ssh/sshd_config.d/, an’ run sudo systemctl reload ssh.
2. sshd -t gives a error message: The message shows the file an’ line number. Fix yer typo before ye load it in.
3. The certificate be not accepted: Check dat the principal in the certificate (ssh-keygen -L) stands in /etc/ssh/auth_principals/user, an’ dat the certificate has not expired. On the server, sudo journalctl -u ssh -n 20 will show why the login was denied.

Critical Terms o’ Ye

Checks

• ssh root@SERVER-IP is rejected.
• Password login via SSH is denied.
  Ye can explain why ye tested in a fresh window afore shuttin’ down the old one.
• Deep dive: ye can explain why a CA be easier than authorized_keys on many servers.

Source: OpenSSH – sshd_config.