Re: Authentication failed suddenly

From: Per Hedeland (
Date: 09/22/02

From: (Per Hedeland)
Date: Sun, 22 Sep 2002 11:14:02 +0000 (UTC)

In article <G6aj9.8719$> "Nico
Kadel-Garcia" <> writes:
>"Per Hedeland" <> wrote in message
>> Some kernels don't support what? OpenSSH? The fact that some kernels
>> don't support the combination of privsep and compression is prominently
>> mentioned in the documentation.
>And it still sucks to have to deal with.

Again, that's purely your opinion - and the "dealing" you *have* to do
is zero, since, as I wrote two messages back, the daemon will just
disable compression and continue to run.

>Solaris 2.6 and Solaris 2.7, various gcc installations. OpenSSH 3.1p1 worked
>fine, I had to play the gcc re-installation game to get OpenSSH 3.4p1 to
>even compile.

OK, I now built and run 3.4p1 on Solaris 2.6 too, the only issue was
that I had to tell configure that it needed -ldl, something that I've
run into with other OpenSSH versions and platforms too - haven't
bothered to figure out why it happens since it's such a trivial issue.
This was with the ancient gcc 2.8.1, which was probably downloaded from
sunfreeware in the distant past when this system was installed.

I refuse to believe that Solaris 7 (which I have run, but don't
currently) differs so dramatically from both 2.6 and 8 that it should
have some inherent problems with OpenSSH that the others don't. Problems
due to outdated or incorrectly installed versions of gcc on Solaris are
legio though, nothing to do with OpenSSH in particular - and it's
perfectly possible that some innocuous change between versions of the
sotfware being compiled will trigger one of those problems while the
previous version did not.

> And 2.6/2.7 are different enough that I had to recompile gcc
>for each system, which wasted quite a chunk of time and took up a big chunk
>of disk for compilation that I had to clear out with a battle axe, first.

And this is OpenSSH's fault how?

>The RPM spec files, like the, are suffering from
>bleeding-edge-itis. If they're broken and distributed with the package, I
>pretty much don't care who wrote it: it's interfering with my attempts to
>use the tool due to a bad design philosophy of those aspects of the code.

You are attempting to use a very peripheral, if not even "officially
unsupported", part of the distribution, as clearly indicated by its
placement in the 'contrib' directory. The vast majority of people that
install from the tarball have no interest in building RPMs from it, and
for those that do I think it's quite reasonable to expect that they can
deal with the intricacies of RPM spec files and modify the parts that
don't suit them. Autoconf wasn't even used in any of the builds/installs
that I did.

Again, this is absolutely no reason to tell people to stay away from
3.4p1 in general.

>No, but I've tried to get the chroot patches *INTO* the main code line
>several times, and always been refused.

Probably for good reasons - not necessarily meaning that there is
anything wrong with your patches per se, but it's yet another chunk of
code to maintain and verify across multiple OSes, while not essential
functionality for most users.

> I use those tools. It's not the
>developer's fault that they broke it, but it's a chunk of someone's time to
>work around the changes.

Sure, that's part of the maintenance you'll have to expect with every
new release of the base software when you distribute patch kits - again
no reason to badmouth the base software.

>True: but a potentially more useful behavior would be to simply disable the
>feature, not to make the daemon start fail altogether,

Let's see - your configuration says that an important security feature
should be turned on, and when the daemon at startup finds that it is not
possible to do so (because you haven't read the documentation and set up
the prerequisites listed there), your suggestion is that it should run
anyway with that feature disabled? Yes, that would be a *really* fine
way for a security-critical piece of software to behave.

Incidentally, I blew a release of a commercial software package that
includes OpenSSH due to not making sure that /var/emtpy was created (I
*had* read the docs, but my testing was flawed) - too bad, but it never
crossed my mind to blame that on the OpenSSH distribution.

>> This is getting silly. If you're stupid enough to replace software that
>> is critical for your access to a remote system without prior testing,
>> you have no-one to blame but yourself. [...]

>You don't always have lots of platforms to test on. For example: a critical
>web server with OpenSSL keys on it in a locked data center in another
>center, running an antique version of the OS you can't even get distribution
>media for without a 20 hour download time for software compatibility reasons
>I won't go into.

It should be obvious that the only sensible, and also always available,
way to test in such a situation is *on the actual system in question*,
by starting the new daemon on a different port (simple commandline
option). Testing on another machine with the same OS can never be
sufficient (especially not if it is a Linux distribution, where no two
installations are the same).

>"/etc/rc.d/init.d/sshd restart". *WHAM*. Failure. Your session is still
>live, praise all the ghods. Unfortunately, while working out what's going
>on, some other idiot sees from the monitors that SSH is dead on that thing,
>calls the data center, and has it rebooted. *WHAM*. Site visit required.
>Been there, done that.

And now you blame your mistakes and incompetent system administrators on

>> More sweeping ramblings. Which are those "expert people" exactly? Names
>> and references to their statements please.
>Besides me? NDA forbids.

How convenient. Until shown otherwise, I can only, based on my own
experience, consider those so-called "expert users" anything but. And
given the newbie mistakes you report having done, I would be hard
pressed to consider you one either.

>> This exactly is the kind of generic, unsubstantiated nonsense you have
>> been posting here for several weeks now - provide specific details or
>> stop doing it.
>What do you think I just *DID*.

Extremely little in that department. From the masses of text you have
produced, I have so far been able to extract two actual potential facts
- i.e. they haven't already been refuted, but they haven't been
confirmed by anyone else either:

- The RPM specs in the contrib directory don't work on very old versions
  of RedHat.
- There are (still unspecified beyond "gcc version dependencies")
  problems building on Tru64.

If that is the sum total of the shortcomings of OpenSSH 3.4.p1, it seems
like a really great distribitution - and I can only agree.

>No, it should parse the *compilation* config.h file to see if the feature is

Nonsense. It is runtime-settable in the sshd_config file, just like lots
of other things in OpenSSH that won't work unless you have built the
package in a specific way, provided additional code/data, etc. It would
be totally broken if the installation failed because you had built with
a feature that you weren't going to use at that particular point in

On both the Solaris installs I did, I built with the default privsep
functionality, but neither created an sshd user nor a /var/empty
directory (well, actually the 'make install' did the latter for me) -
with a simple addition of 'UsePrivilegeSeparation no' to the previously
existing sshd_config, it runs like a charm - and I may choose to enable
privsep at some later time without recompilation. Why should I have been
denied installation because of that?

>I've had them with every OS I've had to compile from scratch: Solaris,
>Tru64, and 6.[0-1] RedHats.

You have had them, I have not, and clearly most other users haven't

>Sigh. So far as I know, the OpenSSH team doesn't have any Tru64's to play
>with. I'm going to be really, really startled if they have any SunOS
>systems, and they've clearly hopped in their basic development environment
>to tools that have not reached broad deployment (such as autoconf-2.5x).
>This makes working with the software harder than it needs to be, and I
>resent it.

You are clearly doing things that most users don't (applying your patch
kit, building RPMs from it, etc). I can see if you are unhappy that this
has become more problematic with the new version, but again it's no
reason to claim that the distribution is unfit for general use.

