OpenSSH Tip: Check Syntax Errors before Restarting SSHD Server

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

ADVERTISEMENTS

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

🐧 Get the latest tutorials on SysAdmin, Linux/Unix, Open Source & DevOps topics via:
CategoryList of Unix and Linux commands
File Managementcat
FirewallAlpine Awall CentOS 8 OpenSUSE RHEL 8 Ubuntu 16.04 Ubuntu 18.04 Ubuntu 20.04
Network Utilitiesdig host ip nmap
OpenVPNCentOS 7 CentOS 8 Debian 10 Debian 8/9 Ubuntu 18.04 Ubuntu 20.04
Package Managerapk apt
Processes Managementbg chroot cron disown fg jobs killall kill pidof pstree pwdx time
Searchinggrep whereis which
User Informationgroups id lastcomm last lid/libuser-lid logname members users whoami who w
WireGuard VPNAlpine CentOS 8 Debian 10 Firewall Ubuntu 20.04

ADVERTISEMENTS
6 comments… add one
  • digen Jan 12, 2008 @ 12:24

    Fantastic tip. Thank you !

  • Kalin Mandaliev Mar 14, 2013 @ 10:12

    Good one ! 🙂 – It’s really helpful.

  • Leo Dirac May 20, 2013 @ 17:24

    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`

  • Cosi Tenero Jul 22, 2014 @ 17:35

    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)

  • Kiwi Nick Jan 14, 2016 @ 3:20

    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.

  • Kiwi Nick Jan 14, 2016 @ 3:28

    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 Reply

Your email address will not be published. Required fields are marked *

Use HTML <pre>...</pre>, <code>...</code> and <kbd>...</kbd> for code samples.