OpenSSH public key problem with Solaris 10 and LDAP users?

Peter Stuge stuge-openssh-unix-dev at cdy.org
Thu Aug 16 11:30:19 EST 2007


On Wed, Aug 15, 2007 at 08:52:42AM +0200, Alexander Skwar wrote:
> > Again - something is different for those users, somewhere.
> 
> Of course! I'm not denying this ;) One set of users is able
> to use passwordless entry, while the other set of users is
> not able to do this. That's of course quite a difference *g*

I meant whatever causes the difference in behavior.


> > Possibly the working users were created in bulk (three) or just
> > using different versions of some software (four).
> 
> Well, as long as the LDAP database has the same contents, it
> doesn't make a difference on how the data was "poured" into it,
> I'd think.

You'd think so, but apparently that's not the case. :\


> It's like if there were a difference, when you create a user by
> doing "vi /etc/passwd" compared to "echo blah:blah:blah >>
> /etc/passwd". The result is the same. Confusing.

Except the code paths for accessing those databases are better known.


> > Creating new users the exact same way as the working users were
> > created should still succeed though.
> 
> Will try that.

> With yet another newly created test user, I'm able to SSH login
> using a password. Passwordless entry using pubkey doesn't work.

So either the tools have changed, or the way they are used has
changed. What upgrades/updates have been done in the system since
creating the working users? See if you can trace it back.


> > If you get that far, you get to reverse engineer what 
> > is actually going on to find the difference.
> 
> Yep. If I'd only be able to get that far... :\

Ok, if you want, you can still investigate what is done for new
users, and then you can look into what PAM expects.


> >> Having a look at the LDIF exports, I cannot see any differences.
> > 
> > But this is not the whole truth. There's a lot of software
> > involved in writing and reading that data,
> 
> But the LDAP database is the sole source of information.

My point is that there are several programs between OpenSSH and the
database. There's at least PAM and the PAM LDAP library, but maybe
more. You can look into which if any requirements and policies are
enforced by those components too.


> >> Anyway. Probably really a LDAP thing.
> > 
> > Can you test if these users are allowed through when someone else
> > than OpenSSH uses PAM to do passwordless logins? Any server is
> > good.
> 
> What server should I try?

Anything that can use PAM to log in users without a password. Apache
with client certs, OpenSC with pubkey on smartcard and .eid file,
even Samba and pam_winbind(sp?) if you have a Windows domain.

Another good tool is Darren's PAM test harness.


> > My guess is that the problem is with writing to LDAP, rather than
> > reading from it.
> 
> I doubt that. In LDAP, there's no difference between the
> non-working users and the working users. At least not, as far as I
> can tell.

What I meant to write was "creating users" instead of "writing to
LDAP" and "logging them in" instead of "reading from it."

Certain users are allowed to log in with key and no password, thanks
to some bit in some database.

Sun's PAM notices this bit is wrong for your new users and requires
them to specify a password even when there's a good key.

You could truss Sun sshd -ddd for working and non-working user and
compare the output, maybe that provides some hints.


On Wed, Aug 15, 2007 at 10:24:29AM +0200, Alexander Skwar wrote:
> written elsewhere in this thread - initially, I filled the
> database with the help of PADL MigrationTools. This converted
> /etc/passwd to ldif format. I then ran ldapadd to add the ldif
> file to the LDAP database.
> 
> That's what I did this time as well for the testing user.

Same versions of all involved components?


> You mean, that I should compare the output of slapcat? You're
> right. And I did that. No difference.

> No relevant differences :/

So the magic bit is not in LDAP.


//Peter


More information about the openssh-unix-dev mailing list