>I do appreciate the features of the software, I highly recommend it for the
>UNIX community, but I'm bashing on the latest release because I've run
>headlong into a bunch of the subtle problems. The PrivSep, while
>conceptually a very cool idea and a good security approach, has not actually
>*solved* any existing problems except a single security hole that was easily

Do you even understand what privsep is about? It's whole purpose is to
prevent holes *that are not already known* from causing damage. If it
was known to have "solved" anything, that would mean that there was yet
another bug to be fixed, and once that was done, privsep would again be
useless by your reckoning.

> and introduced a whole lot of grief for me and other people who've
>reported their issues here and elsewhere. (compression+privsep being the big

And that "whole lot of grief" consists of:

- If you don't bother to read the documentation, nor pay attention to a
  WARNING printed during install, the daemon won't start, clearly
  reporting why. Trivially fixed by either adding a line to the config
  or adding a user to your passwd, as described in the docs.

- You can't use both compression and privsep on some platforms (also
  clearly spelled out in the docs). If you try anyway, the daemon will
  still run, for obvious reasons choosing privsep over compression,
  clearly reporting that it has made this choice. If you prefer the
  opposite choice, again it's a trivial addition of one line to the
  config. And obviously, since no earlier version had privsep, you don't
  lose anything comapred to them by running 3.4p1 with privsep off.

--Per Hedeland