Put a Lasso on SSH Logins an’ Use Certificates

Once key login is workin’, the server don’t need to take passwords over the network no more. That stops every last one tryin’ to guess passwords. In this part, ya turn off password an’ root loggin’ safe-like. At the end, ya’ll see how SSH certificates make it easier to rope up access to lots o’ servers.

Prerequisites

• Key logging works, see [[SSH Level 2 - Keys instead of passwords|SSH Level 2]].
• Your user has sudo, see [[Server Installation Level 4 - Prep the Server|Prep the Server]].
• The console in Proxmox is open. It’s your backup plan if you lock yourself outta SSH.

Turn off password and root login

The SSH service reads settings from /etc/ssh/sshd_config and files in the folder /etc/ssh/sshd_config.d/. Create a separate file so it’s easy to see what ya changed and undo yer workin’:

# Editin' de SSH config file real careful-like
sudo nano /etc/ssh/sshd_config.d/10-sikker.conf

Type in:

# PasswordAuthentication don't work for me on this rig
PasswordAuthentication no
# KbdInteractiveAuthentication ain't needed here either
KbdInteractiveAuthentication no
# PermitRootLogin stay off, that's orders
PermitRootLogin no

PasswordAuthentication no shuts off regular password authentication. KbdInteractiveAuthentication no also closes down keyboard interactive auth, which might otherwise take a password through PAM. PermitRootLogin no blocks root logins dead to rights.

Mostly with them SSH settings, it’s whichever value the service reads first that counts. So your file don’t automatically win out on other files: where you got yer Includes, earlier settings, and any Match blocks can all stir up the outcome. Check what values are actually in play before ya load ‘em in.

Check yer settings before ya put ‘em into action:

sudo sshd -t

If no message shows up, then the syntax is good. Now check on what values that new setup gives ya:

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

All three should show no. If ya get different values, check out /etc/ssh/sshd_config and any files it pulls in before movin’ on. With Match rules, ya gotta verify that specific connection using sudo sshd -T -C user=user,addr=CLIENT-IP,host=CLIENTNAME; swap those example bits with the actual username, client address, and hostname fer whatever login ya’re testin’. Run that same check on all three settings.

Once they look right, load up them changes:

The provided code block does not contain any comments (lines starting with #) that need to be translated; it consists solely of an executable command (sudo systemctl reload ssh). Therefore, no changes are required.

sudo systemctl reload ssh

Don’t close the window you’re logged into. Open a new terminal window an’ give this a try:

ssh debian-vm                 # oughta work
ssh root@SERVER-IP            # oughta get turned away
ssh -o PubkeyAuthentication=no user@SERVER-IP   # oughta get turned away, no password askin'

You still need that user’s password fer sudo. It gets written on de server, not sent over de network.

Deep Dive: SSH Certificates

With ten servers and five administrators, every key has to sit on every server. That makes fifty entries in authorized_keys, and when somebody quits, that key got to get pulled from everywhere.

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

• principals: the names this cert is good for, like admin
• validity period: when the cert stops workin’

Set Up the Server

You need the CA’s public key from whoever runs the CA (like the teacher). Put it on the server:

# Fixin' up that SSH certificate authority pub key for our lab partner
sudo nano /etc/ssh/lab_user_ca.pub

Figure out which principals get to sign in as the user user.

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

Tell the SSH service about that dang CA:

# Nothin' but a command to edit that config file with sudo nano - no comments to translate here!
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 gets swapped out fer the username y’all’re logged in as. Check ‘em off an’ load ‘em up with sudo sshd -t an’ sudo systemctl reload ssh, partner.

Sign yerself with the certificate

That here lies right beside yer private key an’ ends on -cert.pub. Take a look at what’s inside:

# Ain't nothin' but a key checkin', partner!
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Look for Principals, Valid, an’ Signing CA. Toss that certificate into yer ~/.ssh/config:

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

Now y’all log in with ssh debian-vm without yer key bein’ in authorized_keys on that server.

How a CA Signs (For Those Who Run the CA)

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

-n is for principles, -V is for validity period, an’ -I is an ID that shows up in them server logs. That private CA key gives y’all access to every single server that trusts it, so ye better keep her off any server an’ never share it with a soul.

If somethin’ goes wrong

1. You’re locked out: Log into the Proxmox console, delete the file you made in /etc/ssh/sshd_config.d/ an’ run sudo systemctl reload ssh.
2. sshd -t throws a fit: The message’ll show ya the file an’ line number. Fix that typo before ye load it up.
3. The certificate ain’t gettin’ accepted: Check to make sure the principal in the cert (ssh-keygen -L) is listed in /etc/ssh/auth_principals/user, an’ that the cert hasn’t expired yet. On the server side, sudo journalctl -u ssh -n 20 will tell ya why they turned yer login down.

Key Terms

Checks

• ssh root@SERVER-IP gets rejected.
• Password login over SSH gets 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 easier than authorized_keys on many servers.

Source: OpenSSH – sshd_config.