Bug 2208941

+++ This bug was initially created as a clone of Bug #2182858 +++

Description of problem:

The pam_radius module generates an error when attempting to authenticate a login on a system that does not have IPv6 enabled.


Version-Release number of selected component (if applicable):

2.0.0-2


How reproducible:

Configure a system to utilize the pam_radius module, but disable IPv6 at the system level.


Steps to Reproduce:
1. Disable IPv6
2. Configure pam_radius
3. Attempt a login


Actual results:

sshd: pam_radius_auth: Failed to open RADIUS IPv6 socket: Address family not supported by protocol


Expected results:

User is authenticated via pam_radius.


Additional info:

Based on the defect noted here (https://github.com/FreeRADIUS/freeradius-server/issues/4397), it sounds like the pam_radius module was forcing connections to use IPv6, even when the system didn't support it.  A patch was released recently (https://github.com/FreeRADIUS/pam_radius/commit/8d373539bb9f13b0abfe8bcae0095a930a00fad0) which allows disabling IPv6, so that pam_radius will utilize IPv4 instead.

Please update the pam_radius module in EPEL 8 to include this patch, as this is preventing systems from authenticating via RADIUS.

--- Additional comment from Iker Pedrosa on 2023-03-30 07:41:29 UTC ---

If I create a test build, would you be willing to test it to see if the fix is working?

--- Additional comment from Don on 2023-03-30 13:44:49 UTC ---

(In reply to Iker Pedrosa from comment #1)
> If I create a test build, would you be willing to test it to see if the fix
> is working?

Absolutely!

--- Additional comment from Don on 2023-03-30 13:50:45 UTC ---

To add to this, yesterday after opening this Bugzilla request, I downloaded the latest source code bundle from their Github page, and confirmed the error has gone away, and packets seem to be flowing via IPv4 as expected.  That said, I don't like running systems from source tarballs that I've compiled myself, and I have to distribute this to hundreds (possibly thousands) of systems, so I would like to get it into RPM format.  I figured this Bugzilla request would be the correct way to ensure the EPEL package was updated, so that I can continue to utilize our normal installation/patching methodology.

--- Additional comment from Iker Pedrosa on 2023-03-30 14:47:57 UTC ---

Yes, this is the right place to open such a ticket.

The COPR repository where I provide the test rpm is https://copr.fedorainfracloud.org/coprs/ipedrosa/pam-radius-test. This is just a test build and I don't intend to maintain it for long.

The instructions to install the test rpm are quite easy:
1- dnf copr enable ipedrosa/pam-radius-test 
2- dnf update pam_radius

--- Additional comment from Iker Pedrosa on 2023-04-13 08:25:56 UTC ---

Don, were you able to test it?

--- Additional comment from Don on 2023-04-18 20:05:09 UTC ---

My apologies for the delay, sidetracked with other issues!

I have downloaded the new packages and am working with my RADIUS folks to setup another test.  I suspect to have results in the next day or two.

Thank you for being super quick to respond!

--- Additional comment from Don on 2023-04-28 22:39:59 UTC ---

# include sanitized_names_and_ip_addresses
# =)

Getting very different results from the systems where I compiled the latest FreeRadius pam_radius code from source, and where I installed your test COPR package.

192.168.199.11  == RADIUS server
192.168.199.50  == "tarball-client" == Server using the client from source tarball
192.168.199.51  == "copr-client"    == Server using the client from COPR
192.168.199.101 == "workstation"    == Workstation where I'm connecting from

The way I have PAM configured, it should prompt for a TokenCode from the RADIUS server, and if successful, it should then prompt for Active Directory credentials, as configured in SSSD.  Without the RADIUS stuff enabled, the Active Directory/SSSD configuration works great, so I know that's not the problem.  Also, the combination works fine if using the pam_radius compiled from the source tarball (using the "Download .ZIP" option from https://github.com/FreeRADIUS/pam_radius/).

(And it's entirely possible my PAM isn't setup all that well, but it's good enough to be "working" with the source compiled pam_radius, so I didn't configure it TOO badly..)

I suspect there's still something amiss with the pam_radius RPM (maybe additional bugs in the source version utilized?), but I'm not exactly sure how it's configured and compiled, so it's hard to say for certain.  My source tarball was a pretty simple "make" and "make install" or something along those lines; nothing super complicated.

For example, you can see from the /etc/pam.d/sshd entry that I have debugging turned on, but there's no debugging showing up in the logs on the COPR/RPM system, but plenty of debug info on the source tarball system.

-----

Test to system using latest pam_radius RPM uploaded to COPR

-----

[user@workstation ~]$ ssh radtestuser.199.51

##############################################################################
 This computer system and associated networks are for the sole business use
 of Daddy's authorized users.  The company's computers and proprietary data
 and information stored on them remain at all times the property of Daddy.
 Users have no right to privacy as to any information transmitted or stored
 in, by, or through any portion of this system.
##############################################################################

radtestuser.199.51's password:        <- Not prompted for TokenCode, but if I put it in anyway, the RADIUS does succeed, as shown in the logs, but immediately fails SSSD
Permission denied, please try again.
radtestuser.199.51's password:

-----

[root@copr-client ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.7 (Ootpa)

[root@copr-client ~]# rpm -qi pam_radius
Name        : pam_radius
Version     : 2.0.0
Release     : 3.el8
Architecture: x86_64
Install Date: Mon 17 Apr 2023 07:25:22 PM UTC
Group       : Unspecified
Size        : 66531
License     : GPLv2+
Signature   : RSA/SHA256, Thu 30 Mar 2023 02:29:27 PM UTC, Key ID 8c67479fe25b3dc5
Source RPM  : pam_radius-2.0.0-3.el8.src.rpm
Build Date  : Thu 30 Mar 2023 02:29:23 PM UTC

[root@copr-client ~]# grep -v ^# /etc/pam_radius.conf
192.168.199.11     t0ps3cr3t     3     0

[root@copr-client ~]# grep ^auth /etc/pam.d/sshd
auth       required     pam_radius_auth.so prompt=TokenCode ipv6=no debug
auth       sufficient   pam_sss.so prompt_always forward_pass
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin

[root@copr-client ~]# tail -f /var/log/secure
Apr 28 21:55:56 copr-client sshd[3110]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Apr 28 21:56:06 copr-client sshd[3110]: pam_radius_auth: Got user name radtestuser
Apr 28 21:56:06 copr-client sshd[3110]: pam_radius_auth: ignore last_pass, force_prompt set
Apr 28 21:56:06 copr-client sshd[3110]: pam_radius_auth: Sending RADIUS request code 1
Apr 28 21:56:06 copr-client sshd[3110]: pam_radius_auth: DEBUG: get_ipaddr(192.168.199.11) returned 0.
Apr 28 21:56:07 copr-client sshd[3110]: pam_radius_auth: Got RADIUS response code 2
Apr 28 21:56:07 copr-client sshd[3110]: pam_radius_auth: authentication succeeded
Apr 28 21:56:07 copr-client sshd[3110]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.199.101 user=radtestuser
Apr 28 21:56:07 copr-client sshd[3110]: pam_sss(sshd:auth): received for user radtestuser: 7 (Authentication failure)
Apr 28 21:56:07 copr-client sshd[3110]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.199.101 user=radtestuser
Apr 28 21:56:07 copr-client sshd[3110]: pam_sss(sshd:auth): received for user radtestuser: 7 (Authentication failure)
Apr 28 21:56:09 copr-client sshd[3110]: Failed password for radtestuser from 192.168.199.101 port 34972 ssh2

-----

Test to system using latest source tarball, compiled and installed with default options

-----

[don.head@dc2jump2 ~]$ ssh radtestuser.199.50

##############################################################################
 This computer system and associated networks are for the sole business use
 of Daddy's authorized users.  The company's computers and proprietary data
 and information stored on them remain at all times the property of Daddy.
 Users have no right to privacy as to any information transmitted or stored
 in, by, or through any portion of this system.
##############################################################################

TokenCode:      <- Entered TokenCode, which is handled successfully by RADIUS
Password:       <- Entered AD credentials, which is handled successfully by SSSD

Last login: Fri Apr 28 21:27:43 2023 from 192.168.199.101

[radtestuser@tarball-client ~]$

-----

[root@tarball-client ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.7 (Ootpa)

[root@tarball-client ~]# cat /usr/local/src/pam_radius-master/VERSION
2.0.1

[root@tarball-client ~]# grep -v ^# /etc/pam_radius_auth.conf
192.168.199.11     t0ps3cr3t     3     0

[root@tarball-client ~]# grep ^auth /etc/pam.d/sshd
auth       required     pam_radius_auth.so prompt=TokenCode ipv6=no debug
auth       sufficient   pam_sss.so prompt_always forward_pass
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin

[root@tarball-client ~]# tail -f /var/log/secure
Apr 28 22:12:35 tarball-client sshd[2387631]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Apr 28 22:12:35 tarball-client sshd[2387634]: pam_radius_auth: 2.0.1, built on Mar 29 2023 at 20:47:24
Apr 28 22:12:35 tarball-client sshd[2387634]: pam_radius_auth: DEBUG: conf='/etc/pam_radius_auth.conf' use_first_pass=no try_first_pass=no skip_passwd=no retry=0 localifdown=no client_id='' accounting_bug=no ruser=no prompt='TokenCode: ' force_prompt=no prompt_attribute=no max_challenge=0 privilege_level=no
Apr 28 22:12:35 tarball-client sshd[2387634]: pam_radius_auth: Got user name: 'radtestuser'
Apr 28 22:12:35 tarball-client sshd[2387634]: pam_radius_auth: ignore last_pass, force_prompt set
Apr 28 22:12:43 tarball-client sshd[2387634]: pam_radius_auth: Sending RADIUS request code 1 (Access-Request)
Apr 28 22:12:43 tarball-client sshd[2387634]: pam_radius_auth: DEBUG: get_ipaddr(192.168.199.11) returned 0.
Apr 28 22:12:44 tarball-client sshd[2387634]: pam_radius_auth: Got RADIUS response code 2 (Access-Accept)
Apr 28 22:12:44 tarball-client sshd[2387634]: pam_radius_auth: authentication succeeded
Apr 28 22:12:49 tarball-client sshd[2387634]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.199.101 user=radtestuser
Apr 28 22:12:49 tarball-client sshd[2387631]: Accepted keyboard-interactive/pam for radtestuser from 192.168.199.101 port 38134 ssh2
Apr 28 22:12:49 tarball-client sshd[2387631]: pam_unix(sshd:session): session opened for user radtestuser by (uid=0)

-----

What else do you need from me to try and help resolve this?

--- Additional comment from Don on 2023-04-28 22:42:13 UTC ---

TLDR Summary:  I think you fixed the IPv6 error, but now I think I'm hitting another issue.

--- Additional comment from Don on 2023-04-28 23:08:18 UTC ---

Oof, okay, I take that back.  The one thing I just realized I didn't do was compare my /etc/ssh/sshd_config files.  I had made one change per the Token vendor's documentation, and not applied that to both systems.

-----

[root@copr-client ~]# diff /etc/ssh/sshd_config.orig /etc/ssh/sshd_config
74c74
< ChallengeResponseAuthentication no
---
> ChallengeResponseAuthentication yes

-----

I can now confirm that your updated COPR RPM does fix the IPv6 problem, as originally identified by this ticket.

The COPR RPM does -NOT- allow for enabling of debugging, as the source code compiled version does.  I'm not sure if that's a new feature added between 2.0.0 and 2.0.1 or what.

With that said, I can at least confirm I am no longer blocked.

If you wanted to update the RPM to even later code to see if the debugging works, that would be great, but at this point, I'm at least satisfied with where we are.

--- Additional comment from Iker Pedrosa on 2023-05-02 08:22:50 UTC ---

Thanks for testing! I'll start porting the changes, but it'll take some time as I need to follow a precise order before arriving to Fedora EPEL.