Keys, certificates, and what the server allows
Domain 3 names keys and certificates alongside mandatory access control. This guide makes a key pair and logs in with it, breaks the login with one chmod, reads what the SSH server actually permits on both families, and issues a self-signed certificate - then shows the two openssl checks that say whether it is trusted and whether it matches its key.
Security Guide 11 of 28 Intermediate
- PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- Firewallufw / nftables 1.1.6
- TimeAbout 24 min
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-A01 | 192.168.0.73 | Ubuntu 26.04 LTS | Debian-family host - apt, ufw, netplan, AppArmor | 2 Core | 4 GB | 50 GB |
| LPLUS-B01 | 192.168.0.74 | AlmaLinux 10.2 | RPM-family host - dnf, firewalld, NetworkManager, SELinux | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when setting up key-based access or deploying a certificate. This matters because both fail in ways that look like something else: a key with the wrong mode is refused by your own client before the server ever sees it, and a certificate that does not match its key produces an error about TLS rather than about files.
- making a key pair and finding that both halves share one fingerprint
- authorising the public half and logging in with no password
- breaking that login with
chmod 644, and reading the refusal the client issues - reading the effective SSH policy on both families, which spell the same setting differently
- issuing a self-signed certificate, and running the two checks that say what it is worth
Before you start
- selinux-and-apparmor-side-by-side
-
A key pair, and what each half is for
-
Installing the public half, and logging in without a password
-
The permission the client refuses to ignore
-
What the server actually allows
-
A self-signed certificate, and what it does not prove
-
Putting the machine back