If pam is available it uses it automatically. Make sure that you have an
/etc/pam.d/ppp file
Eg
#%PAM-1.0
auth required pam_nologin.so
auth required pam_pwdb.so shadow nullok
account required pam_pwdb.so
session required pam_pwdb.so
Note that Pam ONLY works with pap authentication with the login option
to pppd. It is impossible by definition for pam to work with chap
authentication and also if you just use the pap-secrets database.
I personally would not use pap on a pppoe link, it is totally insecure
to password sniffing on the ethernet link. You might as well just skip
passwords altogether and allow anyone to log on without a password.
I would either use chap (for which pam cannot not work) or Carlson's
new SRP based standard for ppp (for which pam might be made to work, but
certainly does not do so now.)
(Unfortunately the latter is still just in the development stage)
"Bill Unruh" <un...@physics.ubc.ca> wrote in message
news:9a2r8d$8od$1...@nntp.itservices.ubc.ca...
You have the pppd "login" option specified and you compiled with
-DUSE_PAM, right? Pppd doesn't use PAM by default.
--
James Carlson, Internet Engineering <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp
>You have the pppd "login" option specified and you compiled with
>-DUSE_PAM, right? Pppd doesn't use PAM by default.
Actually I think the pppd included in most distrubutions have this
already switched on and so do try to use pam if appropriate (ie with the
login option.)
On the other hand, I still think it is stupid to use pap with a pppoe
situation if you have any choice.
I didn't see that part of the thread.
If the user is on the *client* side of the connection -- that is, he's
the PAP authenticatee -- then it's not possible to use PAM at all.
PAM is for the authenticator (aka "server") only.
the request goes to the Radius server and the user gets authenticated. This
part works.
This is true if the user is configured on the workstation on UNIX side (
useradd fred -p cderfv ) and has entry in pap-secrets on client side; all
the negotiations go through and I can get the session up. But if the user
is configured in Radius server db, not on Unix ( does not have entry in
/etc/passwd /etc/shadow) then the radius server authenticates the user, but
PAM module says that the account is expired. I find it as a PAM design flaw.
"James Carlson" <james.d...@sun.com> wrote in message
news:xoavbsqe...@sun.com...
>After pap-secrets file modification on ppp server to look like
>* * "" *
I assume that you have the "login" option to pppd set, or this will
authenticate everyone and never go to the pam database.
(Actually I never was able to get the * as the username to work. I had
to place each username into the pap-secrets file. Perhaps recent pppd
have fixed this.)
>the request goes to the Radius server and the user gets authenticated. This
>part works.
>This is true if the user is configured on the workstation on UNIX side (
>useradd fred -p cderfv ) and has entry in pap-secrets on client side; all
>the negotiations go through and I can get the session up. But if the user
>is configured in Radius server db, not on Unix ( does not have entry in
>/etc/passwd /etc/shadow) then the radius server authenticates the user, but
>PAM module says that the account is expired. I find it as a PAM design flaw.
Perhaps. I have no idea how PAM interacts with a Radius server.
Again, I would strongly urge you NOT to use pap on a pppoe connection,
but use chap instead. Yes, it does require you to keep up the
chap-secrets database, and yes the passwords in there are in the clear,
but at least someone in Mongolia cannot sniff you passwords as they
travel in the clear down your line.
What PAM modules are you using? Do you have the right modules
specified for auth, account, and session? Pppd should not be going
through any of the Unix password checks if PAM is properly configured
to use a RADIUS module -- look at plogin() in pppd/auth.c.
At a guess, I think you have pam_unix.so specified somewhere.
Otherwise, yes, it's possible that the pam_radius module you're using
has some sort of design flaw. I don't see *why* it would, but it
could.
I don't entirely agree. It depends on the technology underneath the
link between the PPPoE-speaking PC and the pppd implementation that's
serving the call. If this is (say) a single ATM VC per user, then PAP
is just fine. There's no way for users to contact each other or sniff
each other's networks, because you're not bridging between them. This
is no more (or less) secure than a dial-up situation, where PAP is an
appropriate choice.
Of course, if there are multiple users on that Ethernet segment, then
there are the security issues you describe.
"Bill Unruh" <un...@physics.ubc.ca> wrote in message
news:9actmj$5l1$1...@nntp.itservices.ubc.ca...