Cease SSH Loginne & Employ Certificates

When key-based login doth work well, no longer needeth the server to accept passwords o’er the network. This shall stay all who seek to guess at secrets by force of tongue. In this portion, thou shalt disable password and root logins with due caution. At last, behold how SSH certificates render it more facile to govern access unto many servers.

Prerequisites

• Key login doth work, see [[SSH Level 2 - Keys in lieu of passwords|SSH Level 2]].
• Thy user possesseth sudo, see [[Server Installation Level 4 - Make the server ready|Make the server ready]].
• The console within Proxmox standeth open. It is the path of refuge shouldst thou lock thyself out from SSH.

To Discontinue Passowrd and Roote Loggin

The SSH service readeth its settings from /etc/ssh/sshd_config and from filees within the folde /etc/ssh/sshd_config.d/. Craefte a distinct file, that it may bee easie to behold what thou hast altered and to repent thereof:

# To rectify the SSH daemon's configuration, thus ensuring its steadfast security
sudo nano /etc/ssh/sshd_config.d/10-sikker.conf

Inscribe thou thusly:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no doth shutteth off the rite of common password authentication. KbdInteractiveAuthentication no likewise barres interactive keyboard authentication, which otherwise might receive passwords through the hand of PAM. PermitRootLogin no utterly forbiddeth login by the root.

To most settings within this SSH configuration appertaineth the first value that the service readeth forthwith. Thus saith thy file winneth not automatically o’er other scrolls; for placement of Include, prior decrees, and any blocks marked with Match may all sway the outcome. Verifie thou the effective values ere thou loadest in these changes.

Verifie the settings before thou dost them install:

sudo sshd -t

Should no tidings be receiv’d, then is the grammar most valid; whereupon, behold which values this new configuration doth bestow upon thee:

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

All three shall display no. Shouldst thou receive other values, examine thou /etc/ssh/sshd_config and the files therein included ere proceeding further. With rules of Match, verify thou also the current connection via sudo sshd -T -C user=user,addr=CLIENT_IP,host=CLIENTNAME; replace the example values with those of the user, client address, and client name pertaining to thy login trial. Perform this same verification upon the three settings.

When the values are true, loadest thou in the alteration thusly:

sudo systemctl reload ssh

Shut thou not the window wherein thy login doth reside. Open a fresh terminal-window and prove it thus:

ssh debian-vm                 # it oughte to work with ease
ssh root@SERVER-IP            # shall be denied, most surely so
ssh -o PubkeyAuthentication=no user@SERVER-IP   # shall be refused, no query for password's key

The password for the user thou still needest unto sudo. It is writ upon the server, not o’er the network.

En Deepening: The Certificates of SSH

With ten servers and five stewards of administration, each key must rest upon every server. Thus shall there be fifty entries within authorized_keys, and when one departeth from their post, the key must be excised from all places.

By means of certificates, a signatory authority (the CA) doth seal thy key. The servers place their trust in the CA, not in any singular key alone. Furthermore, the certificate containeth this:

• principals: those names unto which the certificate is granted, such as admin
• validity period: the time wherein the ceaseth to hold power

To Set Forth the Server

Thou shalt require th’ publicke key of him that keepeth the Certificate Authority (as a master teacher might). Place it upon the server thusly:

sudo nano /etc/ssh/lab_user_ca.pub

Determine which princes shall be granted leave to enter as the user user:

The input contains no comments; returning original block unchanged per contract (no added meta).

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

Do tell unto the SSH service of the Certificate Authority:

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

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

The token %u shall be exchanged for the name wherein one doth enter. Verify thy works with the command sudo sshd -t, then renew the service via sudo systemctl reload ssh.

To Enter with the Certificate

The certificate lieth beside the private key and endeth upon -cert.pub. Behold what it containeth:

# To scrutinize the credentials of thy ed25519 key certificate
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Seek out Principals, Valid, and Signing CA. Place the certificate within ~/.ssh/config:

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

Now dost thou sign in with ssh debian-vm, albeit thy key be absent from authorized_keys upon that server.

How the CA Signeth (For He Who Dooths the Keeping of the CA)

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

-n is the principals, -V is the term of validity, and -I is an identifier that shall be seen within the logs upon the server. The secret key of authority granteth access unto all servers which place their trust therein; therefore it must never rest upon a server nor be shared with another soul.

If Alas Be Falls Amiss

1. Thou art locked without gate: Enter the Proxmox-console, expunge the file thou didst make within /etc/ssh/sshd_config.d/ and runne sudo systemctl reload ssh.
2. sshd -t doth yield error-message: The message sheweth the file and line-number. Amend thy scribal errour ere thou loadest it in.
3. The certifi-cate is not accept-ed: Check that the principal in the certifi-cate (ssh-keygen -L) standeth in /etc/ssh/auth_principals/user, and that the certifi-cate be not past its date. Upon the server, sudo journalctl -u ssh -n 20 revealeth why thine entry was deny’d.

Of Prime Importance to Knowe

Verifications

• ssh root@SERVER-IP is denied.
• Entry by password o’er the SSH path is refused.
• Thou mayst expound why thou didst assay a fresh window ere thou closedst the ancient one.
• Deeper study: thou canst declare wherewithal a Certificate Authority is more facile than authorized_keys upon manifold servers.

Source: OpenSSH – sshd_config.