LFCS 111 🐧 SSH Server — Configuration - KandZ

⏱️ Estimated read: 10 min | |

The SSH server is the daemon that listens for incoming connections, authenticates users, and provides an encrypted channel for remote administration. On Linux, this is OpenSSH’s sshd. Its behavior is controlled by a single configuration file, /etc/ssh/sshd_config, and a set of drop-in files under /etc/ssh/sshd_config.d/ on modern distributions. The LFCS exam tests the ability to modify this file safely: disable password authentication, prohibit direct root login, change the listening port, and validate the configuration before restarting the service. The critical trap is the lockout: a configuration change that disables the only working authentication method will sever the administrator’s connection and require console access to recover.

Key point: sshd -t validates the syntax of the configuration before a reload. sshd -T displays the effective configuration as the daemon understands it. Both commands must pass before systemctl reload sshd is executed. The service name is ssh on Debian/Ubuntu and sshd on RHEL-family systems.

Why SSH server configuration requires discipline

The lockout problem. A configuration change that disables password authentication before a working SSH key is installed will prevent every future login. The safe workflow is: install the key, verify key-based login in a second terminal, then disable password authentication. The exam tests this sequence, not just the individual directives .

The syntax problem. sshd refuses to start if the configuration contains a syntax error. A missing quote, a misspelled keyword, or an invalid value causes the service to fail. sshd -t parses the file and reports the error without touching the running service. Without this validation step, a reload can terminate the daemon and lock out every administrator .

The drop-in problem. Modern OpenSSH packages include /etc/ssh/sshd_config.d/ and an Include directive at the top of sshd_config. Files in the drop-in directory are read first, and the first occurrence of a keyword wins. A directive added to sshd_config may be overridden by a file in sshd_config.d/. The effective configuration is visible only through sshd -T .

The port problem. Changing the SSH port from 22 to 2222 is a common hardening measure. On RHEL-family systems, SELinux restricts sshd to the ssh_port_t type, which contains only port 22 by default. Adding Port 2222 to sshd_config passes sshd -t but fails at runtime with a bind permission error until the port is added to SELinux with semanage port -a -t ssh_port_t -p tcp 2222 . On Ubuntu with socket activation, sshd -T may report the configured port while the socket listens on port 22. Both cases are exam-relevant traps.

The trade-off. Hardening SSH reduces the attack surface: no password brute force, no direct root login, no legacy protocol. But every hardening step adds a lockout risk. The correct approach is incremental: one change at a time, validated, tested in a separate session, then made permanent.

a. The essential configuration directives

The /etc/ssh/sshd_config file is a keyword-value list, one directive per line. Comments begin with #. The essential directives for a hardened server are few.

# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no

PermitRootLogin no prevents direct root login over SSH. The alternative, prohibit-password, allows root login only with a key, which is acceptable but less strict than no. PasswordAuthentication no disables password-based login entirely; only public key authentication is accepted. PubkeyAuthentication yes is the default and should remain enabled. PermitEmptyPasswords no prevents accounts with empty passwords from authenticating. ChallengeResponseAuthentication no disables keyboard-interactive authentication, which is often a fallback for password login .

The Match block allows conditional configuration. A common pattern is to disable password authentication globally but allow it for a specific user or group.

PasswordAuthentication no

Match User emergency
    PasswordAuthentication yes

The Match block must appear at the end of the file. Directives before the first Match are global; directives inside a Match apply only when the condition is true .

b. Validating and applying the configuration

The validation commands are mandatory before any reload. sshd -t parses the configuration and reports syntax errors. sshd -T dumps the effective configuration, including defaults and drop-in overrides.

# Validate syntax
sudo sshd -t

# No output means the syntax is valid.

# Display effective configuration
sudo sshd -T | grep -E 'port|passwordauthentication|permitrootlogin'

The sshd -T output is the authoritative view. A directive in sshd_config that is overridden by a drop-in file will not appear as expected. The grep filter narrows the output to the directives that matter for the change .

After validation, the service is reloaded with systemctl reload. The reload command rereads the configuration without terminating established connections. The restart command terminates all connections and restarts the daemon. For a remote administrator, reload is the safe choice; restart will drop the current session .

