lsg31.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

<FONT COLOR="#000080"># /etc/ppp/options: globabl definitions



domain merlin.com



auth # force authentication



usehostname # use local hostname for authentication



lock # use file locking UUCP-style</FONT></PRE>



<P>The domain is established with the domain keyname followed by the full domain name (minus the machine name). The next two lines above (auth and usehostname) deal with authentication of the PPP line, preventing unwanted usage and access. We will look at authentication later in this section. The lock keyword tells pppd to use UUCP-style file locking to prevent device clashes. Locking should be used on all PPP systems to prevent problems.



<BR>



<BR>



<A NAME="E69E204"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Checking Problems</B></FONT></CENTER></H4>



<BR>



<P>The pppd daemon echoes all warnings and error messages to the syslog facility. If you used the -v option with the chat script, chat's messages are also sent to syslog. If you are having trouble with your PPP connections, you can check the syslog for details and try to isolate the problem.



<BR>



<P>Syslog discards incoming error and warning messages, unless an entry in the /etc/syslog.conf file redirects them to another file. To save the messages from pppd and chat, add this line to the /etc/syslog.conf file:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">daemon.* /tmp/ppp-log</FONT></PRE>



<P>This entry tells syslog to save any incoming messages from a daemon to the /tmp/ppp-log file. You can use any filename you want instead of /tmp/ppp-log. Many Linux versions of the syslog.conf file insist on tabs to separate the columns instead of spaces. Once your script is working, remember to remove this line or the log file will grow quite large!



<BR>



<P>If you really want to watch what is going on with pppd, you can invoke a debugging option with the kdebug command followed by a number. The three values for debugging are:



<BR>







<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="100%" CELLPADDING=2 >



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



<A NAME="I2"></A>1



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



general debug messages</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



2



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



display incoming HLDC data</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



4



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



display outgoing HLDC data</FONT>



</TABLE><P>The numbers are added together to give the debug level you want. For example, the command kdebug 5 will display all general debug messages and all outgoing HLDC data. A value of 7 displays everything (this display gets very long). You can send the output to a file or the console.



<BR>



<BR>



<A NAME="E69E205"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>PPP Authentication</B></FONT></CENTER></H4>



<BR>



<P>PPP is a wonderful protocol for modem-based communications, but it has one major problem: it has security holes large enough to drive a bus through. If incorrectly configured even slightly, anyone can use the PPP line to get into your machine, or use the PPP line to get out to other systems. To help prevent this, authentication is often used. Authentication essentially makes sure that each end of the connection is who they say they are and are allowed to use the link.



<BR>



<P>PPP uses two authentication schemes: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure. When one machine sends the login name and password to the other, the receiving machine verifies the information with a database on its end. While simple, PAP has the problem that anyone can tap into the line and monitor the passwords being sent.



<BR>



<P>CHAP solves this problem, and hence is the most favored form of authentication for PPP links. CHAP enables one machine to send a random string to the other, along with its hostname. The other end uses the hostname to look up the proper reply, combine it with the first string, encrypt it, and then resend it to the first machine along with its hostname. The first machine performs the same sort of manipulation on the random string it first sent, and if the two replies match, the authentication is complete. CHAP doesn't authenticate only at start time, but at random intervals throughout the connection, which adds to its power.



<BR>



<P>When two machines connect, they don't use authentication unless explicitly instructed to do so (see the auth entry in the /etc/ppp/options file, discussed earlier). When authentication is active, one end will try to use CHAP first, then, if that fails because the other end doesn't support CHAP, it will use PAP. If neither authentication scheme is supported by the other end, the connection is terminated. If you are going to use authentication for all your PPP connections, put the auth entry in the /etc/ppp/options file. If not all your connections support authentication, then those connections will fail if auth is specified.



<BR>



<P>The information needed for both CHAP and PPP are kept in two files called /etc/ppp/chap-secrets and /etc/ppp/ppp-secrets respectively. When authentication is active, one end will check the other for these files, trying CHAP first. If you are going to use authentication for all your connections (which is a very good idea), you can build up the chap-secrets and pap-secrets files. If you configure both chap-secrets and pap-secrets and specify the auth option in /etc/ppp/options, no unauthenticated host can connect to your machine.



