Re: Authentication failed suddenly

Date: 09/22/02

Date: Sun, 22 Sep 2002 02:42:46 GMT

"Per Hedeland" <> wrote in message
> In article <GO_i9.5992$> "Nico
> Kadel-Garcia" <> writes:
> >
> >"Per Hedeland" <> wrote in message
> >news:amhmda$2j1o$
> >> You keep saying things like this, but perhaps you could be a bit more
> >> specific? The only problem I've observed is that privilege separation
> >> and compression won't function together on some platforms - as noted in
> >> the documentation, i.e. this is not really a bug but a limitation of
> >> current implementation. And of course nothing forces you to use
> >> privilege separation just because you run a version that has it, just
> >> turn it off and you have the same functionality in this respect as the
> >> 3.1p1 that you advocate. And if you turn neither privsep nor
> >> off on such a platform, sshd dutifully prints
> >
> >Some kernels don't support it,
> 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.

> > it doesn't compile correctly out of the box
> >on a lot of platforms it used to work on (Solaris was an adventure, as
> >Tru64 with undocumented gcc version dependencies,
> An "adventure" indeed - just the sort of specific technical detail I was
> asking for. It compiles and runs without a hitch for me on Solaris 8
> (using gcc from the "Software companion CD" or whatever it's called). I
> don't have a Tru64 box, nor does most other people, but I wouldn't be
> surprised if there was no problem there either when using reasonably
> up-to-date development tools. I also have no problem on RH 6.x/7.x or
> FreeBSD 4.x, which together with OpenBSD (and I'm sure the other *BSD*
> are fine too) covers the vast majority of Unix systems.

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. 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.

> > the new spec files don't
> >work with older RPM versions for RedHat, it depends an a bleeding edge
> >version of autoconf to be able to modify the
> >etc.),
> I don't know where the RPM stuff in the distribution comes from, but the
> fact that it is in a 'contrib' subdirectory is a clear indication that
> the developers don't consider it a fundamental part of the distribution.
> I'm of course talking about building with the standard configure/make
> procedure, which works perfectly fine on RedHat. If you require RPMs, by
> all means stick to what your vendor provides - that's no basis for
> badmouthing the distribiution as such.

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.

> > and it broke the available chroot tools.
> Are you seriously suggesting that the developers have a responsibility
> to ensure that each new release is compatible with third-party patch
> kits?

No, but I've tried to get the chroot patches *INTO* the main code line
several times, and always been refused. 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.

> > It's just nasty if you're
> >the poor bugger who has to work out the full details for it. The enabling
> >PrivSep fails, if it's going to fail, at daemon start time,
> Of course. That's the only point in time when it can be known that it
> will fail.

True: but a potentially more useful behavior would be to simply disable the
feature, not to make the daemon start fail altogether, with a big honking
warning printed either at connect time and visible with "ssh -v" and in the
logs, or some other more glaring notification. Give the admin a chance to
recover the system, for ghu's sake!

> > so if you're
> >installing it remotely and accidentally enable it with an inappropriate
> >setup (such as compression on some platform, inappropriate sshd or
> >/var/empty on other platforms, etc.), you lose your active ssh daemon
> >you've stashed an old one and left it running on another port.
> 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. And of course you don't lose your
> active *session* unless you're using broken RedHat rc scripts that kill
> every instance of "sshd" in sight instead of just reading the pid file
> to find the daemon.

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. (RedHat 6.0, if you care.). The RPM's won't build under
RedHat 6.0 due to the bleeding edge spec files, so you have to compile from
source. Being not a complete idiot, you find another RedHat 6.0 machine to
compile on and build up an installation tarball. You send it over and
install it. Unfortunately, PrivSep is on by default, and you've failed to
correctly set the /var/empty permissions to 755.

"/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.

> But I begin to see where your aversion is coming from - your patch kit
> doesn't work until you have fixed it, and through sheer incompetence you
> have locked yourself out of a remote system - and now you try to blame
> it all on OpenSSH.

Separate issue. I made one attempt to test out the 3.4p1 chroot changes
needed, and gave it up as a bad job until PrivSep works out the compresseion

> >Those are the obvious failures: they're enough to keep even expert people
> >away from it unless they like the bleeding edge dripping all over them.
> More sweeping ramblings. Which are those "expert people" exactly? Names
> and references to their statements please.

Besides me? NDA forbids.

> >It never should have been put in the code until it had a lot more
> >The code is clearly not mature, which is a bad sign in a high-security
> >It may work well for OpenBSD, the source platform for OpenSSH, but
> >it should be taken out and run through a Roto-Rooter drain cleaner
> >cycle.....
> 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*.

> >It should *FAIL* in this case, not issue a quiet error message.
> That's your opinion, I definitely disagree - the WARNING is printed as
> the very last thing of the 'make install', you can hardly miss it. And
> to be more than a warning, it would have to parse the config file to see
> if privsep was actually on, and make the unfounded assumption that the
> admin wouldn't modify the config file after installation. In fact it
> would be perfectly fine if this check wasn't done at all, I guess it was
> only put in as a hint to those that can't be bothered to read release
> notes and other documentation.

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

> >True. I'm sure they follow this group, and the failures reported here
> >been many and varied.
> So you say - I follow the group pretty closely too, and haven't seen any
> verified actual problems with the code reported - and my previous
> message provided a detailed analysis of what *has* been reported.

> > They have put 3.4p1 on the rawhide site for testing:
> >you can play with that one if you like, but it has a lot of library
> >dependencies, and I'd recompile from the SRPM.
> Putting things on RawHide before integrating them into a release is
> standard procedure for RedHat I believe - it's no indication of quality
> problems, rather the opposite - if there were serious problems, it
> wouldn't even be on RawHide.

It's not an indication of fundamental quality problems. It's certainly no
indicator that there are not subtle ones, as we are seeing with 3.4p1.

> >> - combined with the fact that it has now been out for almost two months
> >> without being "superseded". If it was chock-full of bugs like you
> >> I'm sure the good folks developing/maintaining OpenSSH and the portable
> ^^^^^^^^^^^^^^^^
> >> version would have a bugfixed version out by now.
> ^^^^^^^
> >The bugs are platform compatibility bugs. Near as I can tell, they don't
> >occur under OpenBSD.
> Nor on most other OSes, near as *I* can tell.

I've had them with every OS I've had to compile from scratch: Solaris,
Tru64, and 6.[0-1] RedHats. I'm just waiting to be asked to deal with the
SunOS compilation: b-r-r-r-r-r. CygWin, bless their black flabby little
hearts, has kept Win9x/NTx support easy and done the compilation/bundling
themselves. (Yay! CygWin!)

> > And they're waiting, not surprisingly, for us to find
> >those bugs and fix them:
> Is this more conjecture, or do you have some basis for this claim? Of
> course all open-source developers hope that users will help them find
> bugs and report (or even fix) them - rather than rambling in public fora
> about how the code is not "mature" or "robust" - but that doesn't mean
> that they just sit back and wait rather than try things out themselves
> on the major OSes.

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.

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
patched, 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

Relevant Pages