On Sat, Mar 31, 2007 at 07:06:04PM +0200, Yang Tse wrote:
> This mail is related to this change
> http://cool.haxx.se/cvs.cgi/curl/tests/sshserver.pl.diff?r1=1.7&r2=1.8

Sorry, I should have started a new thread for this problem--the PATH
patch looked fine.

> 2007/3/31, Dan Fandrich wrote:
>
> >The most recent change to sshserver.pl to auto-detect supported sshd_config
> >options causes a problem.
>
> Please Dan, which one/s ? Excuse me, I may have missed some facts or
> some previous post(s) but from what you have written in the mail I'm
> replying and from what I've tested, I don't know or have been unable
> to see, which is/are the problem/s it introduces. I'm not saying they
> don't exist, I'm only declaring my inability to see it/them at this
> point.
>
> If it actually introduces any problem not already present without it,
> I'll be glad to address them, or if it there is no way to fix them
> I'll revert the patch with no problem at all.

In a nutshell, the patch can cause sshd to run using a set of options that
will not allow the test suite to operate, causing the scp/sftp tests to
fail. Without the patch, the same specific case would cause the test to
be skipped instead.

> For example, latest version of OpenSSH (OpenSSH_4.6p1, OpenSSL 0.9.8e
> 23 Feb 2007) distributed with latest version of Cygwin
> (1.5.24(0.156/4/2) 2007-01-31) does support options UseDNS and
> ChallengeResponseAuthentication but does not support UsePAM option.

I had assumed that recent versions would keep support for the old options
for backwards compatibility, but I suppose that's why they created the
-t option--so they wouldn't need to.

> The need for the patch aroused from the fact that sshd failed to start
> if the not supported option UsePAM was used, making the testsuite fail
> tests 6XX.

One of my test setups I'm dealing with has the opposite problem--it fails if
UsePam is NOT used, due to the way PAM is set up there. On another one
(running an old sshd) the test suite to run at all because it lacks the
UsePAM option, so keeping UsePAM in the config file causes the tests to
be skipped, which is right on that machine. Clearly, this is going to
be a tricky problem to solve everywhere. I can see now why Daniel has
insisted in the past on keeping the test servers within the curl package!

> Then, if I'm not understanding you wrong, the testsuite should also be
> verifying OpenSSH's version and skipping 6XX test cases if OpenSSH's
> version is not greater than that one.

Even that's not perfect, because some old versions will probably work
fine if e.g. PAM support is compiled out.

> I agree with you. Further checks might also be needed, and should also
> probably be done. I don't know which ones. You also with Daniel are
> the experts and the fathers of all this and nearly all libcurl stuff.
> I just wanted to help and contribute my little grain into the big
> pile.

You're giving me far too much credit--only a comparative handful of
lines of code originated from me. Of course, I take full credit for the
mess that the ssh test suite has turned into!

Let's see if I can generalize the sshd startup requirements:

1) sshd needs to have all options enabled which are supported in that
version and that a) increase security and b) reduce dependencies on
configuration that is outside the test harness' control.

2) If sshd supports a feature that introduces a dependency on
configuration that is outside the test harness' control and that feature
cannot be disabled through an option, then sshd must not be run so that
the test will be skipped.

Requirement 2) applies only to PAM to my knowledge, and the UsePAM option.
It could be tricky to determine whether a given sshd supports PAM but not
UsePAM. One possibility is to use another option (like
PAMAuthenticationViaKbdInt) as a proxy for PAM support, but even that won't
work on really old versions of sshd (but those really old versions don't
support -t either) or possibly really new versions. We could look see
if the binary is linked against libpam.so, but that's platform-specific
and not completely reliable. Finally, we could just establish a base
version of sshd that doesn't suffer from this problem and we won't even
attempt to run such.

How about this as a solution: pick version 3.7 as a base OpenSSH version
before which we just don't bother run (3.7 is the earliest that supports
UsePAM, and it's almost 4 years old). Find a configuration option
that was first introduced in that version (that's still supported in
the latest version--UseDNS will probably work for this) and if that's
supported in the binary under test, we're OK. Then check all the
other relevant options just the way it's done in the sshserver.pl now,
including UsePAM and increase the set of options to include all the ones
that have changed since version 3.7.

This solution will prevent all the earlier versions without PAM support
compiled in from being used for the tests, but the difficulty in
determining whether older versions have PAM support enabled means it's
hard to do better reliably.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved