service ssh restart does not test the configuration file

Bug #624361 reported by Simon Déziel
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openssh (Debian)
Fix Released
Unknown
openssh (Ubuntu)
Fix Released
High
Unassigned
Xenial
Triaged
Low
Unassigned

Bug Description

I would have expect "service ssh restart" to run the configuration test as "/etc/init.d/ssh restart" do. Or at least, I would have expect to have a meaningful exit status in case of failure.

I modified "/etc/ssh/sshd_config" and mistakenly inserted an error. I tried to apply my modification by restarting SSH :

# service ssh restart
ssh start/running

# echo $?
0

Because no error were reported I assumed that SSH was running with the new configuration. I was wrong because SSH never restarted because of a the syntax error in /etc/ssh/sshd_config.

After some digging I found the error :

# service ssh try-restart
/etc/ssh/sshd_config line 100: Directive 'AllowUsers' is not allowed within a Match block

Am I wrong to expecting that the new starting method provided in Lucid ("service <name> <action>") is equivalent to the old technique involving an init script ?

# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04

# apt-cache policy openssh-server
openssh-server:
  Installed: 1:5.3p1-3ubuntu4
  Candidate: 1:5.3p1-3ubuntu4
  Version table:
 *** 1:5.3p1-3ubuntu4 0
        500 http://ca.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        100 /var/lib/dpkg/status
     1:5.3p1-3ubuntu3 0
        500 http://ca.archive.ubuntu.com/ubuntu/ lucid/main Packages

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: openssh-server 1:5.3p1-3ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-24.41-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-generic x86_64
Architecture: amd64
Date: Wed Aug 25 20:56:54 2010
ProcEnviron:
 LANG=en_US.UTF8
 SHELL=/bin/bash
SourcePackage: openssh

Revision history for this message
Simon Déziel (sdeziel) wrote :
Revision history for this message
Simon Déziel (sdeziel) wrote :

I just found this in OpenSSH changelog for Maverick :

openssh (1:5.5p1-3ubuntu1) maverick; urgency=low
...
    - Convert to Upstart. The init script is still here for the benefit of
      people running sshd in chroots.
...

Is it planned to drop the init script eventually ?

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Hi Simon, thanks very much for filing this bug report and working with us to make Ubuntu better.

Because of the way upstart and sshd work together, its hard to detect failures. The reason try-restart worked was that it falls through in /usr/sbin/service, as its not one of the regular actions that upstart supports.

In looking at this, I think the appropriate fix is to add a pre-stop that runs

/usr/sbin/sshd -t

And will warn the user that the config file is broken, and possibly even abort the stop.

Setting status to Triaged as I think this fix can be worked on now.

Setting status to High, as it is a serious problem for server users if sshd is silently broken on a remote machine.

Changed in openssh (Ubuntu):
status: New → Triaged
importance: Undecided → High
tags: added: regression-release
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Further information, this was introduced in 10.04. 9.10 and prior still used the init.d script.

Revision history for this message
Simon Déziel (sdeziel) wrote :

Hi Clint,

Thanks for your additional input. Regarding your suggestion to add a pre-stop action that runs sshd -t I have to disagree. When I call "service ssh stop" I expect the daemon to quit even if there are configuration errors.

I am not familiar with upstart but maybe there are some hooks other than pre-stop that could be better suited for this. Maybe a pre-restart hook exists ?

Thank you

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

I see your point Simon, and I agree thats what I expect too. I think a case can be made that sometimes "failing safe" means doing something non-intuitive, though in doing something like that, there has to be a good reason.

There is no pre-restart stanza, and upon looking at upstart's code, it simply changes the "goal" state of the job to STOP, then to START, so this makes sense, though it could be added, it would not be a simple, natural hook like the pre-stop and pre-start.

About the only way I can think of to retain the expected behavior of always stopping (which I think is important) and avoid silently disappearing (even falsely returning 0 on initctl restart) is to simply warn via the console, when stopping with a broken config, and then fail in pre-start with the -t check.

Unfortunately, there is some resistance to using 'output console', which is currently the only way for upstart jobs to communicate with the user other than daemon.log, which is pretty far removed from a sysadmin in crisis mode trying to fix their ssh service.

I'm having some trouble even getting restart to work if there are any pre-stop scripts, so I will continue to look into this.

Changed in openssh (Debian):
status: Unknown → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Fixed by Colin in 1:6.7p1-5+deb8u4 1:7.4p1-10+deb9u2 1:7.5p1-6 by hat only Xenial still is affected.

But by now Xenial configs should work already since thre is already the next LTS released.

Changed in openssh (Ubuntu):
status: Triaged → Fix Released
Changed in openssh (Ubuntu Xenial):
status: New → Triaged
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.