Hello, I admit the mail subject is a bit alarmist. I'm able to use dropbear with PAM if I only need to check for local accounts.
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. Yet that's still a very important use case (as I see it) : there is a large number of network-based authentication scheme (including, in my very case, TACACS+) where the username/password is not known on the ssh server. PAM allows this, yet dropbear seems to think it's not a good idea. I agree that it comes with some challenges - what's the user shell, credentials... ? So I won't even think to force you to come with a solution right now. I believe it's a point to consider, not that it's a fix to have right now. However, I'm kinda stuck in this case and I have to come with a solution quite fast. I tried to not call checkusername() when PAM is enabled but it looks like it's a Bad Idea (tm) (with it's corresponding segfault, of course). I guess it's because checkusername() does a whole lot that just checking - and as I see it, it also initialize a few data here and there. Do you have any idea on how I could overcome this situation ? I just need to fully trust PAM when it comes to autentication (I'll still need to implement some kind of user mapping after that but it will be easier if I'm able to pass through the authentication process). Best regards, -- Emmanuel Deloget
