Authentication HOWTO

[Peter Hernberg <petehern@yahoo.com>]

When I was trying to sent up a bunch of totally
extraneous services on my home network, I kept running
into the issue/problem of authentication. So I
figured: why not figure out the ins and outs of linux
authentication, write a HOWTO, and call it my (high
school) senior project? The sgml doc at the bottom of
this email is the first draft of the first section of
what I hope will become the Authentication HOWTO. I'd
greatly appreciate feedback.

Having recently joined this list, I've been reading
the thread about sgml tools, so I'll throw in my two
cents. As someone who's never befored touched sgml or
Docbook, the whole process seemed rather trivial. I
downloaded the sgml version of a HOWTO, fired up gvim,
yanked the text of the HOWTO (leaving the tags), and
started writing. All the tags seemed rather intuitive.
Being a geek and having worked with html certainly
helped, but it really was pretty simple. IMHO, anyone
technically competent enough to be writing an LDP doc
shouldn't have much trouble figuring out the basics
sgml.

Here's the HOWTO (send feedback please!):
<!doctype article public "-//OASIS//DTD DocBook
V3.1//EN"
 [ <!entity header system "header.sgml">
]>

<article>
 <artheader>
  <title>
  Authentication HOWTO
 </title>
 <pubdate>
  2000/05/02
 </pubdate>
 <author>
 
<firstname>Peter</firstname><surname>Hernberg</surname>
 </author>
 <abstract>
 <para>
  Explains how user and group information is stored
and how authentication works on a Linux system or
network.
 </para>
 </abstract>
 </artheader>
 <sect1>
  <title>
  Introduction
 </title>
  <sect2>
   <title>
   How this document came to be
  </title>
  <para>
   When trying to add a number of (mostly
unnessecary:) network services to my existing home
network, I kept running into the problem of
authentication, so I decided to figure out linux
authentication, write a HOWTO, and call it my senior
project. I hope this helps you understand this
often-forgotten, but very important, aspect of system
administration.
  </para>
  </sect2>
  <sect2>
   <title>
   New versions
  </title>
  <para>
   When I get my domain up running properly, you'll be
able to find the newest version of this document
there.
  </para>
  </sect2>
  <sect2>
   <title>
   Feedback
  </title>
  <para>
   Comments, corrections, suggestions, flames, and
flying saucer sightings can be sent to
petehern@rochester.rr.com.
  </para>
  </sect2>
  <sect2>
   <title>
   Version History
  </title>
  <para>
   v0.1 (May 2, 2000) First version (not released).
  </para>
  </sect2>
  <sect2>
   <title>
   Copyrights and Trademarks
  </title>
  <para>
   (c) 2000 Peter Hernberg
  </para>
  <para>
   This manual may be reproduced in whole or in part,
without fee, subject to the following restrictions:
  </para>
  <itemizedlist>
   <listitem>
   <para>
   The copyright notice above and this permission
notice must be preserved complete on all complete or
partial copies
   </para>
  </listitem>
   <listitem>
   <para>
   Any translation or derived work must be approved by
the author in writing before distribution.
   </para>
  </listitem>
   <listitem>
   <para>
   If you distribute this work in part, instructions
for obtaining the complete version of this manual must
be included, and a means for obtaining a complete
version provided.
   </para>
  </listitem>
   <listitem>
   <para>
   Small portions may be reproduced as illustrations
for reviews or quotes in other works without this
permission notice if proper citation is given.
Exceptions to these rules may be granted for academic
purposes: Write to the author and ask. These
restrictions are here to protect us as authors, not to
restrict you as learners and educators. Any source
code (aside from the SGML this document was written
in) in this document is placed under the GNU General
Public License, available via anonymous FTP from the
GNU archive.
   </para>
  </listitem>
  </itemizedlist>
  </sect2>
  <sect2>
   <title>
   Acknowledgements and Thanks
  </title>
  <para>
   Thanks to my family for putting up with me for 18
