pam_radius_auth delay

[Steve Phillips]

Hey Alan,

That’s because the radius system is working fine. The question pertains around why there is a 20 second delay between the user typing the password in and the radius request being generated and put on the wire, not around the radius server receiving the packet and responding to it (less than a second)

Cheers,

-- 
Steve.

On 28/04/2017, 5:27 PM, "Freeradius-Users on behalf of Alan Buxey" <freeradius-users-bounces+steve=focb.co.nz at lists.freeradius.org on behalf of alan.buxey at gmail.com> wrote:

    No debug output of the radiusd here.
    
    alan
    
    On 28 Apr 2017 7:36 am, "Steve Phillips" <steve at focb.co.nz> wrote:
    
    > Hi There,
    >
    > I've just setup pam_radius_auth and it is working, however there seems to
    > be a weird 20 second delay for no apparent reason between getting the
    > password from the prompt and sending the authentication request to the
    > RADIUS server.
    >
    > The version of pam_radius_auth is 1.4.0 obtained from the CentOS 7 EPEL
    > repository
    >
    > I have entries for the RADIUS server in /etc/hosts but have tried both a
    > hostname and an IP address in /etc/pam_radius.conf and the effect is the
    > same.
    >
    > My sshd pam entries are set as follows
    >
    > -- begin snippet --
    > auth [success=ignore default=1] pam_succeed_if.so debug user ingroup radius
    > auth       required     pam_radius_auth.so debug conf=/etc/pam_radius.conf
    > auth       required     pam_sepermit.so
    > auth       substack     password-auth
    > auth       include      postlogin
    > -- end --
    >
    > The logs are as follows
    >
    > -- begin logs --
    > Apr 28 16:09:40 bastion sshd[9197]: pam_radius_auth: Got user name
    > stevetest
    > Apr 28 16:09:40 bastion sshd[9197]: pam_radius_auth: ignore last_pass,
    > force_prompt set
    > Apr 28 16:10:00 bastion sshd[9197]: pam_radius_auth: Sending RADIUS
    > request code 1
    > Apr 28 16:10:00 bastion sshd[9197]: pam_radius_auth: DEBUG:
    > getservbyname(radius, udp) returned 0x7f05695fa1c0.
    > Apr 28 16:10:00 bastion sshd[9197]: pam_radius_auth: Got RADIUS response
    > code 2
    > Apr 28 16:10:00 bastion sshd[9197]: pam_radius_auth: authentication
    > succeeded
    > -- end logs --
    >
    > and the server entry is (less the lines starting with a #)
    >
    > # cat /etc/pam_radius.conf | egrep -v ^#
    > auth1 somesecret 3
    > 172.28.208.169:1812 somesecret 3
    >
    > (If I comment auth1 out the effect is identical - a 20 second delay)
    >
    > The 20 seconds sounds like a timeout of some sort but I'm at a bit of a
    > loss what this would be. Just wondering if anyone else has come across this?
    >
    > OS: CentOS 7.3.1611, minimal installation, patched to whatever the latest
    > patch cluster was as of a week ago.
    >
    > Any ideas would be appreciated,
    >
    > Cheers,
    >
    > --
    > Steve.
    >
    >
    > -
    > List info/subscribe/unsubscribe? See http://www.freeradius.org/
    > list/users.html
    -
    List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5610 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170429/acc9f50f/attachment.bin>