Help - SSH with Radius on one Server: no password match by authentication over sshd --- password match over NTRadPING
Marius.Meisner
marius.meisner at googlemail.com
Mon Jan 24 01:19:29 CET 2011
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
/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
More information about the Freeradius-Users
mailing list