On Mon, 02 Oct 2006, in the Usenet newsgroup comp.os.linux.misc, in article
<slrnei1tq2.5df.wyrd@deuce.localdomain>, Harold Stevens wrote:

>From /etc/ppp/options on kubuntu 6.06 ("dapper"):
>
> # Require the peer to authenticate itself before allowing network
> # packets to be sent or received.
> # Please do not disable this setting. It is expected to be standard in
> # future releases of pppd.

If you look at the ppp source files at ftp://ftp.samba.org/pub/ppp you'll
find /etc/ppp/options is not included (an example file like this _was_
included in ppp-2.2.tar.gz, and ppp-2.3.0.tar.gz, but hasn't been included
since then) - that's now generally a distribution supplied file, and in this
case it's only a about seven _years_ out of date. The 'noauth' deal went
into ppp-2.3.6 in early 1999. That's one of the changes that br0ke diald.

>From the same kubuntu pppd manpage:

Actually, that's right out of the stock pppd man page - and that section
hasn't changed since the man page that came with (at least) ppp-2.3.7.

> auth Require the peer to authenticate itself before allowing network
> packets to be sent or received. This option is the default if
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the system has a default route.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's a reasonable assumption. If you _have_ a pre-existing default route
to the world, why are you dialing _out_? That is a security issue that gives
network admins heartburn. If you don't have a pre-existing default route,
this option doesn't matter.

> name name
> Set the name of the local system for authentication purposes to
> name.

Look at the syntax of the /etc/ppp/*ap-secrets file.

Thus each line in a secrets file has at least 3 fields: the name of
the client, the name of the server, and the secret. These fields
may be followed by a list of the IP addresses that the specified
client may use when connecting to the specified server.

> user name
> Sets the name used for authenticating the local system to the
> peer to name.

This is more normal, but is used in the same manner. You would use this if
there are multiple ISPs (I hope you aren't dumb enough to use the same
username/secret across multiple accounts), or where your ISP username is
different from the username on the system you are dialing in FROM.

>This isn't clear to me at all, and I wonder if it's overkill, anyway.

The guys who maintain the ppp code are well aware of security consequences
and are strict in enforcement. A network or security administrator wouldn't
want a user running a ppp link around the company firewall. pppd has two
kinds of options - privileged, and non-privileged. The idea is that only
root can muck with a privileged option, because it has serious security
implications. The non-privileged options would be used where root has set
up pppd, and yet the user needs to make non-critical changes for some things.

>Using the default ("auth"), pppd dies (my ISP sees no need to authenticate).

Yes, that's normal. Don't forget that in addition to being a "Point to Point
Protocol", it's also a "Peer to Peer Protocol" and the concept of client and
server is severely blurred. Both peers could be servers OR clients, so all
of the capabilities are there.

>As a workaround, I tried simply forcing "noauth" in the options file, despite
>kubuntu advice. That's fine for running pppd directly as root, but not when a
>mere user tries to run pppd for vanilla dialup (allowed as root only AFAICT).

Why do you need the option in the first place? This only comes up if you
have a pre-existing default, probably on the eth0 interface. If that _is_
the case (example, you are dialing in to a company site - but have an
existing broadband connection to the world), the _preferred_ solution is
to kill off the existing default route before dialing so that your system
can't be used to bypass the firewall at the company. If that is not an
issue (you have a firewall blocking "new" connections to the ppp0 interface
for example), then the 'noauth' option is acceptable.

>Polite advice on implementing this (and/or correcting my ignorance) welcome.

Aw, come-on Harold - this is Usenet ;-)

Old guy