years. Thanks to the debian folks for making such a
sweet distro for me to play with. Thanks to <ulink
url="http://www.cgr.org/";>CGR</ulink> for paying me to
be a geek. Finally, I'd thank the makers of ramen
noodles, because I don't know how I'd live without
them.
  </para>
  </sect2>
 </sect1>
 <sect1>
  <title>
  How User Information is Stored on Your System
 </title>
  <sect2>
   <title>
   /etc/passwd
  </title>
  <para>
   On almost all linux distrubtions (and commercial
*nixes as well), user information is stored in
/etc/passwd, a text file which contains the user's
login, their encrypted password, a unique numerical
user id (called the uid), a numerical group id (called
the gid), an optional comment field (usually
containing things like their real name, phone number,
etc.), their home directory, and their prefered shell.
A typical entry in /etc/passwd might look something
like this:
  </para>
  <programlisting>
  pete:K3xcO1Qnx8LFN:1000:1000:Peter
Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
  </programlisting>
  <para>
   As you can see, it's pretty straight-forward. Each
entry contains the six field I described above, with
the fields delimited by a colon. If this were as
complex as authentication got, there would be no need
for this HOWTO.
  </para>
  </sect2>
  <sect2>
   <title>
   Shadow passwords
  </title>
  <para>
   Looking at your /etc/passwd, it's likely that you
actually saw something likethis:
  </para>
  <programlisting>
  pete:x:1000:1000:Peter
Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
  </programlisting>
  <para>
   Where did the encrypted password go? Before I tell
you where it went, a bit explanation is required.
  </para>
  <para>
   The /etc/passwd file, which contains each user's
encrypted password, is readable by all users, making
it possible for any user to get the encrypted password
of everyone on the system. Though the passwords are
encrypted, password cracking programs are widely
available. To keep evil crackers at bay, shadow
passwords were developed.
   </para>
   <para>
    When a system has shadow passwords enabled, the
password field in /etc/passwd is replaced by an "x"
and the user's real encrypted password is stored in
/etc/shadow. Because /etc/shadow is only readable by
the root user, malicious users cannot crack their
fellow users' passwords. Each entry in /etc/shadow
contains the user's login, their encrypted password,
and a number of fields relating to password
expiration. A typical entry looks like this:
   </para>
   <programlisting>
    pete:/3GJllg1o4152:11009:0:99999:7:::
   </programlisting>
  </sect2>
  <sect2>
   <title>
   /etc/group and /etc/gshadow
  </title>
  <para>
   Group information is stored in /etc/group. The
format is similar to that of /etc/passwd, with the
entries containing fields for the group name,
password, numerical id (gid), and a comma-seperated
list of group members. An entry in /etc/group looks
like this:
  </para>
  <programlisting>
   pasta:x:103:spagetti,fettucini,linguine,vermicelli
  </programlisting>
  <para>
   As you can see from the "x" in the password field,
group passwords can be shadowed as well. While groups
almost never have their own passwords, it is worth
noting that shadow group password information is
stored in /etc/gshadow.
  </para>
  </sect2>
  <sect2>
   <title>
   MD5 encrypted passwords
  </title>
  <para>
   Traditionally, unix passwords were encrypted with
the standard crypt() function. (For more information
on the crypt() function, see the crypt(3) manpage.) As
computers grew faster, passwords encrypted with this
function became easier to crack. As the internet
emerged, tools for distributed the task of cracking
accross multiple hosts became available. Many newer
distributions ship with the option of encrypting
passwords with the MD5 hash algorithm. (For more
information on the MD5 algorithm, consult RFC 1321.)
While MD5 passwords will not eliminate the threat of
password cracking, they will make cracking your
passwords much more difficult.
  </para>
  </sect2>
  <sect2>
   <title>
    Sifting through the mess
  </title>
  <para>
   As you can see, there are a number of different
ways user authentication information can be stored on
your system (shadow passwords without MD5 encryption,
/etc/passwd passwords with MD5 encryption, etc.). How
do programs like login and su know how to verify your
password? Or worse, what if you want to change the way
passwords are stoed on your system? How will programs
that need your password know that passwords are stored
differently? PAM is the answer.
  </para>
  </sect2>
 </sect1>
 <sect1>
  <title>
  PAM (Pluggable Authentication Modules)
 </title>
 <para>
  Pluggable authentication modules are at the core of
authentication in any modern linux distribution.
 </para>
  <sect2>
   <title>
   Coming soon to an sgml file near you!
  </title>
  <para>
   Be amazed as we explored the intricate depths of
pam_unix_auth.so!
  </para>
  </sect2>
 </sect1>


</article>



__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org