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.
If I create a test build, would you be willing to test it to see if the fix is working?
(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!
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.
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
Don, were you able to test it?
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!
# 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?
TLDR Summary: I think you fixed the IPv6 error, but now I think I'm hitting another issue.
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.
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.
FEDORA-EPEL-2023-c9b892c43f has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c9b892c43f
FEDORA-EPEL-2023-c9b892c43f has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c9b892c43f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-c9b892c43f has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.