Hello, I'm a freeradius beginner and can't get further by my problem for days - reading a lot of stuff in dokumentation, books and forums on the net. Using a debian system with freeradius 2.04 and OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 on it - no NAS or other authenticator is used. Installed freeradius - everything works fine. On my XP client I run NTRadPING with radius secret key, user-name and passwort and get Access-accept response (by chap, by pap - Auth-Type = System; Cleartext-Password, Auth-Type := Local ...) Now I installed pam package: apt-get install -y libpam-radius-auth. make configs (added things are underlined) * /etc/pam_radius_auth.conf:* # server[:port] shared_secret timeout (s) _127.0.0.1 secret 2_ */etc/freeradius/clients.conf:* ... _client 110.110.110.0/24 { secret = secret shortname = private-net }_ ... */etc/pam.d/sshd* # PAM configuration for the Secure Shell service # Read environment variables from /etc/environment and # /etc/security/pam_env.conf. auth required pam_env.so # [1] # In Debian 4.0 (etch), locale-related environment variables were moved to # /etc/default/locale, so read that as well. auth required pam_env.so envfile=/etc/default/locale # Standard Un*x authentication. _auth sufficient pam_radius_auth.so_ @include common-auth # Disallow non-root logins when /etc/nologin exists. account required pam_nologin.so # Uncomment and edit /etc/security/access.conf if you need to set complex # access limits that are hard to express in sshd_config. # account required pam_access.so # Standard Un*x authorization. @include common-account # Standard Un*x session setup and teardown. @include common-session # Print the message of the day upon successful login. session optional pam_motd.so # [1] # Print the status of the user's mailbox upon successful login. session optional pam_mail.so standard noenv # [1] # Set up user limits from /etc/security/limits.conf. session required pam_limits.so # Set up SELinux capabilities (need modified pam) # session required pam_selinux.so multiple # Standard Un*x password updating. @include common-password */etc/freeradius/users* # # # DEFAULT # Service-Type = Administrative-User # On no match, the user is denied access. _"test" Cleartext-Password := "123" "1user" Cleartext-Password := "1user" Fall-Through = No "John" Cleartext-Password := "123" Reply-Message = "Hello, %{User-Name}" "will" Auth-Type = Accept "lameuser" Auth-Type := Reject Reply-Message = "Your account has been disabled." "mike" Auth-Type := Local, User-Password := "mike" "33user" Auth-Type = System Reply-Message = "Hello, %{User-Name}! Dein Passwort kommt aus shadow", Fall-Through = Yes_ To test secure shell session I took a system account with has no entries in the freeradius users-file. The user can log in, but radius-authentication failed. rad_recv: Access-Request packet from host 127.0.0.1 port 5572, id=176, length=89 User-Name = "user" User-Password = "j\205[\022\245\343/X\231\330R@\342\324\023=" NAS-IP-Address = 10.10.10.11 NAS-Identifier = "sshd" NAS-Port = 4547 NAS-Port-Type = Virtual Service-Type = Authenticate-Only Calling-Station-Id = "10.10.10.200" +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated rad_check_password: Found Auth-Type auth: type "PAP" +- entering group PAP rlm_pap: login attempt with password "j?[?¥ã/X?ØR@âÔ?=" rlm_pap: Using CRYPT encryption. rlm_pap: *Passwords don't match* ++[pap] returns reject *auth: Failed to validate the user.* *Login incorrect* (rlm_pap: CRYPT password check failed): [user/j\205[\022\245\343/X\231\330R@\342\324\023=] (from client localhost port 4547 cli 10.10.10.200) WARNING: Unprintable characters in the password. Double-check the shared secret on the server and the NAS! Found Post-Auth-Type Reject +- entering group REJECT expand: %{User-Name} -> user attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 3 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 3 Sending Access-Reject of id 176 to 127.0.0.1 port 5572 Waking up in 4.9 seconds. An other example with a non system-account "will" and Auth-Type = Accept passes radius authentication, but this is not what I want to have. rad_recv: Access-Request packet from host 127.0.0.1 port 5564, id=142, length=89 User-Name = "will" User-Password = "\354-YbQ\367\036\033\034\232\262I\260\327\322\013" NAS-IP-Address = 10.10.10.11 NAS-Identifier = "sshd" NAS-Port = 4539 NAS-Port-Type = Virtual Service-Type = Authenticate-Only Calling-Station-Id = "10.10.10.200" +- entering group authorize ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "will", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound users: Matched entry will at line 212 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rlm_pap: Found existing Auth-Type, not changing it. ++[pap] returns noop rad_check_password: Found Auth-Type Accept rad_check_password: Auth-Type = Accept, accepting the user Login OK: [will/\354-YbQ\367\036\033\034\232\262I\260\327\322\013] (from client localhost port 4539 cli 10.10.10.200) +- entering group post-auth ++[exec] returns noop Sending Access-Accept of id 142 to 127.0.0.1 port 5564 Finished request 2. Going to the next request Waking up in 5.0 seconds. Cleaning up request 2 ID 142 with timestamp +118 Ready to process requests. The shared_secret in clients.conf and pam_radius_auth.conf are the same, and there are no spaces. perhaps it may be a problem with the tool puTTy (for manageing ssh-sessions) - here I can't find any location to place the shared_secret from the two files. But if I had changed system-authentication instead of sshd, there is the same problem with the diffrent passwords - and I'm sure they are written right. Any suggestions? Any hinds are welcome. Greets MM