<BR>



<P>The /etc/ppp/chap-secrets file consists of four columns for the client name, the server name, the secret password string, and an optional list of IP addresses. The behavior of the system is different depending on whether the local machine is being challenged to authenticate itself or is issuing a challenge to the remote. When the local machine has to authenticate itself, pppd examines the /etc/ppp/chap-secrets file for an entry in the client field that matches the local host name and the server field equal to the remote hostname, and then uses the string to build the authentication message. Such an entry in the /etc/ppp/chap-secrets file looks like this:



<BR>



<PRE>



<FONT COLOR="#000080"># client server string addresses



merlin.tpci.com big_guy.big_net.com &quot;I hate DOS&quot;</FONT></PRE>



<P>This entry will use the string &quot;I hate DOS&quot; to build an authentication message back to big_guy.big_net.com. The quotations are necessary to surround the string in the file. (The addresses column is discussed below.) If you are setting up your system to connect to three different PPP remotes, you will want an entry for each server, so your file may look like this:



<BR>



<PRE>



<FONT COLOR="#000080"># client server string addresses



merlin.tpci.com big_guy.big_net.com &quot;I hate DOS&quot;



merlin.tpci.com chatton.cats.com &quot;Meow, Meow, Meow&quot;



merlin.tpci.com roy.sailing.ca &quot;Hoist the spinnaker&quot;</FONT></PRE>



<P>When your machine is sending the challenge, the process is reversed. The pppd daemon looks for the remote hostname in the client field, the local hostname in the server field, and uses the string to compare the encryption results with the string sent back by the remote. Entries in the /etc/ppp/chap-secrets file for this purpose look like this:



<BR>



<PRE>



<FONT COLOR="#000080"># client server string addresses



big_guy.big_net.com merlin.tpci.com &quot;Size isn't everything&quot;</FONT></PRE>



<P>Again, you will have an entry for each remote machine you may need to authenticate. You can see that you will end up having mirror image entries for the client and server fields for each machine you connect to (as either end may require authentication at any time). A simple /etc/ppp/chap-secrets file really looks like this:



<BR>



<PRE>



<FONT COLOR="#000080"># client server string addresses



merlin.tpci.com big_guy.big_net.com &quot;I hate DOS&quot;



big_guy.big_net.com merlin.tpci.com &quot;Size isn't everything&quot;



merlin.tpci.com chatton.cats.com &quot;Meow, Meow, Meow&quot;



chatton.cats.com merlin.tpci.com &quot;Here, Kitty, Kitty&quot;



merlin.tpci.com roy.sailing.ca &quot;Hoist the spinnaker&quot;



roy.sailing.ca merlin.tpci.com &quot;Man overboard&quot;</FONT></PRE>



<P>The size of the file could get quite large, so CHAP enables you to use a wildcard match, usually only for your local machine. For example, in the /etc/ppp/chap-secrets file below:



<BR>



<PRE>



<FONT COLOR="#000080"># client server string addresses



merlin.tpci.com big_guy.big_net.com &quot;I hate DOS&quot;



big_guy.big_net.com merlin.tpci.com &quot;Size isn't everything&quot;



merlin.tpci.com chatton.cats.com &quot;Meow, Meow, Meow&quot;



chatton.cats.com merlin.tpci.com &quot;Here, Kitty, Kitty&quot;



merlin.tpci.com roy.sailing.ca &quot;Hoist the spinnaker&quot;



* merlin.tpci.com &quot;Man overboard&quot;</FONT></PRE>



<P>the last entry enables any other machine connecting to the localhost and requiring authentication to use the same string. Of course, the remote must have the same string in its chap-secrets file. This is a little less secure than a dedicated string for each remote, but can be a handy time-saver when using a number of machines only rarely.



<BR>



<P>The addresses field, which wasn't used in the samples above, enables you to list either symbolic names or IP addresses for the clients. This is necessary if the remote wants to use an IP address other than its normal one, which would cause the authentication to fail normally. If the address field is empty (as they all are in the samples), any IP address is allowed. A hyphen in the field disallows all IP addresses with that client.



