CONTENTS

SYNOPSIS

DESCRIPTION

The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: a method for encapsulating datagrams over serial links, an extensible Link Control Protocol (LCP), and a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.

OPTIONS

OPTIONS FILES

The normal way that pppd should be set up is to have the auth option in the /etc/ppp/options file. (This may become the default in later releases.) If users wish to use pppd to dial out to a peer which will refuse to authenticate itself (such as an internet service provider), the system administrator should create an options file under /etc/ppp/peers containing the noauth option, the name of the serial port to use, and the connect option (if required), plus any other appropriate options. In this way, pppd can be set up to allow non-privileged users to make unauthenticated connections only to trusted peers.

At present, pppd supports two authentication protocols: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP involves the client sending its name and a cleartext password to the server to authenticate itself. In contrast, the server initiates the CHAP authentication exchange by sending a challenge to the client (the challenge packet includes the server’s name). The client must respond with a response which includes its name plus a hash value derived from the shared secret and the challenge, in order to prove that it knows the secret.

The PPP protocol, being symmetrical, allows both peers to require the other to authenticate itself. In that case, two separate and independent authentication exchanges will occur. The two exchanges could use different authentication protocols, and in principle, different names could be used in the two exchanges.

The default behaviour of pppd is to agree to authenticate if requested, and to not require authentication from the peer. However, pppd will not agree to authenticate itself with a particular protocol if it has no secrets which could be used to do so.

Pppd stores secrets for use in authentication in secrets files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets for CHAP). Both secrets files have the same format. The secrets files can contain secrets for pppd to use in authenticating itself to other systems, as well as secrets for pppd to use when authenticating other systems to itself.

Each line in a secrets file contains one secret. A given secret is specific to a particular combination of client and server - it can only be used by that client to authenticate itself to that server. 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.

A secrets file is parsed into words as for an options file, so the client name, server name and secrets fields must each be one word, with any embedded spaces or other special characters quoted or escaped. Any following words on the same line are taken to be a list of acceptable IP addresses for that client, or an override for "local:remote" addresses (the same format used on the command line or in the options file) when on a line that contains a specific client name (not a wildcard nor empty). If there are only 3 words on the line, or if the first word is "-", then all IP addresses are disallowed. To allow any address, use "*". A word starting with "!" indicates that the specified address is not acceptable. An address may be followed by "/" and a number n, to indicate a whole subnet, i.e. all addresses which have the same value in the most significant n bits. Note that case is significant in the client and server names and in the secret.

If the secret starts with an ‘@’, what follows is assumed to be the name of a file from which to read the secret. A "*" as the client or server name matches any name. When selecting a secret, pppd takes the best match, i.e. the match with the fewest wildcards.

Thus a secrets file contains both secrets for use in authenticating other hosts, plus secrets which we use for authenticating ourselves to others. When pppd is authenticating the peer (checking the peer’s identity), it chooses a secret with the peer’s name in the first field and the name of the local system in the second field. The name of the local system defaults to the hostname, with the domain name appended if the domain option is used. This default can be overridden with the name option, except when the usehostname option is used.

When pppd is choosing a secret to use in authenticating itself to the peer, it first determines what name it is going to use to identify itself to the peer. This name can be specified by the user with the user option. If this option is not used, the name defaults to the name of the local system, determined as described in the previous paragraph. Then pppd looks for a secret with this name in the first field and the peer’s name in the second field. Pppd will know the name of the peer if CHAP authentication is being used, because the peer will have sent it in the challenge packet. However, if PAP is being used, pppd will have to determine the peer’s name from the options specified by the user. The user can specify the peer’s name directly with the remotename option. Otherwise, if the remote IP address was specified by a name (rather than in numeric form), that name will be used as the peer’s name. Failing that, pppd will use the null string as the peer’s name.

When authenticating the peer with PAP, the supplied password is first compared with the secret from the secrets file. If the password doesn’t match the secret, the password is encrypted using crypt() and checked against the secret again. Thus secrets for authenticating the peer can be stored in encrypted form if desired. If the papcrypt option is given, the first (unencrypted) comparison is omitted, for better security.

Furthermore, if the login option was specified, the username and password are also checked against the system password database. Thus, the system administrator can set up the pap-secrets file to allow PPP access only to certain users, and to restrict the set of IP addresses that each user can use. Typically, when using the login option, the secret in /etc/ppp/pap-secrets would be "", which will match any password supplied by the peer. This avoids the need to have the same secret in two places.

Additional checks are performed when the login option is used. If the file /etc/ppp/ppp.deny exists, and the user is listed in it, the authentication fails. If the file /etc/ppp/ppp.shells exists and the user’s normal login shell is not listed, the authentication fails.

Authentication must be satisfactorily completed before IPCP (or any other Network Control Protocol) can be started. If the peer is required to authenticate itself, and fails to do so, pppd will terminated the link (by closing LCP). If IPCP negotiates an unacceptable IP address for the remote host, IPCP will be closed. IP packets can only be sent or received when IPCP is open.

When IPCP negotiation is completed successfully, pppd will inform the kernel of the local and remote IP addresses for the ppp interface. This is sufficient to create a host route to the remote end of the link, which will enable the peers to exchange IP packets. Communication with other machines generally requires further modification to routing tables and/or ARP (Address Resolution Protocol) tables. In most cases the defaultroute and/or proxyarp options are sufficient for this, but in some cases further intervention is required. The /etc/ppp/ip-up script can be used for this.

Sometimes it is desirable to add a default route through the remote host, as in the case of a machine whose only connection to the Internet is through the ppp interface. The defaultroute option causes pppd to create such a default route when IPCP comes up, and delete it when the link is terminated.

In some cases it is desirable to use proxy ARP, for example on a server machine connected to a LAN, in order to allow other hosts to communicate with the remote host. The proxyarp option causes pppd to look for a network interface on the same subnet as the remote host (an interface supporting broadcast and ARP, which is up and not a point-to-point or loopback interface). If found, pppd creates a permanent, published ARP entry with the IP address of the remote host and the hardware address of the network interface found.

The following examples assume that the /etc/ppp/options file contains the auth option (as in the default /etc/ppp/options file in the ppp distribution).

Probably the most common use of pppd is to dial out to an ISP. This can be done with a command such as

Messages are sent to the syslog daemon using facility LOG_DAEMON. (This can be overriden by recompiling pppd with the macro LOG_PPP defined as the desired facility.) In order to see the error and debug messages, you will need to edit your /etc/syslog.conf file to direct the messages to the desired output device or file.

The debug option causes the contents of all control packets sent or received to be logged, that is, all LCP, PAP, CHAP or IPCP packets. This can be useful if the PPP negotiation does not succeed or if authentication fails. If debugging is enabled at compile time, the debug option also causes other debugging messages to be logged.

FILES

SEE ALSO