point-to-point protocol daemon
pppd [options]
By default, an asyncmap of 0 is negotiated; the peer will not escape control characters. If multiple asyncmap options are given, the values are ``ORed'' together. If no asyncmap option is given, no async character map will be negotiated for the receive direction; the peer will then escape all control characters.
ms-dns primary ms-dns secondary
The default is to not allow peer request.
The pppd daemon is used to establish TCP/IP serial connections using the point-to-point protocol (PPP). The protocol consists of three parts:
The encapsulation scheme is provided by driver code in the kernel. The pppd utility provides the basic LCP, authentication support, and an NCP for establishing and configuring the Internet Protocol (IP) called the IP Control Protocol (IPCP).
Options can be taken from files as well as the command line. Before looking at the command line, the pppd utility reads options from these files:
The device is the name of pppd's controlling terminal. For example, if the terminal is /dev/ser2, the options file would be /etc/ppp/options.ser2.
An options file is parsed into a series of words delimited by whitespace. Whitespace can be included in a word by enclosing the word in quotes ("). A backslash (\) quotes the next character. A pound sign (#) starts a comment, which continues until the end of the line.
The pppd utility provides system administrators with sufficient access control such that PPP access to a server machine can be provided to legitimate users without fear of compromising the security of the server or the network it's on. This is provided in part by the /etc/ppp/options file, where the administrator can place options to require authentication whenever pppd is run, and in part by the PAP and CHAP secrets files, where the administrator can restrict the set of IP addresses individuals use.
The default behavior of pppd is to agree to authenticate if requested, and to not require authentication from the peer. But pppd won't agree to authenticate itself with a particular protocol if it has no secrets that could be used to do so.
Authentication is based on secrets, which are selected from secrets files (/etc/ppp/pap-secrets and /etc/ppp/chap-secrets). Both secrets files have the same format, and both can store secrets for several combinations of server (authenticating peer) and client (peer being authenticated). Note that pppd can be both a server and client, and that different protocols can be used in the two directions if desired.
A secrets file is parsed into words as for a options file. A secret is specified by a line containing at least 3 words in the order: client, server, secret. Any following words on the same line are taken to be a list of acceptable IP addresses for that client. If there are only 3 words on the line, it is assumed that any IP address is okay. To disallow all IP addresses, use -. If the secret starts with an @, what follows is assumed to be the name of a file from which to read the secret. An asterisk (*) 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 that we use for authenticating ourselves to others. Which secret to use is chosen based on the names of the host (the ``local name'') and its peer (the ``remote name''). The local name is set as follows:
if we are authenticating ourselves and the user option is given, then use the user option else if the name option is given, then use the argument of the first name option seen else if the local IP address is specified with a hostname, then use that hostname otherwise use the hostname of this machine (with the domain appended, if given)
|
When authenticating ourselves, the user option overrides the name option, so that the local name is set to the user option. |
The remote name is set as follows:
if the remotename option is given, then use the argument of the last remotename option seen else if the remote IP address is specified with a hostname, then use that hostname else the remote name is the null string ""
Secrets are selected from the PAP secrets file as follows:
* For authenticating the peer, look for a secret with client == username specified in the PAP authenticate request, and server == local name. * For authenticating ourselves to the peer, look for a secret with client == local name, server == remote name.
When authenticating the peer with PAP, a secret of "" matches any password supplied by the peer. 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 the login option was specified, the username and password are also checked against the system password database. The system administrator can therefore 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.
Secrets are selected from the CHAP secrets file as follows:
* For authenticating the peer, look for a secret with client == name specified in the CHAP-Response message, and server == local name. * For authenticating ourselves to the peer, look for a secret with client == local name, and server == name specified in the CHAP-Challenge message.
Authentication must be satisfactorily completed before IPCP (or any other Network Control Protocol) can be started. If authentication fails, 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 be sent or received only when IPCP is open.
In some cases you may want to allow some hosts that can't authenticate themselves to connect and use one of a restricted set of IP addresses, even when the local host generally requires authentication. If the peer refuses to authenticate itself when requested, pppd takes that as equivalent to authenticating with PAP using the empty string for the username and password. Thus, by adding a line to the pap-secrets file specifying the empty string for the client and password, it's possible to allow restricted access to hosts that refuse to authenticate themselves.
When IPCP negotiation is completed successfully, pppd will inform the socket manager 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 some cases this will be done automatically through the actions of the routing daemon, but in most cases some further intervention is required.
Sometimes it's 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 (e.g. 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 such a network interface is 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.
Messages are sent to the syslogd daemon using LOG_LOCAL2. To see the error and debug messages, you'll 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 (i.e. LCP, PAP, CHAP or IPCP packets) sent or received to be logged. This can be useful if the PPP negotiation doesn't succeed.
Debugging can also be enabled by sending a SIGUSR1 to the pppd process and disabled by sending a SIGUSR2.
This program or script is executed with the same real and effective user ID as pppd, that is, at least the effective user ID and possibly the real user ID will be root. This allows the script to be used to manipulate routes, run privileged daemons (e.g. sendmail), etc. Be careful that the contents of the /etc/ppp/ip-up and /etc/ppp/ip-down scripts don't compromise your system's security.
The primary-nameserv-IP-address and secondary-nameserv-IP-address parameters are only valid when the require_ns option is specified.
The same security considerations of the /etc/ppp/ip-up script apply, since it's executed with the same effective and real user IDs as pppd.
|
The /etc/ppp/auth-up script isn't executed if the peer didn't authenticate itself. |
The following signals have the specified effect when sent to the pppd process:
RFC 1144, RFC 1321, RFC 1332, RFC 1334, RFC 1549, RFC 1661, RFC 1662
Section on ``Setting up a PPP serial link'' in the Serial Network Configuration chapter in this guide.