[Swan] XAUTH: PAM auth chain failed with '7' on CentOS 7

Remy van Elst relst at relst.nl
Fri Aug 22 17:55:45 EEST 2014



On 08/22/14 16:44, Matt Rogers wrote:
> On 08/22, Remy van Elst wrote:
>>
>>
>> On 08/22/14 16:30, Matt Rogers wrote:
>>> On 08/22, Remy van Elst wrote:
>>>> How would I apply this to system/PAM authentication? The passwords in
>>>> the shadow file are SHA512 ($6$...)
>>>>
>>> chpasswd(8) can do that, but the pam method in pluto doesn't run anything
>>> through crypt (it will leave the password verification to the pam stack),
>>> and crypt would support the SHA512 type. Is your system-auth configuration much
>>> different than the RHEL/CentOS default?
>>
>> It is a default CentOS (7) shadow file.
>>
> Sorry, I meant /etc/pam.d/system-auth
> 

That is also a default CentOS 7 one. The only file modified is the
/etc/pam.d/pluto file to paul's instructions, but that has no effect.

> Matt
> 
>>>
>>> Matt
>>>
>>>>
>>>>
>>>> On 08/21/14 21:15, Matt Rogers wrote:
>>>>> On 08/21, Pontus Wiberg wrote:
>>>>>> FYI did a new setup on a Ubuntu server with no additional software but
>>>>>> Libreswan and the requirements, a clean setup, clean ipsec.conf, getting
>>>>>> the same error. The password is incorrectly handled by Libreswan or some
>>>>>> dependency somewhere, same error as I've had on Openswan too.
>>>>>>
>>>>>> Is there anything I can do to help narrow this down?
>>>>>>
>>>>>>  ****parse ISAKMP ModeCfg attribute:
>>>>>> |    ModeCfg attr type: 16521??
>>>>>> |    length/value: 8  *<-- username is correct and 8 chars*
>>>>>> | ****parse ISAKMP ModeCfg attribute:
>>>>>> |    ModeCfg attr type: 16522??
>>>>>> |    length/value: 12 *<-- password is correct and 12 chars*
>>>>>> | complete state transition with STF_IGNORE
>>>>>> | * processed 0 messages from cryptographic helpers
>>>>>> | next event EVENT_DPD in 15 seconds for #1
>>>>>> | next event EVENT_DPD in 15 seconds for #1
>>>>>> XAUTH: User testuser: Attempting to login
>>>>>> XAUTH: passwd file authentication being called to authenticate user testuser
>>>>>> XAUTH: password file (/etc/ipsec.d/passwd) open.
>>>>>> | XAUTH: found user(testuser/testuser) pass($apr1$RXWgYKAc$***********/)
>>>>>> connid(roadwarrior/roadwarrior)
>>>>>> | XAUTH: checking user(testuser:roadwarrior) pass (null) vs
>>>>>> $apr1$RXWgYKAc$***********/ *<-- password is now: (null)*
>>>>>> XAUTH: nope
>>>>>> XAUTH: User testuser: Authentication Failed: Incorrect Username or Password
>>>>>>
>>>>>
>>>>> I found this to be the result of crypt() failing when passed the default
>>>>> htpasswd created hash. The $apr1$ part specifies an ID that crypt doesn't seem
>>>>> to support. If you want to work around this you can add -d to the htpasswd
>>>>> option and that will give you a crypt() compatible hash (or use a different tool
>>>>> to create one of the types mentioned in crypt(3))
>>>>>
>>>>> So we'll need to handle this hash type seperately, or not recommend htpasswd like we
>>>>> do currently in the code comments.
>>>>>
>>>>> Regards,
>>>>> Matt
>>>>>
>>>
>>>> pub  2048R/1B7F88DC 2014-06-01 Remy van Elst <relst at relst.nl>
>>>> sub  2048R/97AC7685 2014-06-01 [expires: 2019-05-31]
>>>
>>>
>>>
> 
>> pub  2048R/1B7F88DC 2014-06-01 Remy van Elst <relst at relst.nl>
>> sub  2048R/97AC7685 2014-06-01 [expires: 2019-05-31]
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x1B7F88DC.asc
Type: application/pgp-keys
Size: 1714 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20140822/a91561e0/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20140822/a91561e0/attachment-0001.sig>


More information about the Swan mailing list