Why can users just not login with SSH while everything else seems to work?

Question

I have set up a pair of OpenLDAP servers on Ubuntu 20 with directional failover using Syncrepl. Things that an LDAP user can successfully do include:

• login
• su - <uid>
• remote bind from PHPLDAPAdmin or Apache Directory Studio
• id <uid>

However, the same LDAP user cannot use SSH to login. (Local users can.) The following is an extract from the OpenLDAP server log:

Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 fd=20 ACCEPT from IP=127.0.0.1:60066 (IP=0.0.0.0:389)
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=0 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" method=128
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=0 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" mech=SIMPLE ssf=0
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=0 RESULT tag=97 err=0 text=
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=1 SRCH base="dc=house,dc=878,dc=home,dc=arpa" scope=2 deref=0 filter="(uid=webmin)"
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=1 SRCH attr=host authorizedService shadowExpire shadowFlag shadowInactive shadowLastChange shadowMax shadowMin shadowWarning uidNumber
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=2 BIND anonymous mech=implicit ssf=0
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=2 BIND dn="uid=webmin,ou=users,dc=house,dc=878,dc=home,dc=arpa" method=128
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=2 RESULT tag=97 err=49 text=
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=3 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" method=128
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=3 BIND dn="cn=admin,dc=878,dc=home,dc=arpa" mech=SIMPLE ssf=0
Oct 19 18:29:38 s-tow-01 slapd[15532]: conn=1185 op=3 RESULT tag=97 err=0 text=

The bind attempt for the user (uid=webmin) results in error 49, i.e. invalid credentials. The very same credentials are, however, valid for the other cases listed above.

I have had this problem for some while now, and, in my despair, I tried to solve it by installing SSSD. This is only important to explain that, in the log above, I don't know in the first line (ACCEPT from IP=127.0.0.1:60066) whether the OpenLDAP server is talking to SSSD or SSH. It seems clear, though, that it is not speaking StartTLS, which is otherwise does. Is that significant? Would the OpenLDAP server reject an authentication attempt on principle because it isn't StartTLS?

I have run pam-auth-update and told it that I'm using LDAP, SSSD, etc., but it made no difference despite one or two small changes in the common-* files.

I don't know how to debug this. And I've run out of things to google. Can anyone help me please?

Answer 1

A very simple brute force way to maybe rapidly find out what you are missing or which file may need editing (as you mention that the user is known and can perform many things, it may just need its name to be added in some file under /etc) :

# compare with another regular username (ex: "smith") that can log in via ssh
 grep -rl "smith"  /etc # and look particularly : ssh related files, sudoers, etc
 grep -rl "webmin" /etc # and compare, see what's missing

Answer 2

I have found the answer to my problem. The short answer is that the following line needs to be added to /etc/ssh/sshd_config, at least in Ubuntu 20:

PAMAuthenticationViaKbdInt yes

LDAP-authenticated SSH then works.

However, systemctl status ssh throws up the following warning: Deprecated option PAMAuthenticationViaKbdInt so this is only a temporary solution. If anyone knows how to fix this problem AND avoid using PAMAuthenticationViaKbdInt, please add that as an answer. I will then mark that as the accepted answer.