OpenSSH Tip: Check Syntax Errors before Restarting Server

Posted on in Categories Linux, Networking, OpenBSD, RedHat/Fedora Linux, Security, Sys admin, Tips, Troubleshooting, UNIX last updated January 8, 2008
OpenSSH - SSHD Logo

OpenSSH / OpenBSD Secure Shell – is default secure shell for encrypted communication sessions over a computer network using the ssh protocol. Usually, you login using ssh and makes changes to its configuration file /etc/ssh/sshd_conf over a remote session. If there is an error in configuration, server may not start (i.e. no remote login allowed). This will result into a disaster; if you didn’t have access to remote console. But how do you find out a syntax error for 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 config file, type the following command run syntax check on configuration file, enter:
$ sudo /usr/sbin/sshd -t
# sshd -t

/etc/ssh/sshd_config: line 26: Bad configuration option: PermitRootLogins
/etc/ssh/sshd_config: terminating, 1 bad configuration options

If there is error, it will show on screen. Otherwise it will not display any message:
$ sudo /usr/sbin/sshd -t
$ echo $?



If there is 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, simply type a restart sshd command:
# service sshd restart
# /etc/init.d/ssh restart

6 comment

  1. 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)

  2. 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.

  3. 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.

Leave a Comment