Enabling hashed passwords

[Andrew Gin]

Hi
I've trawled looking for a solution for this, but there doesn't seem
to be a clearcut answer. I am using Freeradius 1.1.7.
I'm trying to make it so that in the users file, passwords are stored
as a SHA hash.

So my users file looks like this:
asdf SHA-Password == 3da541559918a808c2402bba5012f6c60b27661c

When I try to login, it with the -X option, it says:

rad_recv: Access-Request packet from host 127.0.0.1:3381, id=73, length=89
       User-Name = "asdf"
       User-Password = "asdf"
       NAS-Identifier = "vty0"
       NAS-Port = 2356
       NAS-Port-Type = Virtual
       Service-Type = Authenticate-Only
       Calling-Station-Id = "::ffff:192.168.1.10"
 Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
 modcall[authorize]: module "preprocess" returns ok for request 0
 modcall[authorize]: module "chap" returns noop for request 0
 modcall[authorize]: module "mschap" returns noop for request 0
   rlm_realm: No '@' in User-Name = "asdf", looking up realm NULL
   rlm_realm: No such realm "NULL"
 modcall[authorize]: module "suffix" returns noop for request 0
 rlm_eap: No EAP-Message, not doing EAP
 modcall[authorize]: module "eap" returns noop for request 0
 modcall[authorize]: module "files" returns notfound for request 0
rlm_pap: WARNING! No "known good" password found for the user.
Authentication may fail because of this.
 modcall[authorize]: module "pap" returns noop for request 0
modcall: leaving group authorize (returns ok) for request 0
auth: No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user
auth: Failed to validate the user.
Login incorrect: [asdf] (from client 127.0.0.1 port 2356 cli
::ffff:192.168.1.10)
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 73 to 127.0.0.1 port 3381
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 73 with timestamp 4993eaec
Nothing to do.  Sleeping until we see a request.

However when I change the users file to:
asdf User-Password == asdf

With the -X option, I can now login:

rad_recv: Access-Request packet from host 127.0.0.1:3414, id=60, length=89
       User-Name = "asdf"
       User-Password = "asdf"
       NAS-Identifier = "vty0"
       NAS-Port = 2389
       NAS-Port-Type = Virtual
       Service-Type = Authenticate-Only
       Calling-Station-Id = "::ffff:192.168.1.10"
 Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
 modcall[authorize]: module "preprocess" returns ok for request 0
 modcall[authorize]: module "chap" returns noop for request 0
 modcall[authorize]: module "mschap" returns noop for request 0
   rlm_realm: No '@' in User-Name = "asdf", looking up realm NULL
   rlm_realm: No such realm "NULL"
 modcall[authorize]: module "suffix" returns noop for request 0
 rlm_eap: No EAP-Message, not doing EAP
 modcall[authorize]: module "eap" returns noop for request 0
   users: Matched entry asdf at line 4
 modcall[authorize]: module "files" returns ok for request 0
 modcall[authorize]: module "pap" returns updated for request 0
modcall: leaving group authorize (returns updated) for request 0
 rad_check_password:  Found Auth-Type pap
auth: type "PAP"
 Processing the authenticate section of radiusd.conf
modcall: entering group PAP for request 0
rlm_pap: login attempt with password asdf
rlm_pap: Using clear text password "asdf".
rlm_pap: User authenticated successfully
 modcall[authenticate]: module "pap" returns ok for request 0
modcall: leaving group PAP (returns ok) for request 0
Login OK: [asdf] (from client 127.0.0.1 port 2389 cli ::ffff:192.168.1.10)
Sending Access-Accept of id 60 to 127.0.0.1 port 3414
       Service-Type = Administrative-User
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 60 with timestamp 4993edaf
Nothing to do.  Sleeping until we see a request.

---
Is it as simple as changing User-Password to SHA-Password? There are
various solutions which require changing the pap encryption_scheme
attribute but I think these were made obsolete?

It is this line at which they differ:
success:
 modcall[authorize]: module "eap" returns noop for request 0
   users: Matched entry asdf at line 4
 modcall[authorize]: module "files" returns ok for request 0
 modcall[authorize]: module "pap" returns updated for request 0

fail:
 modcall[authorize]: module "eap" returns noop for request 0
 modcall[authorize]: module "files" returns notfound for request 0
rlm_pap: WARNING! No "known good" password found for the user.
Authentication may fail because of this.
 modcall[authorize]: module "pap" returns noop for request 0

I had a look in the code just to see why it was failing and
file_authorize (in rlm_files.c) calls paircmp (in valuepair.c). The
relevant section goes:
               /*
                *      Not found, it's not a match.
                */
               if (auth_item == NULL) {
                       /*
                        *      Didn't find it.  If we were *trying*
                        *      to not find it, then we succeeded.
                        */
                       if (check_item->operator == T_OP_CMP_FALSE)
                               return 0;
                       else
                               return -1; <-SHA-Password quits here
               }

When the password is User-Password, auth_item is NOT null, processing
continues. But when SHA-Password is used, it returns -1.
Have I missed something obvious, or is this just a red herring?

My config is quite large, but here are the relevant parts:
authorize {
       preprocess
       chap
       mschap
       suffix
       eap
       files
       pap
}

authenticate {
       Auth-Type PAP {
               pap
       }
...
}
modules {
       pap {
               auto_header = yes
       }