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

[Remy van Elst]

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.

> 
> 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]
> 
> 
> 
-------------- 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/a6902f7d/attachment.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/a6902f7d/attachment.sig>