Mike Blatchley <[EMAIL PROTECTED]> wrote:
> Also, I'm aware that mgetty will do
> "Auto PPP", but all authentication is solely via PAP. There's something
> about requiring the normal Login/Password procedure that makes me feel
> better.
I'm not sure >why< it makes you feel better. I prefer CHAP myself, so that
people snooping the line can't get the password. Not that it's easy to
snoop on V.34 and V.90 connections, but I just tend to be paranoid. Anyhow,
even using PAP doesn't seem to me to be inherently any less secure than the
normal getty/login procedure.
In the olden days (before Linux), some systems had an (undocumented?)
feature where getty would allow additional arguments after the user name,
which would be put into an environment variable and could be used by the
user's login script to do things like perhaps start PPP (although these were
the days before PPP). AFAIK, none of the various getty programs for Linux
have this feature.
Anyhow, if you do decide to use AutoPPP, I'd offer one piece of advice. The
PPP Howto is completely wrong about how to set up the pap-secrets and
chap-secrets files. They have to be the same on both systems, not swapped.
For instance, on my machines, they look like:
# client server secret IP addresses
# ------ ------ ------ ------------
rock hardplace pass*word
hardplace rock you/wish
This same file (*) is used on both machines. If you swap the secrets the way
the PPP Howto suggests, authentication will fail. Why? Because the "client"
and "server" roles as used in the secrets file are relative to the
authentication, not to the ultimate usage of the machine. In this example,
the machine 'rock' authenticates to the machine 'hardplace' using the secret
'pass*word'. Both machines must agree on this. If you swap the secrets,
'rock' will try to use 'pass*word', but 'hardplace' will expect 'you/wish', so
the authentication will fail.
Similarly, 'hardplace' uses the secret 'you/wish' to authenticate itself
to 'rock'. Again, both machines must agree on this.
Note that in many cases it is deemed sufficient for the macine dialing in
to authenticate itself, and the ansering machine is not required to
authenticate to the caller. Typically you can assume that if you call a
known telephone number, you will get the machine you expect, rather than
an imposter. To use PPP in that manner, if 'rock' is dialing into
'hardplace', both machines only need the first line of the example. But
that line still must be the same on both.
IMNSHO, there is no particularly good reason not to authenticate in both
directions, unless you're using a non-Linux PPP client that is too stupid
too allow it, or too cumbersome for users to configure.
Cheers,
Eric
(*) There are actually two difference in my chap-secrets files between the
endpoints. One of my machines accepts calls from many others, so naturally
it has a pair of lines for each machine it talks to, whereas my end-nodes
each only have a single pair.
Secondly, my central machine (hardplace) has to assign an IP address to
the caller (rock) when it connects, so there is an IP address on the first
line. This doesn't need to be present in rock's chap-secrets file, although
I don't think it would cause a problem if it was.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