<BR>



<P>The /etc/ppp/pap-secrets file is much the same as the chap-secrets file. The fields in the pap-secrets file are the client (called a user in the pap-secrets format) and server names, a secret string, and valid address aliases. However, the look of the file is different because the client and server names are not full domain names and the secret string is a single block of text. A sample pap-secrets file looks like this:



<BR>



<PRE>



<FONT COLOR="#000080"># /etc/ppp/pap-secrets



# user server string addresses



merlin darkstar yG55Sj29 darkstar.big_net.com



darkstar merlin 5Srg7S merlin.tpci.com



merlin chatton MeowMeow chatton.cats.com



chatton merlin 73wrh6s merlin.tpci.com</FONT></PRE>



<P>In this example, the first two lines show a connection to the machine darkstar. The first line is how we authenticate a request from darkstar, and the second how we authenticate a request from us to them. The user name in the first column is the name we send to the remote, while the server field is their identification to us. This poses a problem: the pppd daemon has no way of knowing the remote host's name, because all it gets is an IP address. You can put the IP address in the addresses column of the file, or you can specify the remote host name at the end of the pppd command line like this:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">pppd ..... remotename chatton user merlin</FONT></PRE>



<P>This shows that the remote is called chatton, and our local host is merlin. The last portion giving the local host name overrides the default values, if specified.



<BR>



<BR>



<A NAME="E68E175"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Using DNS for SLIP and PPP</B></FONT></CENTER></H3>



<BR>



<P>If you are using SLIP or PPP to connect to the Internet for more than simple tasks (such as downloading e-mail and news), you will probably want to use DNS. The basic configuration for DNS and BIND were discussed in <A HREF="lsg30.htm">Chapter 30</A>, &quot;Configuring TCP/IP.&quot;



<BR>



<P>The easiest method of using DNS for your SLIP and PPP connections is to put the IP address of a name server you can access in the /etc/resolv.conf file. For example, if you can access a name server with an IP address of 45.2.12.1, you would make the following addition to your /etc/resolv.conf file:



<BR>



<PRE>



<FONT COLOR="#000080"># /etc/resolv.conf



domain merlin.com # the local domain



nameserver 145.2.12.1 # the Internet name server</FONT></PRE>



<P>Once this entry has been established, SLIP or PPP will send requests for address resolution to the name server and wait for replies. The more accessible the name server is, the better the performance will be. For this reason, choose a name server that is relatively close (in network terms).



<BR>



<P>Using this approach has a problem, though: all address resolution attempts must go out over the SLIP or PPP line. This can slow down applications, as well as increase the amount of network traffic over your SLIP or PPP line, sometimes to the detriment of other applications. A way around this problem is to set up a cache-only name server on your machine. As you may recall from <A HREF="lsg30.htm">Chapter 30</A>, a name server uses a cache to retain the most commonly used addresses. Since most SLIP and PPP connections are to a few machines only, the cache can dramatically reduce the amount of resolution traffic on the SLIP or PPP link.



<BR>



<P>To set up a cache-only name server, you need to modify the /etc/named.boot file. To set your local machine up as a cache-only name server, your named.boot file would look like this:



<BR>



<PRE>



<FONT COLOR="#000080">; /etc/named.boot



directory /var/named



cache db.cache ; cache-only



primary 0.0.147.in-addr-arpa db.cache ; loopback</FONT></PRE>



<P>The file above uses the local network name in IN-ADDR-ARPA format to specify the loopback driver, and the cache points to the file db.cache, which contains a list of root name servers.



<BR>



<BR>



<A NAME="E68E176"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>



<BR>



<P>Once you have performed all the configuration steps and startup instructions mentioned above for SLIP and PPP, you can use the interfaces to the outside world. The applications that make use of SLIP and PPP usually expect only to be told where the interface is, and then to work without any interference from you. SLIP is much easier to configure than PPP, but PPP has faster throughput and more security features that make it attractive if you are using a modem connection a lot.



<P ALIGN=LEFT>



























</td>
</tr>
</table>
<!-- begin footer information -->


</body></html>