Hands-on Lab·CompTIA Linux+
The SSH server and what blocks a login
Domain 2 names secure remote access, and the question that actually comes up is why a good key is refused. This guide reads the effective server configuration, makes a working key login, then breaks it three ways on purpose - a drop-in that denies the account, a directory mode the server refuses to ignore, and a login shell that says no after the key was accepted - reading the exit code and the journal each time.
Services and Users Guide 21 of 28 Intermediate
- OSUbuntu 26.04 LTS
- Kernel7.0.0-30-generic
- systemd259
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- TimeAbout 26 min
- Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5
| 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 |
This guide includes
Use this when someone cannot log in and the key looks correct. This matters because the client's message is the same three words for causes that are nothing alike, and because the server writes the real reason in the journal every time.
- reading the configuration in force with
sshd -Tinstead of the file - knowing that a drop-in in
sshd_config.dis read before the main file - checking a change with
sshd -tbefore reloading, so a typo cannot lock you out - telling a refused authentication (exit 255) from a refused shell (exit 1)
- finding the server's real reason in the journal for each refusal
- knowing that
usermod -Llocks the password and leaves key login working
Before you start
- accounts-sudo-and-what-a-login-reads
-
The configuration actually in force
-
An account and a key, so there is something to block
-
A drop-in that refuses one account
-
The permission the server refuses to ignore
-
A shell that refuses after the key was accepted
-
Putting the machine back