Hi,
some question about the configuration behaviour of openssh..
sshd.8
-f configuration_file
Specifies the name of the configuration file. The default is
/etc/sshd_config. sshd refuses to start if there is no configura-
tion file.
While servconf.c has the routine
fill_default_server_options(ServerOptions *options)
which sets valid/common options by "itself" - thus I *can* run sshd
w/ an empty configuration file anyway .. hello?
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 ....
<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)
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..
</rant>
so long,
ciao
--
Philipp Buehler, aka fips | sysfive.com GmbH | BOfH | NUCH | <double-p>
#1: Break the clue barrier!
#2: Already had buzzword confuseritis ?
On Sun, 7 Oct 2001, Philipp Buehler wrote:> 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> ..Exactly. We even provide a commandline switch (sshd -t) which will test configs for you.> 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 ....sshd's config is secure by default.> 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 want rlogin, then use rlogin. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer
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
On Sun, Oct 07, 2001 at 04:49:15AM +0200, Philipp Buehler wrote:> 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 ....the default is not considered insecure. sshd assumes that if you do sshd -f /dev/null you know what you are doing. moreover, if you do echo bogusoption yes > sshd_config sshd -f sshd_config then it also assumes that you know what you are doing.> <rant> > openssh tends to develop major paranoia .. security is also about > realiablity.please send a bug report if you discover a realiablity bug.> sshd is usually a *remote* tool, and way-to-easy-self-shoot-feet > is not fun (yeah, tell me something about terminalservers)you can start backup daemons if you don't understand the documentation.> same for removing 'cipher none'cipher none support got not removed, it was never supported.> .. ever thought of IPsec connected LANs > where maybe a slow machine is connected with "trusted cables" to the IPsec > gateway..there is not standard API for figuring out the IPsec SAs for the underlying TCP connection.> it's nice to still have public keys but not the crypting overhead > while "work"how much overhead is it in interactive sessions?> and it's still encrypted via the untrusted path..-m