BadOption failures "annoying"

Philipp Buehler lists at
Sun Oct 7 18:43:42 EST 2001

On 07/10/2001, Jim Knoble <jmknoble at> wrote To openssh-unix-dev at
>   SSHD_CONFIG="/etc/ssh/sshd_config"
>   [ -s "${SSHD_CONFIG}" ] && /usr/sbin/sshd -t -f "${SSHD_CONFIG}" \
>     && /etc/init.d/sshd restart

Yeah sure.

> If you're concerned about reliability, you should probably use 'sshd
> -t' in combination with version control on the config file, along with
> an automated process to move an older, known-good config file into
> place and restart sshd if a newly changed one doesn't work.  You'll
> probably also want a watchdog process to restart sshd if it falls over
> for any reason.

Uhuu.. the more 'automated process' the more point of possible failures.
(see below also)

> Neither of those things is really a job for OpenSSH.  Besides, if you
> need reliability for sshd, you probably need it for other services as
> well, and you probably need to customize it according to site-specific
> policy.

The point is:
If $service fails to start at bootup, I still can log in and start by hand.
*But* this is obviously not "valid" for ssh.
> Let OpenSSH concentrate on what it does: secure remote terminal
> sessions and secure remote command execution.  It's quite enough.

Sure. My keypoint was (and even Damien told me "default is secure"):
sshd refuses to start, if the config file is broken. WHY?
It's rather a short patch to revert to the "secure default" configuration,
make a critical syslog entry about this and *start*, so I am not forced
to travel to the machine for a possible 2 minute "fix" [1]

Corruption of the config file can occur also several conditions, and
this "reverting" to a "known good" config by some script is errorprone

[1] Which I have to do now and thus no patch for now, but I will write one.
Philipp Buehler, aka fips | GmbH | BOfH | NUCH | <double-p> 

#1: Break the clue barrier!
#2: Already had buzzword confuseritis ? 

More information about the openssh-unix-dev mailing list