# Reload (safe, keeps connections)
sudo systemctl reload sshd

# Check status
sudo systemctl status sshd

The service name varies. On RHEL, Fedora, and CentOS, it is sshd. On Debian and Ubuntu, it is ssh, though recent versions accept the sshd alias. The systemctl list-unit-files | grep ssh command confirms the correct name .

c. The lockout recovery path and port changes

If a configuration change locks out SSH access, the recovery path is the console. On a physical server, this is a keyboard and monitor. On a virtual machine, it is the hypervisor console. On a cloud instance, it is the serial console. The recovery steps are: log in via console, revert the configuration change, validate with sshd -t, and reload the service.

The port change requires additional steps beyond editing sshd_config. On SELinux systems, the port must be added to the ssh_port_t type before the daemon can bind to it.

# Check current SSH port context
sudo semanage port -l | grep ssh_port_t

# Add the new port
sudo semanage port -a -t ssh_port_t -p tcp 2222

# Then edit sshd_config and reload

On Ubuntu with socket activation, the ssh.socket unit controls the listening port. Editing sshd_config is insufficient; the socket unit must be modified or the port must be configured through the ssh.socket override. The sshd -T command may report the configured port while the actual listening socket remains on 22. The ss -tlnp | grep ssh command shows the actual listening port.

Complete Example Session

# ============================================
# PART 1: VERIFY CURRENT CONFIGURATION
# ============================================

sudo sshd -T | grep -E 'port|passwordauthentication|permitrootlogin'
# port 22
# passwordauthentication yes
# permitrootlogin prohibit-password

# ============================================
# PART 2: ENSURE A KEY IS INSTALLED AND TESTED
# ============================================

# From the client:
ssh-copy-id user@server
ssh user@server
# Key-based login must succeed before password authentication is disabled.

# ============================================
# PART 3: EDIT THE CONFIGURATION
# ============================================

sudo nano /etc/ssh/sshd_config
# Set:
# PermitRootLogin no
# PasswordAuthentication no

# ============================================
# PART 4: VALIDATE SYNTAX
# ============================================

sudo sshd -t
# No output: syntax is valid.

# ============================================
# PART 5: CHECK EFFECTIVE CONFIGURATION
# ============================================

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'
# passwordauthentication no
# permitrootlogin no

# ============================================
# PART 6: RELOAD THE SERVICE
# ============================================

sudo systemctl reload sshd
# Established sessions remain active.

# ============================================
# PART 7: TEST IN A NEW SESSION
# ============================================

ssh user@server
# Key-based login succeeds.
ssh -o PubkeyAuthentication=no user@server
# Permission denied (publickey): password login is rejected.

# ============================================
# PART 8: CHANGE THE PORT (OPTIONAL)
# ============================================

# On SELinux systems:
sudo semanage port -a -t ssh_port_t -p tcp 2222
# Edit sshd_config: Port 2222
sudo sshd -t
sudo systemctl reload sshd

# ============================================
# PART 9: VERIFY LISTENING PORT
# ============================================

sudo ss -tlnp | grep sshd
# LISTEN 0 128 0.0.0.0:2222

The nine parts trace the hardening workflow: verification, key installation, configuration edit, syntax validation, effective configuration check, reload, test, port change, and listening port verification.

Quick Reference

Essential Directives

Directive	Recommended Value	Purpose
`Port`	`22` or custom	Listening port
`PermitRootLogin`	`no`	Block direct root login
`PasswordAuthentication`	`no`	Disable password auth
`PubkeyAuthentication`	`yes`	Enable key auth
`PermitEmptyPasswords`	`no`	Block empty passwords
`ChallengeResponseAuthentication`	`no`	Disable keyboard-interactive

Validation Commands

Command	Purpose
`sshd -t`	Validate syntax
`sshd -T`	Dump effective configuration
`ss -tlnp \| grep sshd`	Show listening ports
`systemctl reload sshd`	Apply without dropping connections
`systemctl restart sshd`	Restart, drops connections

