How to test SSH server configuration

Testing the SSH server configuration before a reload catches broken directives, bad include files, and host-key problems before the daemon tries to apply them. That check lowers the chance of locking out the next SSH login or leaving the service unable to restart.

The OpenSSH daemon reads /etc/ssh/sshd_config and any extra files loaded through Include. Running sshd -t parses that configuration tree and checks the sanity of the configured host keys, while sshd -t -f /path/to/file validates a staged file before it replaces the live one.

Editing the server configuration still requires root or sudo access, and a clean test only proves that the daemon can parse the files. It does not prove that a new client can authenticate, so keep another login path available and reload the service only after the test returns cleanly; Ubuntu and Debian package the server as the ssh unit, while RHEL, Fedora, and similar distributions use sshd.

Steps to test SSH server configuration:

Open a terminal on the server with an account that can use sudo, and keep a second SSH session or console path available before testing changes.
Save the SSH daemon change in /etc/ssh/sshd_config or the included file that carries the local override.
```
$ sudoedit /etc/ssh/sshd_config
```
Current OpenSSH packages often load extra files from paths such as /etc/ssh/sshd_config.d/*.conf. A syntax error in any included file causes the test to fail.
Run the SSH daemon test mode against the active configuration.
```
$ sudo sshd -t
```
No output means the configuration parsed successfully and the configured host keys passed the sanity check.

Use sudo sshd -t -f /root/test_sshd_config to validate a staged file before replacing the live configuration.
Fix the first fatal error reported by sshd when the test fails.
```
$ sudo sshd -t
/etc/ssh/sshd_config.d/90-custom.conf: line 1: Bad configuration option: NotARealDirective
/etc/ssh/sshd_config.d/90-custom.conf: terminating, 1 bad configuration options
```
The output identifies the first blocking file and line, so correct that error and test again before looking for later problems.
Repeat the test until it returns with no output.
```
$ sudo sshd -t
```
Reload the SSH service only after the test returns cleanly.
```
$ sudo systemctl reload ssh
```
A clean test does not guarantee that the next login will be allowed, so changes to directives such as AllowUsers, AuthenticationMethods, or Match rules still need a real connection test.

Use sudo systemctl reload sshd on systems that package the service as sshd.

Related: How to manage the SSH server service with systemctl in Linux
Confirm that the SSH service is still running after the reload.
```
$ sudo systemctl is-active ssh
active
```
If the unit does not return active, inspect sudo journalctl --unit=ssh --no-pager --lines=20 before retrying the reload.

Substitute sshd for ssh on systems that use the sshd unit name.
Verify 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 connect 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.