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

[Matt Rogers]

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?

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]