OpenSSH Tip: Check Syntax Errors before Restarting SSHD Server

Posted on in Categories Linux, Networking, OpenBSD, RedHat/Fedora Linux, Security, Sys admin, Tips, Troubleshooting, UNIX last updated June 17, 2017
OpenSSH - SSHD Logo

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-check-syntax-error-before-resting-server

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

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin and a trainer for the Linux operating system/Unix shell scripting. He has worked with global clients and in various industries, including IT, education, defense and space research, and the nonprofit sector. Follow him on Twitter, Facebook, Google+.

6 comment

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

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

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

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

Comments are closed.