openssh bugs - Sep 2024 - [Bug 3736] New: sshd falls back to password prompt after PAM module returns a PAM_MAXTRIES.

https://bugzilla.mindrot.org/show_bug.cgi?id=3736

            Bug ID: 3736
           Summary: sshd falls back to password prompt after PAM module
                    returns a PAM_MAXTRIES.
           Product: Portable OpenSSH
           Version: 9.8p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: PAM support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: thibault.delmas at lxp.lu

It is more a question about if it is an intended behavior or not.

Overview:

I am working on a PAM module where I either allow a user to provide us
with an OTP code or if his account doesn't have one, I print the link
to set it up and stop the authentication. When a user doesn't have OTP
enabled, ssh prints 3 times the link because the user has 3 tries on
the sshd side of things. To prevent that I tried to use the
PAM_MAXTRIES return code in my PAM module. Instead of honoring the max
tries and stopping the connection attempt, sshd falls back to a
password prompt.

Steps to Reproduce:

For the purpose of the ticket I went and downloaded the latest 9.8p1
openssh portable and compiled it with:

configure --prefix=/opt --sysconfdir=/etc/ssh-portable --with-pam

This minimum setup to reproduce are these config files for sshd_config
and pam.d/sshd:

# /opt/sbin/sshd -V
OpenSSH_9.8p1, OpenSSL 3.0.7 1 Nov 2022

# grep -v '#' /etc/ssh-portable/sshd_config | grep -v -e '^$'
KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive:pam
UsePAM yes
SyslogFacility AUTHPRIV
LogLevel DEBUG
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

# grep -v '#' /etc/pam.d/sshd | grep -v -e '^$'
auth required pam_module.so

Running on rocky94.

The pam module, compiled with gcc -shared -o pam_module.so min.c -lpam,
and put in /usr/lib64/security/pam_module.so:

cat min.c
#include <security/pam_misc.h>
#include <security/pam_ext.h>
#include <security/pam_modules.h>

PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags, int
argc, const char **argv)
{
        return PAM_MAXTRIES;
}

PAM_EXTERN int pam_sm_setcred(pam_handle_t *pamh, int flags, int argc,
const char **argv)
{
    return PAM_SUCCESS;
}

Expected behavior:

ssh connection attempt should instantly terminates instead of asking
for a password prompt.

Current behavior:

ssh tdelmas at test-vm
tdelmas at test-vm's password: 
Permission denied, please try again.
tdelmas at test-vm's password: 
Permission denied, please try again.
tdelmas at test-vm's password: 
tdelmas at test-vm: Permission denied ().


Is there a way for me to achieve my intended behavior? Am I wrong to
assume sshd would "honor" the PAM_MAXTRIES with my current
configuration?

Thanks in advance for your feedback, hopefully posting at the right
spot.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3736

--- Comment #1 from thibault.delmas at lxp.lu ---
No matter if the password is correct or not the user is not allowed in.
This does not happen if the ssh client also specifies -o
PasswordAuthencation=no

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3736

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net>
---
>From PAM's perspective, the SSH "password" authentication
attempt and
the "keyboard-interactive" one are separate PAM auth attempts.  For
your use case, you probably want to disable PasswordAuthentication in
the server's sshd_config.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3736

--- Comment #3 from thibault.delmas at lxp.lu ---
Hi Daren, thank you for reading me,

# grep -v '#' /etc/ssh-portable/sshd_config | grep -v -e '^$'
KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive:pam
UsePAM yes
SyslogFacility AUTHPRIV
LogLevel DEBUG
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

I pasted my ssh config, I was under the impression that 

PasswordAuthentication no

did indeed disable password authentication.

After some more testing, if I use PAM_ABORT exit code instead of
PAM_MAXTRIES, sshd does exist without falling back to a password
prompt.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3736

--- Comment #4 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to thibault.delmas from comment #3)
[...]
> I pasted my ssh config, I was under the impression that 
> PasswordAuthentication no
> did indeed disable password authentication.
It does, however the prompts look like passwordauthentication ones, and

(In reply to thibault.delmas from comment #1)
> This does not happen if the ssh client also specifies -o
PasswordAuthencation=no
indicates it's not actually disabled.

Are you sure you're looking at the right config file location?  Using
sshd -T to dump the effective config will check that it's reading the
one you think it is:

$ sudo /usr/sbin/sshd -T | grep passwordauth
passwordauthentication yes

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3736

--- Comment #5 from thibault.delmas at lxp.lu ---
[root at test-vm ~]# sshd -T | grep passwordauth
passwordauthentication no

As I said I got it to work with PAM_ABORT instead and I don't want to
be bothersome.

I redid a test with a dump of the sshd config at the beginning:

[root at pam-test-td ~]# sshd -T | grep passwordauth
passwordauthentication no
[root at pam-test-td ~]# cat /etc/pam.d/sshd | grep -v '#'
auth required pam_module.so

#Replace the pam module with the pam_maxtries.so one
[root at pam-test-td ~]# cp /tmp/pam_maxtries.so
/usr/lib64/security/pam_module.so 
cp: overwrite '/usr/lib64/security/pam_module.so'? y

#in a second terminal try to ssh
ssh tdelmas at test-vm
tdelmas at test-vm's password: <enter anything>
Received disconnect from 10.40.0.33 port 22:2: Too many authentication
failures
Disconnected from 10.40.0.33 port 22

#back to the vm replace the shared module by the one returning pam
abort

[root at pam-test-td ~]# cp /tmp/pam_abort.so
/usr/lib64/security/pam_module.so 
cp: overwrite '/usr/lib64/security/pam_module.so'? y

#back to the second terminal

ssh tdelmas at test-vm
tdelmas at test-vm: Permission denied (keyboard-interactive).

Here I don't get password prompted.

The two modules pam_abort and pam_maxtries were compiled with the same
min.c file (from my original message) with only the return value being
changed.

I am happy to do further testing if you think there might be something
behind this but else, I get the behavior I wanted with PAM_ABORT and I
think I can live with it so I can change the case status.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.