OOpenSSH (OpenBSD Secure Shell) is a default secure shell for encrypted communication sessions over a computer network using the ssh protocol. Usually, you log in using ssh and makes changes to its configuration file /etc/ssh/sshd_conf over a remote session. If there is an error in configuration, the server may not start (i.e. no remote login allowed). This will result in a disaster; if you didn’t have access to the remote console. But how do you find out a syntax error for the sshd_config file?
OpenSSH Test Mode
OpenSSH has test mode option. Use the -t option to check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.After making changes to the config file, type the following command run syntax check on the configuration file, enter:
$ sudo /usr/sbin/sshd -t
OR
# sshd -t
Sample outputs:
/etc/ssh/sshd_config: line 26: Bad configuration option: PermitRootLogins /etc/ssh/sshd_config: terminating, 1 bad configuration options
If there is an error, it will show on screen. Otherwise, it will not display any message:
$ sudo /usr/sbin/sshd -t
$ echo $?
Sample outputs:
0
If there is an error on line # 26, edit config file using vi text editor, enter:
$ sudo vi +26 /etc/ssh/sshd_config
Please note that test mode can be done while running the OpenSSH daemon (sshd). If there is no error, just type a restart sshd command:
# service sshd restart
OR
# /etc/init.d/ssh restart
OR
# systemctl ssh reload
OR just reload sshd using systemctl on Linux based system:
$ sudo systemctl sshd reload
See also
ADVERTISEMENTS
6 comment
Fantastic tip. Thank you !
Good one ! 🙂 – It’s really helpful.
This is so crippling if you get it wrong on a remote machine I’m tempted to put something like this in my crontab:
wall `sshd -t`
To restart the daemon – and read the modified configuration – type /etc/init.d/sshd restart (notice the “d” in “sshd”; there is no /etc/init.d/ssh file)
Various versions of sshd don’t take a -t option. After editing a sshd_config file, I handle this in four steps.
1. ps -ef | grep ‘[s]shd’ # to learn the command-line it was started with (eg /usr/sbin/sshd -4)
2. netstat -a -n | grep -w ‘2222’ # check that port 2222 is vacant on this machine
3. Peruse the man page for sshd and find the option that enables debugging mode (eg -v) or prevents it from daemonising (eg -D), and the option for setting a port (usually -p 2222)
4. /usr/sbin/sshd -4 -v -p 2222
This will start a new sshd in the same way the existing was started (-4), except it won’t daemonise (-v) and on a vacant port (-p 2222). It gives an error message if there’s something wrong with the config file. Otherwise, press ^C to exit.
To be doubly sure, I put an intentional syntax error into the config file, so I can be sure the test is picking up the right file, before doing the real test.
It may not be necessary to restart the sshd server. Many sshd implementations will take a SIGHUP to re-read its configuration file.
# ps -ef | grep ‘[s]shd’
root 1396 491 0 11:36:13 ? 0:00 /usr/lib/ssh/sshd -4
root 491 1 0 16:44:44 ? 0:00 /usr/lib/ssh/sshd -4
root 1359 491 0 11:00:22 ? 0:00 /usr/lib/ssh/sshd -4
root 1395 1369 0 11:30:13 pts/1 0:00 vi sshd_config
# kill -HUP 491
If SIGHUP doesn’t work, an extra safeguard could be have a second ssh session/connection running, and check they don’t get clobbered by an sshd restart (ie do a restart without changing any config file). Or temporarily enable telnet and use that to do the work.