Service Names

Distribution	Service Name
RHEL, Fedora, CentOS	`sshd`
Debian, Ubuntu	`ssh` (alias `sshd`)

Port Change Requirements

System	Additional Step
SELinux (RHEL)	`semanage port -a -t ssh_port_t -p tcp <port>`
Ubuntu socket activation	Modify `ssh.socket` unit

Best Practices

✅ Do This:

sudo sshd -t
<!-- Validate syntax before reload -->                # ✅

ssh user@server
<!-- Test key login in a separate session first -->   # ✅

sudo systemctl reload sshd
<!-- Use reload to preserve connections -->           # ✅

❌ Don’t Do This:

# Disable password auth before testing key auth
<!-- Locks out the administrator -->                  # ❌

# Restart sshd over a remote connection
<!-- Drops the current session -->                    # ❌

# Change port without updating SELinux
<!-- sshd fails to bind on RHEL -->                   # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Locked out after change	Disabled password before key tested	Console recovery; re-enable password
sshd fails to start	Syntax error	`sshd -t` to identify
Directive ignored	Overridden by drop-in file	Check `sshd -T`
Port change fails on RHEL	SELinux restricts port	`semanage port -a`
Ubuntu port change ignored	Socket activation	Modify `ssh.socket`

Real-World Examples

1. Disable Root Login

PermitRootLogin no

2. Disable Password Auth

PasswordAuthentication no

3. Enable Key Auth

PubkeyAuthentication yes

4. Match Block for User

Match User emergency
    PasswordAuthentication yes

5. Validate Syntax

sudo sshd -t

6. Effective Config

sudo sshd -T | grep passwordauthentication

7. Reload Service

sudo systemctl reload sshd

8. Check Listening Port

sudo ss -tlnp | grep sshd

9. SELinux Port

sudo semanage port -a -t ssh_port_t -p tcp 2222

10. Test Password Rejection

ssh -o PubkeyAuthentication=no user@server

Visual

Hardening Workflow

┌──────────────────────────────────────────────┐
│  Install SSH key for user                    │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Test key-based login in new session         │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Edit sshd_config                            │
│  PasswordAuthentication no                   │
│  PermitRootLogin no                          │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  sshd -t (syntax validation)                 │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  systemctl reload sshd                       │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Test in new session                         │
└──────────────────────────────────────────────┘

Lockout Recovery

┌──────────────────────────────────────────────┐
│  Locked out after config change              │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Console access (physical/hypervisor/serial) │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Revert configuration                        │
│  PasswordAuthentication yes                  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  sshd -t && systemctl reload sshd            │
└──────────────────────────────────────────────┘

Summary

Item	Value
Configuration file	`/etc/ssh/sshd_config`
Drop-in directory	`/etc/ssh/sshd_config.d/`
Syntax validation	`sshd -t`
Effective config	`sshd -T`
Reload (safe)	`systemctl reload sshd`
Restart (drops)	`systemctl restart sshd`
Service name (RHEL)	`sshd`
Service name (Ubuntu)	`ssh`
Port change (SELinux)	`semanage port -a -t ssh_port_t -p tcp <port>`

Key takeaways:

sshd -t is mandatory before any reload. It validates the syntax without touching the running service. A configuration with a syntax error will prevent the daemon from starting .
sshd -T shows the effective configuration. Drop-in files can override directives in sshd_config. The first occurrence of a keyword wins, so the effective value may differ from what is written in the main file .
Disable password authentication only after key-based login is verified. The lockout is the most common failure mode. The recovery path is the console, which may not be available on a remote server .
Port changes require distribution-specific steps. SELinux on RHEL restricts sshd to the ssh_port_t type. Ubuntu’s socket activation may ignore the Port directive in sshd_config .
reload preserves established connections. restart drops them. For a remote administrator, reload is the safe command.

Remember: The SSH server configuration is a lockout risk. Every change must be validated with sshd -t, tested in a separate session, and applied with reload. The key-based login must work before password authentication is disabled. The port change must be coordinated with SELinux or socket activation. The configuration file is the source, but sshd -T is the truth.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!