BadOption failures "annoying"

[Jim Knoble]

Circa 2001-Oct-07 04:49:15 +0200 dixit Philipp Buehler:

  [...]
: servconf.c also kills the startup if it cant recognize an option -
: thus if I make a typo (or in this case use an option from a newer
: sshd on an older installation) sshd will fail.
: 
: Ok, <paranoia> It's better to refuse starting then *maybe* in an
: insecure configuration mode </paranoia> .. and yes <pedantic> test
: your stuff before restarting </pedantic> .. but hey, sometimes you
: are in a hurry .. :-}
: Or imagine a nulled configuration file (FS fuckup, whatever) sshd
: will start also.. w/ possible insecure configuration ....

With OpenSSH-2.9.9, sshd has an additional option:

     -t      Test mode.  Only check the validity of the configuration
             file and sanity of the keys.  This is useful for updating
             sshd reliably as configuration options may change.

This may help out the situation you're describing.  For example, if you
have a System V init:

  /usr/sbin/sshd -t && /etc/init.d/sshd restart

Or, if you think the file may be empty:

  SSHD_CONFIG="/etc/ssh/sshd_config"
  [ -s "${SSHD_CONFIG}" ] && /usr/sbin/sshd -t -f "${SSHD_CONFIG}" \
    && /etc/init.d/sshd restart

: <rant>
: openssh tends to develop major paranoia .. security is also about 
: realiablity. sshd is usually a *remote* tool, and
: way-to-easy-self-shoot-feet is not fun (yeah, tell me something
: about terminalservers)

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.

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.

Let OpenSSH concentrate on what it does: secure remote terminal
sessions and secure remote command execution.  It's quite enough.

: same for removing 'cipher none' .. ever thought of IPsec connected
: LANs where maybe a slow machine is connected with "trusted cables"
: to the IPsec gateway.. it's nice to still have public keys but not
: the crypting overhead while "work" and it's still encrypted via the
: untrusted path..

If you truly need 'cipher none', you should probably know enough about
OpenSSH to be able to put it back easily.  Otherwise, a slow machine
with a fast cipher (blowfish, arcfour) is still liable to be bound by
servicing interrupts on the network adapter more than anything else.
Don't forget to turn off compression over a fast network.

-- 
jim knoble | jmknoble at pobox.com   | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011007/17fa613e/attachment.bin