Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PPP and PAM

220 views
Skip to first unread message

Arek Nowakowski

unread,
Mar 30, 2001, 12:21:05 PM3/30/01
to
I am working on configuration consisting of ppp talking to the Radius
server using PAM software.
I am using the ppp-2.4.0-pppoe4.tgz package, which has the PAM feature in
the
auth.c file.
I compile the package with USE_PAM feature in the Makefile is enabled.
None of the files in the package explain how to configure and start ppp,
that PAM library would be used for the authentication.
Please, could you send me instructions what to tell PPP to use PAM??
Thanks.
Arek.No...@Innovation.Siemens.ca

Bill Unruh

unread,
Mar 30, 2001, 3:45:01 PM3/30/01
to

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)

Arek Nowakowski

unread,
Apr 2, 2001, 1:19:30 PM4/2/01
to
Thank you very kindly for the response.
I did the recommended changes to the /etc/pam.d/ppp file but the PAM
functionality is still not used.
There is no request going to the radius server from PAM. It simply uses the
pap authentication. It does not go any further.
There are also two files /etc/ppp/options and /etc/ppp/pap-secrets.
They must be used during the authentication also, but...
The question I have is how the ppp uses pap for pam authentication? Should
it jump to the pam module after doing the pap authentication?
Arek Nowakowski.

"Bill Unruh" <un...@physics.ubc.ca> wrote in message
news:9a2r8d$8od$1...@nntp.itservices.ubc.ca...

James Carlson

unread,
Apr 2, 2001, 2:17:16 PM4/2/01
to
"Arek Nowakowski" <Arek.No...@Innovation.Siemens.ca> writes:
> Thank you very kindly for the response.
> I did the recommended changes to the /etc/pam.d/ppp file but the PAM
> functionality is still not used.
> There is no request going to the radius server from PAM. It simply uses the
> pap authentication. It does not go any further.
> There are also two files /etc/ppp/options and /etc/ppp/pap-secrets.
> They must be used during the authentication also, but...
> The question I have is how the ppp uses pap for pam authentication? Should
> it jump to the pam module after doing the pap authentication?

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

Bill Unruh

unread,
Apr 2, 2001, 8:21:03 PM4/2/01
to
In <xoav1yrb...@sun.com> James Carlson <james.d...@sun.com> writes:

>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.

James Carlson

unread,
Apr 3, 2001, 7:21:05 AM4/3/01
to
un...@physics.ubc.ca (Bill Unruh) writes:
> 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.

Arek Nowakowski

unread,
Apr 3, 2001, 12:10:43 PM4/3/01
to
After pap-secrets file modification on ppp server to look like
* * "" *

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...

Bill Unruh

unread,
Apr 3, 2001, 12:28:03 PM4/3/01
to
In <9ad0bh$8cc$1...@papyrus.erlm.siemens.de> "Arek Nowakowski" <Arek.No...@Innovation.Siemens.ca> writes:

>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.


James Carlson

unread,
Apr 3, 2001, 12:33:08 PM4/3/01
to
"Arek Nowakowski" <Arek.No...@Innovation.Siemens.ca> writes:
> 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.

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.

James Carlson

unread,
Apr 3, 2001, 12:43:59 PM4/3/01
to
un...@physics.ubc.ca (Bill Unruh) writes:
> 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.

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.

Arek Nowakowski

unread,
Apr 3, 2001, 1:49:36 PM4/3/01
to
I have the login entry specified.
My set-up is experimental, used in the lab only. Evesdropping is not a
concern.

"Bill Unruh" <un...@physics.ubc.ca> wrote in message

news:9actmj$5l1$1...@nntp.itservices.ubc.ca...

0 new messages