[Freeipa-users] User can't login via ssh from external

Jakub Hrozek jhrozek at redhat.com
Tue Jul 24 05:45:10 UTC 2012


On Mon, Jul 23, 2012 at 06:22:55PM -0400, Rob Crittenden wrote:
> Joe Linoff wrote:
> >Hi Steve:
> >
> >Thank you for your suggestions.
> >
> > > In the gui you can do a hbac test of the rule.
> >
> >I ran the hbactest rule testing from the command line using “ipa
> >hbactest …”. It showed that the rules were correct. Do you think that
> >the GUI might provide a different result?
> 
> No, the GUI and CLI share exactly the same backend code.
> 
> > > Also what are the UIDS?  IPA provided 32bit ones?  or your own?
> >
> >The UID’s were provided by IPA. Actually during testing I also provided
> >my own at one point but reverted back when that didn’t seem to make a
> >difference.
> >
> >Can you explain why that might cause the problem? For example, would
> >duplicates break the system or are there ranges of UIDs that are not legal?
> 
> The issue is if the UIDS are < 1000 they are treated as local in sssd.
> 
> > > I'd suggest re-setting that user's password and get them to login and
> >reset the password, that
> >
> > > works for me, it was a sign of bad/failed replication in my system I
> >think (now fixed).
> >
> >I tried that using kpasswd and “ipa passwd” to change the password but
> >neither solved the problem. In both cases I was able to run “kinit
> >new-user” and set the credentials using the new password but new-user
> >could not ssh in.
> >
> >It was a really strange problem. It looks like something got out of sync
> >but I could not (and cannot) figure out where. It is doubly difficult
> >because removing and re-adding the user worked. In addition, adding
> >other users worked.
> 
> It could be that sssd cached something and wouldn't let it go, too.
> If you can reproduce this it is probably worthwhile bump up the log
> level and add pam debug logging to see what is happening.

As Rob says, I think we should take a look at SSSD and system logs.

Can you paste or attach the couple of lines that are appended to
/var/log/secure during the login attempt? That should give us a clue on
whether the SSSD PAM modules are contacted.

Can you also add "debug_level = 8" to the [pam] and [domain/$name]
sections of the SSSD, restart the SSSD and paste or attach
/var/log/sssd/sssd_pam.log and /var/log/sssd/sssd_$name.log ? Feel free
to sanitize the logs before sending them out.




More information about the Freeipa-users mailing list