PORT BUG: openssh 2.3.0p1 in Linux Slackware 7

[Peter Stuge]

On Wed, Jan 03, 2001 at 12:19:20AM -0800, Ryan Moore wrote:
> I'm running a Slackware 7-based Linux distribution.  I had a problem using
> openssh 2.3.0p1.  Slackware 7 uses shadow passwords.  Openssh picks up the
> shadow password information correctly but doesn't encrypt the incoming
> password properly so all password authentication fails.
> 
> The problem is that sshd *must* be compiled with the link flag
> '-lcrypt' which includes libcrypt with the proper password crypt()
> function.  Without '-lcrypt', a different crypt() function (from the C
> library, I guess) is used which isn't compatible with the shadow password
> suite distributed with Slackware.  In Slackware 7, libcrypt is in /lib so
> no '-L' flags are needed.
> 
> I believe the solution is to have the configure script check for libcrypt
> and link against it if it exists.  The ssh-1.2.27 distribution configure
> script checks for this library and properly links against it, so it works
> correctly.

I had problems with this too.  The "problem" is actually that Slackware 7 is
using an encryption other than the regular 2 char salt + 11 char key; the
"$1$" + 8 char salt + "$" + 23 char key.

The solutions is to throw --with-md5-passwords at ./configure, then all works
fine.  The reason -lcrypt also solves the problem is because the crypt() in
OpenSSL gets overridden by the crypt() in libcrypt if you explicitly include
it.


> Sorry, I can't provide any patches, but I'm not an autoconf expert.

I've given this issue some thought but I'm still very unsure of what a good
solution would be.  There isn't really any reason to assume that all entries
in the passwd/shadow file use the same or even the desired encryption method
so there's no real way to know what to do.  Although I guess the
--with-md5-passwords could be enabled automagically if configure sees $1$ in
the beginning of the password field of any entry in passwd/shadow.  This
would however require configure to be run with root priviledges, which I
don't think is very good.  The autodetection could of course be skipped if a
user is running configure but then there's not very much use for it in the
first place.  Or?


//Peter

-- 
irc: CareBear\    tel: +46-40-914420
irl: Peter Stuge  gsm: +46-705-783805