Hello Brian, Thanks again for your sincere feedback, that's why I would like to ask the community in the first place. Well, for all remote-only users, I changed sshd code to call fakepw() for them (changed it a bit to use the nobody and netgrp uid and gid respectively), that is to say, all remote-only users will be treated as valid users of nobody/netgrp at the moment, so that public key authentication with LDAP server can take place Once pubkey method authenticates a remote user successfully, a PAM *auth* module is used to optionally allocate unused uid/gid for this remote-only user, and create an entry for it in /etc/passwd, which effectively make the remote-only user local as well, without local password Then I believe sshd will have the unprivileged sshd-session using the same privilege of the user. So the same user can re-login with consistent uid/gid/homeidr/etc on the same device The simulation of nss-ldap includes faking remote-only users valid and using this auth PAM module to make remote-only users local. Admittedly, this works on single device, but there is no consistency across different devices in the same network that remote-only users can all login, in that the auth PAM module individually figure out uid/gid for remote-only users on different devices, resulting in conflict file ownerships / group membership / ACL etc This effectively kills the value of the centralized user management on LDAP server (except their sshPublicKey attribute), and the nss-ldap is a must-have to make use of it Warm regards, Harry On Sat, Oct 12, 2024 at 10:41 PM Brian Candler <b.candler@xxxxxxxxx> wrote: > On 12/10/2024 13:19, Qingtao Cao wrote: > > 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. > > How would the PAM module signal back to sshd which uid/gid has been > selected to switch to? Or are you thinking that sshd starts every > session as root, and you're expecting the PAM session module itself to > switch uid/gid?! > > > > > But will this bring about any unexpected vulnerability? > > It sounds extremely insecure to me, if it were to work at all. > > If you disagree, then I think you would need to lay out, in much more > detail, exactly how you expect PAM to handle the uid/gid switching (in > particular, what happens in each of the "auth", "account" and "session" > calls) > > In any case, even after a user has logged in, you still need to map > uids<->usernames and gids<->groupnames - even for simple cases like > running "id" or "ls -l" - both for the currently logged-in user and all > other users. I don't think you can avoid nss_ldap or sssd. In which > case, just deploy it and then you don't need to mess with sshd. > > That's unless you want all these external remote users to login as the > *same* uid - in which case, you can just create an entry for this shared > account in /etc/passwd. > > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
