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 <[email protected]> >> sub 2048R/97AC7685 2014-06-01 [expires: 2019-05-31] > > >
0x1B7F88DC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
