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