Failure to use dropbear with PAM

[DELOGET, Emmanuel]

Hello Matt, 

> De : Matt Johnston [matt at ucc.asn.au]
> On Wed, Aug 20, 2014 at 01:25:21PM +0000, DELOGET, Emmanuel wrote:
> > Hello,
> >
> > Yet in my use case I have to authenticate users whose 
> > login/password information is stored in a distant database. 
> > Everytime I try to log in with such a user, dropear answers 
> > me that the user is unknown - and that's true : the user is 
> > unknown, because the whole point is to not have him/her 
> > in /etc/passwd but on a distant database.
> >
> > That's where things break : dropbear seems to assume that 
> > the user must be known on the system where it runs - that's 
> > one of the purpose of checkusername() in svr-auth.c. If the 
> > user is not found in /etc/passwd then it's not a valid user and 
> > login fails.
>
> Hi Emmanuel,
> 
> Is this a normal Unix type system or something more
> embedded? From what I've seen the normal approach for remote

I'm working in the embedded world.  

> DB auth (LDAP etc) is to have nsswitch.conf set up to know
> about the users, then optionally a PAM module if there isn't
> a straightforward mapping to Unix password crypts. Would
> that work for your situation? The benefit there is that all
> programs know about the user using the standard user APIs.

If I had though to that before, I would have tried to do it that
way. Unfortunately, I'm a bit too late in the development cycle.

> Dropbear's PAM currently only allows username/password,
> though there's a dev branch that should allow kind of
> authentication conversation. It doesn't handle user
> remapping though since that seems out of PAM's scope. Note
> that the branch also needs some attention in terms of setting up PAM
> login sessions properly.

I tried to go another route - a dirty hack that does not please
me (and it won't please you either ; see the attached patch) : when I 
don't know the username, I still accept it (I fill the authstate structure 
by myself using somewhat dummy values). After a successful auth, I 
refill the authstate structure with the unix mapped user (root in this 
case, which is silly but sufficiently extreme to show me that everything 
worked as intended). This is cheap and hacky (please, don't judge 
me :))

(BTW the above patch, against an olfder version of dropbear, enables
a command line option -A to tell dropbear to favor PAM auth instead
of password auth - both can be activated with the change. If you beleive 
it might be interesting I can refine this patch against the latest tree). 

> Cheers,
> Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enable_PAM_with_-A_cmdline_options.patch
Type: text/x-patch
Size: 4208 bytes
Desc: enable_PAM_with_-A_cmdline_options.patch
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20140821/0d7f362d/attachment.bin