How to test SSH server configuration

A broken SSH server configuration can block new logins the next time sshd reloads. Testing the configuration before applying a change catches misspelled directives, invalid include files, and unreadable host-key settings while the current daemon keeps running.

The OpenSSH daemon reads /etc/ssh/sshd_config and any files matched by an Include directive, commonly /etc/ssh/sshd_config.d/*.conf on current Linux packages. The sshd -t test parses that configuration tree and checks configured host keys, while sshd -t -f /path/to/file validates a staged file before it replaces the live configuration.

A clean test returns no output, so the next proof comes from a controlled reload, an active service check, and a fresh login from another session. Keep an existing shell or console path open until the new login succeeds, especially after changing AllowUsers, DenyUsers, AuthenticationMethods, Match, or listening directives.

Steps to test SSH server configuration:

Open a terminal on the SSH server with an account that can use sudo.

Keep a second SSH session or console path available until the tested configuration reloads and a new login works.
Edit the SSH daemon file that changed.
```
$ sudoedit /etc/ssh/sshd_config
```
Use the included drop-in file instead when the local policy lives under /etc/ssh/sshd_config.d.
Run the sshd test mode against the active configuration.
```
$ sudo sshd -t
```
No output means the files parsed successfully and the configured host keys passed the sanity check.
Test a staged configuration file before replacing the live file.
```
$ sudo sshd -t -f /root/test_sshd_config
```
Skip this step when the live file was edited directly.

Fix the first fatal error when the test fails.

$ sudo sshd -t
/etc/ssh/sshd_config.d/90-sg-config-test.conf: line 1: Bad configuration option: NotARealDirective
/etc/ssh/sshd_config.d/90-sg-config-test.conf: terminating, 1 bad configuration options

The output names the blocking file and line; correct that error before chasing later symptoms.

Repeat the test until it returns with no output.
```
$ sudo sshd -t
```
Reload the SSH service after the test returns cleanly.
```
$ sudo systemctl reload ssh
```
Use sudo systemctl reload sshd on systems that package the service as sshd.
Related: How to manage the SSH server service with systemctl
Check that the SSH service is active after the reload.
```
$ sudo systemctl is-active ssh
active
```
Substitute sshd for ssh on systems that use the sshd unit name.
Confirm that a new SSH login still works from a separate client session.
```
$ ssh user@host.example.net 'echo SSH configuration loaded'
SSH configuration loaded
```
Related: How to log in to an SSH server from Linux

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.