openssh unix dev - Oct 2024 - A question about LDAP Public Key authentication with openssh 9.8p1

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 at pobox.com>
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.
>

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.