Thank you Brian for your prompt response, much appreciated! Yes, your question just helps me connect dots together. On my device using musl there is no nss-ldap support, no wonder the getpwnam() will return NULL since remote-only users don't exist locally. Since there is no nss-ldap (not to mention sssd), a separate PAM module has been used once the public key authentication is a success, to allocate an unused uid/gid for the remote user, also creating its home directory (which are all specified on the LDAP server but there is no nss-ldap to fetch these configuration) so that the remote-only user can login successfully. Ok, setting authctxt->valid = 1 for invalid user just fakes it to be valid so as to perform public key authentication, which is just a workaround for the lack of nss-ldap to do username mapping. But will this bring about any unexpected vulnerability? the public key authentication will still be performed by the sshd server anyway. If the sshd security is jeopardized I guess there is no way out but to integrate nss-ldap. Thanks again! Harry On Sat, Oct 12, 2024 at 9:13 PM Brian Candler <b.candler@xxxxxxxxx> wrote: > On 12/10/2024 12:04, Qingtao Cao wrote: > > 4. Putting the #2 and #3 points above together, that "goto out;" line will > make the non-local user unable to login the device, despite of the fact > that its RSA public key has been setup properly on the remote LDAP server > > Suppose that user were allowed to login: what UID, GID and home directory > would you expect them to be assigned? > > Don't you still need something like nss_ldap or sssd to perform the > username mapping? And if you had that, getpwnam() would not return NULL. > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
