Linux

I've been using Linux/Unix for many years. I've always had a strong interest in technology in general and computing specifically.

These are my opinions. Opinions are like noses, everyone has one, and they all smell.

Enjoy your visit.
April 2017
M T W T F S S
« Dec    
 12
3456789
10111213141516
17181920212223
24252627282930

authentication

Linux Authentication Systems


In this document I will discuss the various user authentication systems, and how they relate to system security.


How User Information is Stored on Your System

/etc/passwd


On almost all linux distributions (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 such items as their real name, phone
number, etc.), their home directory, and their preferred shell. A
typical entry in /etc/passwd looks something like this:

bozo:x:1000:1000:Bozo the Clown:/home/bozo:/bin/
bash

What follows is a discussion of various authentication and authorization
methods. This isn’t as simple as simply choosing one. Several can
interact with each other, for example:

  • SASL can use pam to determine what authorizations are allowed for
    a given user
  • LDAP can use SASL as the authentication mechanism
  • SASL can use kerberos tokens for authentication and authorization
  • passwords for SASL can be looked up from an LDAP server
  • PAM can use ldap for storing usernames and passord authentication
    information

And different authentication schemes can be used for different applications
on the same machine. You could, for example, store username and passwords
for ftp in LDAP, authenticate IMAP clients using SASL from username
password pairs stored in sasldb, and authenticate ssh clients from
the standard /etc/passwd and /etc/shadow files and/or stored public keys. While this presents some complexity, like many
things in Linux it also provides flexibility.


PAM Pluggable Authentication Modules

Traditionally user authentication is programmed directly into
applications. With this method each developer has to write his own
authentication
functions. Using PAM (Pluggable Authentication Modules), applications
can be developed with a PAM interface, and the system administrator
can choose any number of PAM modules to do authentication and other
tasks. This seperates user authentication from the application, and
allows “plugging in” of different authentication methods, without the
need to rewrite the application.

PAM is built into many Linux distributions, including Caldera
1.3, 2.2 and later; Debian 2.2 and later; Turbo Linux 3.6 and later;
Red
Hat 5.0 and later; and SuSE 6.2 (partial support). FreeBSD supports PAM
from version 3.1.

PAM (Pluggable Authentication Modules) is a suite of shared
libraries that enable the local system administrator to choose how
applications
authenticate users.

The function of the configuration file(s) is to provide a
mapping from the application’s service name to a selection of modules
that provide authentication services to the raw application. When a pam
aware application with a file in /etc/pam.d
starts, the PAM library loads the configuration for the specified
service and constructs four module chains (one for each facility.) If
the configuration does not
specify any modules for one or more facilities, the configuration for
the other service is used instead for these facilities.

Linux as a server, can provide several different services (e.g., web,
ftp with areas restricted by password control). Through the use of
modules, PAM can enable a program to search through several different
password databases, even if that program is not explicitly coded for
that particular database.

Here are some examples of the possibilities that this enables.

  • Apache has a module that provides PAM services. Now authentication
    to use particular directories can be conducted by PAM, which means
    that the range of modules that are available to PAM can be used,
    including RADIUS, NIS, NCP (which means that Novell password databases
    can be used).
  • pppd has a PAMified version (available from RedHat) Now it is
    possible to use a series of databases to authenticate ppp users. In
    addition
    to the normal Linux-based password databases (such as /etc/passwd and /etc/shadow), you can use PAM modules to authenticate against Novell password databases or NT-based password databases.
  • The preceding two examples can be combined. Imagaine that the
    persons in your office or department are already registered with a
    username and password in a Novell or NT LAN. If you wanted to use this
    database on your Linux server (for PPP access, for web access, or even
    for normal shell access), you can use PAM to authenticate against this
    existing database, rather than maintain a separate database on both
    Linux and the LAN server.

PAM configuration files, located in /etc/pam.d
and named for the service which they control have three fields, with
optional fourth and greater fields. The first field in the
configuration file is the module-type indicatiing which of four PAM
management services the correspoding
module will provide to the application. PAM deals with four separate
types of management services. The type token tells PAM what type of
authentication is to be used for this module. Modules of the same type
can be “stacked”, requiring a user to meet multiple requirements to be
authenticated. The four types of management
services are: authentication management; account management; session
management; and password management.

auth

Determines whether the user is who they claim to be, usually by a
password, but perhaps by a more sophistcated means, such as biometrics.

account

Determines whether the user is allowed to access the service. This is
different from establishing whether the user is who they say
they are. Account management deals with enforcing the expiration of
passwords and preventing logins during system time.

password

Provides a mechanism for the user to change their authentication. Again, this usually their password.

session

Things that should be done before and/or after the user is authenticed. This might included things such as mounting/unmounting
the user home directory, logging their login/logout, and restricting/unrestricting
the services available to the user.

Control:

PAM modules can be stacked – there can be any number of modules of the
same module type for a single application. The application is not told
of the individual success or failure of any module, only of the success
or failure of the stack. The control flags determine how each module
affects the success or failure of the stack. Modules in the stack are
executed in the order they are listed in the configuration
file.

The second field in the configuration file is the control
token, which tells PAM what should be done in if authentication by this
module fails. PAM recognizes four control types: required, requisite,
sufficient, and optional.

requisite
The module must succeed for the stack of this module type to succeed.
Failure to authenticate via this module results in immediate denial of
authentication.
required
The module must succeed for the stack of this module type to
succeed. Failure also results in denial of authentication, although PAM
will still call all the other modules listed for this service before
denying authentication.
sufficient
Success of this module is sufficient for the stack of this module
type to succeed. If authentication by this module is successful, PAM
will grant authentication.
optional
Not critical to the success or failure of the stack. If at least one
non-optional module succeeds or fails, the result of this module is
ignored when calculating the success or failure of the stack. Whether
this module succeeds or fails is only significant
if it is the only module of its type for this service.
Module Path:

The module-path tells PAM which module to use and (optionally) where
to find it. Most configurations only contain the module’s name. Since
Linux-PAM-0.56 was released there is support for a default
authentication-module
directory, and a full path is no longer required, only the name of the
module. PAM looks for the modules in the default PAM module directory,
normally /usr/lib/security. However, if your linux distribution conforms
to the Linux Filesystem standard, PAM modules can be found in /lib/security.

Module Arguments:

Any further fields contain any arguments to the module. Each module has
its own arguments. For example, in our login configuration, the “nulok”
(“null ok”, argument being passed to pam_unix.so module, indicating the a blank (“null”) password is acceptable (“ok”).

The following are a list of module options that are likely to be recognize by all modules:

  • debug Use the syslog(3) call to log debugging information to the system log files.
  • no_warn
  • Instruct module to not give warning messages to the application.
  • use_first_pass
    The module should not prompt the user for a password. Instead, it
    should obtain the previously typed password (from the preceding auth
    module), and use that. If that doesn’t work, then the user will not be
    authenticated. (This option is intended for auth and password modules
    only).
  • try_first_pass
    The module should attempt authentication with the previously typed
    password (from the preceding auth module). If that doesn’t work, then
    the user is prompted for a password. (This option is intended for auth
    modules only).
  • use_mapped_pass
    This argument is not currently supported by any of the modules in the
    Linux-PAM distribution because of possible consequences associated
    with U.S. encryption exporting restrictions. Within the U.S., module
    developers are, of course, free to implement it (as are developers
    in other countries). For compatibility reasons we describe its use as
    suggested in the DCE-RFC 86.0, see section bibliography for a pointer
    to this document. The use_mapped_pass argument instructs the module to take the clear
    text authentication token entered by a previous module (that requests
    such a token) and use it to generate an encryption/decryption key with
    which to safely store/retrieve the authentication token required
    for this module. In this way the user can enter a single authentication
    token and be quietly authenticated by a number of stacked modules.
    Obviously a convenient feature that necessarily requires some reliably
    strong encryption to make it secure. This argument is intended for the
    auth and password module types only.
  • expose_account
    In general the leakage of some information about user accounts is not a
    secure policy for modules to adopt. Sometimes information such as users
    names or home directories, or preferred shell, can be used to attack a
    user’s account. In some circumstances, however, this sort of
    information is not deemed a threat: displaying a user’s full name when
    asking them for a password in a secured environment could also be
    called being friendly.
    The expose_account argument is a standard module argument to encourage
    a module to be less discrete about account information as it is deemed
    appropriate by the local administrator.


Example configuration file entries

Let’s look at some examples of pam configuration files. The first example is for the other or default service. If there is not a specific pam configuration file in /etc/pam.d
for a service, this
is the configuration file that can be used to ease the integration of
new services by providing a default selection of modules appropriate to
the local security policy. Or, it can be used to deny access to any
application that does not have a specific /etc/pam.d
entry. The
fields in the configuration file are module-type, control-flag and
module-filename. Any other fields are optional arguments that are
specific to the individual modules.


Default policy

If a system is to be considered secure, it had better have a reasonably secure other entry. The following is a paranoid setting (which
is not a bad place to start!):

#
# default configuration: /etc/pam.d/other
#
auth required pam_deny.so
account required pam_deny.so
password required pam_deny.so
session required pam_deny.so

While fundamentally a secure default, this won’t give the administrator
any feedback about a misconfigured system. For example, such a system
is vulnerable to locking everyone out should the configuration file for
a specific service be badly written.

The module pam_deny is not very sophisticated, it
logs no information when it is invoked. Unless the users of a system
contact the administrator when failing to execute a service
application, the administrator may go for a long not knowing that his
system is mis-configured.

By changing the configuration to the example below would
provide a suitable warning to the administrator. Notice the the
stacking of
pam_warn.so and pam_deny.so.

#
# default configuration: /etc/pam.d/other
#
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so 

password required pam_warn.so
session required pam_deny.so
session required pam_warn.so

With this configuration, whenever an unknown service attempts to
access any of the four configuration types, PAM denies authentication
(via the pam_deny.so module) and then logs a syslog warning (via the pam_warn.so
module). Short of a bug in PAM, this configuration is brutally secure.
The only problem with that brutality is it may cause problems if your
accidentally delete the configuration of another service. If your
/etc/pam.d/login was mistakenly deleted, no one would be able to login!

Here’s a little gentler configuration

#
# default configuration: /etc/pam.d/other
#
auth requisite pam_securetty.so
auth required pam_unix.so
auth required pam_warn.so
account required pam_unix.so
account required pam_warn.so
password required pam_unix.so
password required pam_warn.so
session required pam_unix.so
session required pam_warn.so.

The first module (pam_securetty.so) checks to see if the
user is root and prevents root from logging in from an insecure
terminal. The value requisite for control-flag is used to force
immediate authentication failure if the securetty module fails. If this
occurs, no more of the auth modules are executed. This has the benefit
of preventing root from mistakenly typing a password over an insecure
terminal line. This configuration will allow an unknown service to
authenticate (via the pam_unix.so module), although it will
not allow it to change
the user’s password. Although it allows authentication by unknown
services, it logs a syslog warning whenever such a service attempts
authentication.


A word on null passwords

On many linux systems there are a number of accounts used to assign
privileges to system services like ftp, apache, news, and databases.
These accounts allow services to run as unprivileged users, providing a
level of security, because an intruder that compromises the service
only has the limited privileges available to that service, rather than
the privileges of root. However, allowing these accounts login
privileges is a security risk, as they usually have blank (null)
passwords.
The nullok options-argument allows passwordless accounts. It is recommended you remove this argument from any modules of auth
type for services that allow login. This is usually the login service,
may also include services like rlogin and ssh. So the following line in
/etc/pam.d/login:

auth required pam_unix.so nullok

Should be changed to:

auth required pam_unix.so


Disable unused services

If you find you have pam configuration files in /etc/pam.d/
that you’re not using, you may want to rename or remove them to prevent
their unauthorized use. For example, if you’re not using graphical
login (Red Hat runlevel 5) then you might want to rename /etc/pam.d/xdm
to /etc/pam.d/noxdm. Not finding the file named after the service requesting authentication, PAM will fall back to the /etc/pam.d/other. If you later want to enable the service, rename to it’s original name and everything w
ill work as it was intended.


Basic PAM modules


pam_unix.so

This module provides traditional Unix authentication, password
management, and user account setup. It uses standard system calls to
retrieve and set password and account information, and relies on /etc/shadow
and /etc/passwd.

  • account Establishes the validity of the user’s account and password and may
    offer advice on changing the user’s password, or force a password
    change. The actions this module performs are controlled by the /etc/passwd and /etc/shadow files.Arguments: audit, debug.
  • auth This component of the module checks the user’s password against the
    password databases. Configuration for this component is done in /etc/nsswitch.conf.
    An additional binary, unix_chkpwd, is used to allow the component to read protected databases without requiring the whole module to be setuid root.Arguments: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.
  • password This component changes the user’s password. The module pam_cracklib.so
    can be stacked with this component to check password security.Arguments: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok,
    remember, try_first_pass, use_authtok, and use_first_pass.
  • sessionThis component logs the user name and session
    type to syslog, at the start and end of the user’s session. There are
    no arguments to this
    component.
  • arguments
    • audit
      A more extensive form of debug
    • bigcrypt
      Use the DEC “C2″ extension to crypt().
    • debug – Log information using syslog
    • md5 – Use md5 encryption instead of crypt().
    • nis – Use NIS (Network Information Service) passwords.
    • nodelay – By default, the module requests a delay-on-failure of a
      second. This argument overrides the default.
    • not_set_pass – Don’t use the passwords from other stacked modules.
      Don’t give the new password to other stacked modules.
    • nullok – By default, if the official password is blank, the authentication
      fails. This argument overrides the default.
    • remember (remember=n) – Save n recent passwords to prevent the user
      from alternating passwords.
    • try_first_pass – Use the password from the previous stacked auth
      module, and prompt for a new password if the retrieved password is
      blank or incorrect.
    • use_authtok – Set the new password to the one provided by a previous
      module.
    • use_first_pass – Use the result from the previous stacked auth
      module, never prompts the user for a password, fails if the result
      was a fail.
pam_access.so

This module intercepts the user’s name and password. If the name is
ftp or anonymous, the user’s password is broken up at the
@ delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items
being set accordingly. The username is set to ftp. In this case
the module succeeds. Alternatively, the module sets the PAM_AUTHTOK
item with the entered password and fails.

The behavior of the module can be modified with the following flags:

  • debug – log more information to with syslog(3).
  • users=XXX,YYY,… – instead of ftp or anonymous, provide anonymous
    login to the comma separated list of users; XXX,YYY,…. Should
    the applicant enter one of these usernames the returned username is
    set to the first in the list; “XXX”.
  • ignore – pay no attention to the email address of the user (if supplied).
pam_chroot.so

This module is intended to provide a transparent wrapper around
the average user, one that puts them in a fake file-system (eg, their
/ is really /some/where/else).

Useful if you have several classes of users, and are slightly
paranoid about security. Can be used to limit who else users can see on
the system, and to limit the selection of programs they can run.

pam_console.so

This module implements a console permission scheme similar to Solaris’
logindevperms. Allows for the permissioning of certain devices and
files at login and logout time.

pam_cracklib.so

This module can be plugged into the password stack of a given
application to provide some plug-in strength-checking for passwords.

This module works in the following manner:
it first calls the Cracklib routine to check the strength of the password; if crack likes the
password, the module does an additional set of strength checks. These checks are:

  • Palindrome – Is the new password a palindrome of the old one?
  • Case Change Only – Is the new password the the old one with only a
    change of case?
  • Similar – Is the new password too much like the old one?
    This is primarily
    controlled by one argument, difok which is a number of characters that
    if different between the old and new are enough to accept the
    new password, this defaults to 10 or 1/2 the size of the new password
    whichever is smaller. To avoid the lockup associated with trying to
    change a long and complicated password, difignore is available. This
    argument can be used to specify the minimum length a new password
    needs to be before the difok value is ignored. The default value for
    difignore is 23.
  • Simple – Is the new password too small? This is controlled
    by 5 arguments
    minlen, dcredit, ucredit, lcredit, and ocredit. See the section on the
    arguments for the details of how these work and there defaults.
  • Rotated – Is the new password a rotated version of the old password?
  • Already used – Was the password used in the past? Previously used passwords are to be found in /etc/security/opasswd.

This module with no arguments will work well for standard unix password
encryption. With md5 encryption, passwords can be longer than 8
characters and the default settings for this module can make it hard
for the user to choose a satisfactory new password. Notably, the
requirement that the new password contain no more than 1/2 of the
characters in the old password becomes a non-trivial constraint. For
example, an
old password of the form the quick brown fox jumped over the lazy dogs
would be difficult to change… In addition, the default action is to
allow passwords as small as 5 characters in length. For a md5 systems
it can be a good idea to increase the required minimum size of a
password. One can then allow more credit
for different kinds of characters but accept that the new password may
share most of these characters with the old password.

pam_deny.so
This module can be used to deny access. It always indicates a failure
to the application through the PAM framework. As is commented in the
overview section above, this module might be suitable for using for
default (the OTHER) entries.
pam_env.so

This module allows you to (un)set arbitrary environment variables using
fixed strings, the value of previously set environment variables
and/or PAM_ITEMs.

All is controlled via a configuration file (by default, /etc/security/pam_env.conf
but can be overriden with conffile argument). Each line starts with the
variable name, there are then two possible options for each variable
DEFAULT and OVERRIDE. DEFAULT
allows an administrator to set the value of the variable to some
default value, if none is supplied then the empty string is assumed.
The OVERRIDE option tells pam_env.so that it should enter in its value (overriding the default value) if there is one to use. OVERRIDE is not used, “” is assumed and no override will be done.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values
using the ${string} syntax and (possibly non-existent) PAM_ITEMs may be
used in values using the @{string} syntax. Both the $ and
@ characters can be backslash-escaped to be used as literal
values (as in \$. Double quotes may be used in values (but not
environment variable names) when white space is needed the full value
must be delimited by the quotes and embedded or escaped quotes are not
supported.

This module can also parse a file with simple KEY=VAL pairs on separate lines (/etc/environment
by default). You can change the default file to parse, with the envfile
flag and turn it on or off by setting the readenv flag to 1 or 0
respectively.

The behavior of this module can be modified with one of the following flags:

  • debug
    write more information to syslog(3).
  • conffile=filename
    by default the file /etc/security/pam_env.conf
    is used as the configuration file. This option overrides the default. You must supply a complete path + file name.
  • envfile=filename
    by default the file /etc/environment
    is used to load KEY=VAL pairs directly into the env. This option
    overrides the default. You must supply a complete path + file name.
  • readenv=0|1
    turns on or off the reading of the file specified by envfile (0 is off, 1 is on). By default this option is on.
pam_filter.so

Each component of the module has the potential to invoke the desired
filter. The filter is always execv(2)d with the privilege of the
calling
application and not that of the user. For this reason it cannot usually
be killed by the user without closing their session.

The behavior of the module can be significantly altered by the arguments passed to it in the Linux-PAM configuration file:

  • debug – this option increases the amount of information logged to syslog(3) as the module is executed.
  • new_term – the default action of the filter is to set the PAM_TTY item to indicate the terminal that the user is using to connect to
    the application. This argument indicates that the filter should set PAM_TTY to the filtered pseudo-terminal.
  • non_term – don’t try to set the PAM_TTY item.
  • runX – in order that the module can invoke a filter it
    should know when to invoke it. This argument is required to tell the
    filter when
    to do this. The arguments that follow this one are respectively the
    full pathname of the filter to be run and any command line arguments
    that the filter might expect.Permitted values for X are 1 and 2. These indicate the precise time
    that the filter is to be run. To understand this concept it will be
    useful to have read the Linux-PAM Module developer’s guide. Basically,
    for each management group there are up to two ways of calling the
    module’s functions.

In the case of the authentication and session components there are
actually two separate functions. For the case of authentication, these
functions are _authenticate and _setcred – here run1 means run the
filter from the _authenticate function and run2 means run the filter
from _setcred. In the case of the session modules, run1 implies that
the filter is invoked at the _open_session stage, and run2 for
_close_session.

For the case of the account component. Either run1 or run2 may be used.

For the case of the password component, run1 is used to indicate that
the filter is run on the first occasion _chauthtok is run (the
PAM_PRELIM_CHECK phase) and run2 is used to indicate that the filter is
run on the second occasion (the PAM_UPDATE_AUTHTOK phase).

pam_ftp.so

This module intercepts the user’s name and password. If the name is ftp or anonymous, the user’s password is broken up at the @ delimiter into a PAM_RUSER and a PAM_RHOST part; these p
am-items being set accordingly. The username (PAM_USER) is set to ftp.
In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

  • debug – log more information to with syslog(3).
  • users=XXX,YYY,… – instead of ftp or anonymous, provide anonymous
    login to the comma separated list of users; XXX,YYY,…. Should the applicant enter one of these usernames the returned username is
    set to the first in the list; XXX.
  • ignore – pay no attention to the email address of the user (if supplied).
pam_group.so

This module does not authenticate the user, but instead it grants
group memberships (in the credential setting phase of the
authentication
module) to the user. Such memberships are based on the service they are
applying for. The group memberships are listed in text form in the /etc/security/group.conf file.

pam_issue.so

This module allows you to prepend an issue file to the username prompt.
It also by default parses escape codes in the issue file similar to
some common getty’s (using \x format).

Recognized escapes:

  • d – current date
  • s – operating system name
  • l – name of this tty
  • m – architecture of this system (i686, sparc, powerpc, …)
  • n – hostname of this system
  • o – domainname of this system
  • r – release number of the operation system (eg. 2.2.12)
  • t – current time
  • u – number of users currently logged in
  • U – same as u, except it is suffixed with “user” or “users” (eg. “1 user” or “10
    users”
  • v – version/build-date of the operating system (eg. “#3 Mon Aug 23 14:38:16 EDT 1999″ on Linux).

The behavior of this module can be modified with one of the following flags:

  • issue – the file to output if not using the default
  • noesc – turns off escape code parsing
pam_krb5.so

pam_krb5.so is designed to allow smooth integration of Kerberos 5
password- checking with applications built using PAM. It also supports
session-specific ticket files (which are neater), and Kerberos IV
ticket file grabbing. Its main use is as an authentication module, but
it also supplies the same functions as a session-management module to
better support poorly-written applications, and a couple of other
workarounds as well. It also supports account management and
password-changing.

When a user logs in, the module’s authentication function performs
a simple password check and, if possible, obtains Kerberos 5 and
Kerberos IV credentials, caching them for later use. When the
application requests initialization of credentials (or opens a
session), the usual ticket files are created. When the application
subsequently requests deletion of credentials or closing of the
session, the module deletes the ticket files.

pam_lastlog.so

This module can be used to provide a Last login on …
message. when the user logs into the system from what ever application
uses the PAM libraries. In addition, the module maintains the /var/log/lastlog file.

The behavior of this module can be modified with one of the following flags:

  • debug – write more information to syslog(3).
  • nodate – neglect to give the date of the last login when displaying information about the last login on the system.
  • noterm – neglect to diplay the terminal name on which the last login was attempt.
  • nohost – neglect to indicate from which host the last login was attempted.
  • silent – neglect to inform the user about any previous login: just update the /var/log/lastlog file.
  • never – if the /var/log/lastlog file does not contain any
    old entries for the user, indicate that the user has never previously
    logged in with a welcome… message.
pam_ldap.so

This is a relatively new module that allows the use of ldap instead of
something like NIS or NIS+ to do distributed authentication.

pam_limits.so

Through the contents of the configuration file, /etc/security/limits.conf,
resource limits are placed on users’ sessions. Users of uid=0 are not affected by this restriction.

The behavior of this module can be modified with the following arguments:

  • debug – verbose logging to syslog(3).
  • conf=/path/to/file.conf – indicate an alternative limits configuration file to the default.
  • change_uid – change real uid to the user for who the limits
    are set up. Use this option if you have problems like login not forking
    a shell for user who has no processes. Be warned that something else
    may break when you do this.
  • utmp_early – some broken applications actually allocate a
    utmp entry for the user before the user is admitted to the system. If
    some of the services you are configuring PAM for do this, you can
    selectively use this module argument to compensate for this behavior
    and at the same time maintain system-wide consistency with a single limits.conf file.
pam_listfile

The module gets the item of the type specified – user specifies the username, PAM_USER; tty specifies the name of the terminal over which the request has been made, PAM_TTY; rhost specifies t
he name of the remote host (if any) from which the request was made, PAM_RHOST; and ruser specifies the name of the remote user (if available) who made the request, PAM_RUSER – and looks for an instance of t
hat item in the file filename. filename contains one line per item listed. If the item is found, then if sense=allow, PAM_SUCCESS is returned, causing the authorization request to succeed; e
lse if sense=deny,
PAM_AUTH_ERR is returned, causing the authorization request to fail.

If an error is encountered (for instance, if filename does not exist,
or a poorly-constructed argument is encountered), then if onerr=succeed, PAM_SUCCESS is returned, otherwise if onerr=fail, PAM_AUTH_ERR or PAM_SERVICE_ERR (as appropriate) wil
l be returned.

An additional argument, apply=, can be used to restrict the application of the above to a specific user (apply=username) or a given group (apply=@groupname). This added restriction is only meaningful when used with the
t>tty, rhost and shell items.

Besides this last one, all arguments should be specified; do not count on any default behavior, as it is subject to change.

No credentials are awarded by this module.

Classic ftpusers authentication can be implemented with this entry in /etc/pam.d/ftp

auth required pam_listfile.so onerr=succeed item=user sense-deny
file=/etc/ftpusers

Note, users listed in /etc/ftpusers file are (counterintuitively) not allowed access to the ftp service.

pam_mail.so

This module provides the you have new mail service to the
user. It can be plugged into any application that has credential hooks.
It gives a single message indicating the newness of any mail it finds
in the user’s mail folder. This module also sets the Linux-PAM
environment variable, MAIL, to the user’s mail directory.

The behavior of this module can be modified with one of the following flags:

  • debug – write more information to syslog(3).
  • dir=pathname – look for the users’ mail in an alternative directory given by pathname. The default location for mail is /var/spool/mail.
    Note, if the supplied pathname is prefixed by a `’, the directory is
    interpreted as indicating a file in the user’s home directory.
  • nopen – instruct the module to not print any mail
    information when the user’s credentials are acquired. This flag is
    useful to get the MAIL environment variable set, but to not display any
    information about it.
  • close – instruct the module to indicate if the user has any mail at the as the user’s credentials are revoked.
  • noenv – do not set the MAIL environment variable.
  • empty – indicate that the user’s mail directory is empty if this is found to be the case.
  • hash=hashcount – mail directory hash depth. For example, a hashcount of 2 would make the mailfile be /var/spool/mail/u/s/user.
  • standard – old style “You have…” format which doesn’t show the mail spool being used. this also implies empty
  • quiet – only report when there is new mail.
pam_mkhomedir.so

This module is useful for distributed systems where the user account is
managed in a central database (such as NIS, NIS+, or LDAP) and
accessed through multiple systems. It frees the administrator from
having to create a default home directory on each of the systems by
creating it upon the first successfully authenticated login of that
user. The skeleton directory (usually /etc/skel/) is used to copy default files and also set’s a umask for the creation.

The behavior of this module can be modified with one of the following flags:

  • skel – The skeleton directory for default files to copy to the new home directory.
  • umask – An octal for of the same format as you would pass to the shells umask command.
pam_motd.so

This module allows you to have arbitrary motd’s (message of the day) output after a successful login. By default this file is /etc/motd,
but is configurable to any file.

The behavior of this module can be modified with one of the following flags:

  • motd – the file to output if not using the default.
pam_nologin.so

Provides standard Unix nologin authentication. If the file /etc/nologin exists, only root is allowed to log in; other users are turned away with an error message (and the module returns PAM_AUTH_ERR or PAM_USER_UNKNOWN).
All users (root or otherwise) are shown the contents of /etc/nologin.

If the file /etc/nologin does not exist, this module defaults to returning PAM_IGNORE, but the successok module argument causes it to return PAM_SUCCESS in this case.

The administrator can override the default nologin file with the file=pathname
module argument.

pam_permit.so

No matter what management group, the action of this module is to simply return PAM_SUCCESS – operation successful.

In the case of authentication, the user’s name will be acquired. Many applications become confused if this name is unknown.

pam_pwdb.so

This module is a pluggable replacement for the pam_unix_.. modules. It uses the generic interface of the Password Database library libpwdb.

The debug argument makes the accounting functions of this module
syslog(3) more information on its actions. (Remaining arguments
supported by
the other functions of this module are silently ignored, but others are
logged as errors through syslog(3)).

Based on the following pwdb_elements: expire; last_change; max_change;
defer_change; warn_change, this module performs the task of
establishing the status of the user’s account and password. In the case
of the latter, it may offer advice to the user on changing their
password
or, through the PAM_AUTHTOKEN_REQD return, delay
giving service to the user until they have established a new password.
The entries
listed above are documented in the Password Database Library Guide (see
pointer above). Should the user’s record not contain one or more
of these entries, the corresponding shadow check is not performed.

pam_rhosts_auth.so

his module performs the standard network authentication for
services, as used by traditional implementations of rlogin and rsh etc.

The authentication mechanism of this module is based on the contents of two files; /etc/hosts.equiv (or _PATH_HEQUIV in #include ) and /.rhosts. Firstly, hosts listed in the former file are treated as equi
valent to the localhost. Secondly, entries
in the user’s own copy of the latter file is used to map remote-host remote-user pairs to that user’s account on the current host. Access is granted to the user if their host is present in /etc/hosts.equiv
and their remote account is identical to their local one, or if their
remote account has an entry in their personal configuration file.

Some restrictions are applied to the attributes of
the user’s personal configuration file: it must be a regular file (as
defined by S_ISREG(x)
of POSIX.1); it must be owned by the superuser or the user; it must not be writable by any user besides its owner.

The module authenticates a remote user (internally specified by the item PAM_RUSER) connecting from the remote host (internally specified by the item PAM_RHOST). Accordingly, for applications to be compatible this authentication module t
hey must set these items prior to calling pam_authenticate(). The module is not capable of independently probing
the network connection for such information.

In the case of root-access, the /etc/host.equiv file is ignored unless
the hosts_equiv_rootok option should be used. Instead, the superuser must have a correctly configured personal configuration file.

The behavior of the module is modified by flags:

  • debug – log more information to syslog(3). (XXX – actually, this module
    does not do any logging currently, please volunteer to fix this!)
  • no_warn – do not give verbal warnings to the user about
    failures etc. (XXX – this module currently does not issue any warnings,
    please volunteer to fix this!)
  • no_hosts_equiv – ignore the contents of the /etc/hosts.equiv file.
  • hosts_equiv_rootok – allow the use of /etc/hosts.equiv for superuser.
    Without this option /etc/hosts.equiv is not consulted for the superuser account. This option has no effect if the no_hosts_equiv option is used.
  • no_rhosts – ignore the contents of all user’s personal configuration file /.rhosts.
  • privategroup – normally, the /.rhosts file must not be
    writable by anyone other than its owner. This option overlooks group
    write access in the case that the group owner of this file has the same
    name as the user being authenticated. To lessen the security
    problems associated with this option, the module also checks that the
    user is the only member of their private group.
  • promiscuous – A host entry of `+’ will lead to all hosts
    being granted access. Without this option, ‘+’ entries will be ignored.
    Note, that the debug option will syslog a warning in this latter case.
  • suppress – This will prevent the module from syslog(3)ing a
    warning message when this authentication fails. This option is mostly
    for keeping logs free of meaningless errors, in particular when the
    module is used with the sufficient control flag.
pam_rootok.so

This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.

This module authenticates the user if their uid is 0. Applications
that are created setuid-root generally retain the uid of the user but
run with the authority of an enhanced effective-uid. It is the real uid
that is checked.

pam_securetty.so

Provides standard Unix securetty checking, which causes
authentication for root to fail unless PAM_TTY is set to a string
listed in the
/etc/securetty file. For all other users, it succeeds.

For canonical usage, should be listed as a required authentication method before any sufficient authentication methods.

pam_shells.so

This module checks for the existence of a user’s shell in /etc/shells

pam_stack.so

from the man page

In a nutshell, pam_stack lets you “call”, from inside of the
stack for a particular service, the stack defined for any another
service. The intention is to allow multiple services to “include” a
system-wide setup, so that when that setup needs to be changed, it need
only be changed in one place.

pam_stress.so

A stress testing PAM module

pam_tally.so

This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

pam_tally comes in two parts: pam_tally.so and pam_tally. The former
is the PAM module and the latter, a stand-alone program. pam_tally
is an (optional) application which can be used to interrogate and
manipulate the counter file. It can display users’ counts, set
individual
counts, or clear all counts. Setting artificially high counts may be
useful for blocking users without changing their passwords. For
example, one might find it useful to clear all counts every midnight
from a cron job.

The counts file is organized as a binary-word array, indexed by uid.
You can probably make sense of it with od, if you don’t want to use
the supplied application.

Note, there are some outstanding issues with this module: pam_tally is
very dependent on getpw*() – a database of usernames would be much more
flexible; the `keep a count of current logins’ bit has been #ifdef’d
out and you can only reset the counter on successful authentication,
for now.

The authentication component of this module increments the attempted login counter.

pam_time.so

Running a well regulated system occasionally involves restricting
access to certain services in a selective manner. This module offers
some time control for access to services offered by a system. Its
actions are determined with a configuration file. This module can be
configured to deny access to (individual) users based on their name,
the time of day, the day of week, the service they are applying for and
their terminal from which they are making their request.

This module bases its actions on the rules listed in its configuration file: /etc/security/time.conf. Each rule has the following form,

services;ttys;users;times

In words, each rule occupies a line, terminated with a newline
or the beginning of a comment; a `#’. It contains four fields separated
with semicolons, `;’. The fields are as follows:

  • services – a logic list of service names that are affected by this
    rule.
  • ttys – a logic list of terminal names indicating those terminals covered
    by the rule.
  • user – a logic list of usernames to which this rule applies

By a logic list we mean a sequence of tokens (associated with the
appropriate PAM_ item), containing no more than one wildcard character;
`*’, and optionally prefixed with a negation operator; `!’. Such a
sequence is concatenated with one of two logical operators: &
(logical
AND) and | (logical OR). Two examples are: !morgan&!root,
indicating that this rule does not apply to the user morgan nor to
root; and
tty*&!ttyp*, which indicates that the rule applies only to console
terminals but not pseudoterminals.

  • times – a logic list of times at which this rule applies. The
    format of each element is a day/time-range. The days are specified by a
    sequence of two character entries. For example, MoTuSa, indicates
    Monday Tuesday and Saturday. Note that repeated days are unset; MoTuMo
    indicates Tuesday, and MoWk means all weekdays bar Monday. The two
    character combinations accepted are,Mo Tu We Th Fr Sa Su Wk Wd AlThe last two of these being weekend days and all 7 days of the week respectively.

    The time range part is a pair of 24-hour times, HHMM,
    separated by a hyphen – indicating the start and finish time for the
    rule. If the finish time is smaller than the start time, it is assumed
    to apply on the following day. For an example, Mo1800-0300 indicates that the permitted times are Monday night from 6pm to 3am the following morning.

    Note, that the given time restriction is only applied when the first
    three fields are satisfied by a user’s application for service.

For convenience and readability a rule can be extended beyond a single line with a `\newline’.

pam_unix.so

This is the standard Unix authentication module. It uses standard calls
from the system’s libraries to retrieve and set account information
as well as authentication. Usually this is obtained from the /etc/passwd and the /etc/shadow file as well if shadow is enabled.

The debug argument makes the accounting functions of this module
syslog(3) more information on its actions. (Remaining arguments
supported by the other functions of this module are silently ignored,
but others are logged as errors through syslog(3)). The audit argument
causes even more logging.

Based on the following shadow elements: expire; last_change;
max_change; min_change; warn_change, this module performs the task of
establishing
the status of the user’s account and password. In the case of the
latter, it may offer advice to the user on changing their password or,
through the PAM_AUTHTOKEN_REQD
return, delay giving service to the user until they have established a
new password. The entries listed above are documented in the GNU Libc
info documents. Should the user’s record not contain one or more of
these entries, the corresponding shadow check is not performed.

pam_userdb.so

Look up users in a .db database and verify their password against what is contained in that database.

This module is used to verify a username/password pair against
values stored in a Berkeley DB database. The database is indexed by the
username, and the data fields corresponding to the username keys are
the passwords, in unencrypted form, so caution must be exercised over
the access rights to the DB database itself..

The module will read the password from the user using the conversation
mechanism. If you are using this module on top of another
authentication module (like pam_pwdb ;) then you should tell that module to read the entered password from the PAM_AUTHTOK field, which is set by this module.

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.d/ file.

  • debug – Supply more debugging information to syslog(3).
  • icase – Perform the password comparisons case insensitive.
  • dump – dump all the entries in the database to the log (eek, don’t do this by default!)
  • db=XXXX – use the database found on pathname XXXX. Note that
    Berkeley DB usually adds the needed filename extension for you, so you
    should use something like /etc/foodata instead of /etc/foodata.db.
pam_warn.so

This module is principally for logging information about a proposed authentication or application to update a password.

Log the service, terminal, user, remote user and remote host to
syslog(3). The items are not probed for, but instead obtained from the
standard pam-items.

pam_wheel.so

This module is used to enforce the so-called wheel group. By
default, it permits root access to the system if the applicant user is
a member
of the wheel group (better described as the group with group-id 0).

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.conf file.

  • debug – Supply more debugging information to syslog(3).
  • use_id – This option modifies the behavior of the module by
    using the current uid of the process and not the getlogin(3) name of
    the user. This option is useful for being able to jump from one account
    to another, for example with ‘su’.
  • trust – This option instructs the module to return PAM_SUCCESS should it find the user applying for root privilege is a member of the wheel group. The default action is to return PAM_IGNORE in this situation. By using the trus
    t option it is possible to arrange for wheel-group
    members to become root without typing a password. USE WITH CARE.
  • deny – This is used to reverse the logic of the module’s
    behavior. If the user is trying to get uid=0 access and is a member of
    the wheel group, deny access (for the wheel group, this is perhaps
    nonsense!): it is intended for use in conjunction with the group=
    argument…
  • group=XXXX – Instead of checking the gid=0 group, use the user’s XXXX group membership for the authentication. Here, XXXX is the name of
    the group and not its numeric identifier.

To allow only members of the wheel group to become root through su, use the following line in /etc/pam.d/su:

auth required /lib/security/pam_wheel.so use_uid
pam_warn.so

This module logs information about an authentication or password change
attempt to syslog.

This module has no arguments, and only auth and password components.
Log the service, terminal, user, remote user and remote host to
syslog(3).
The items are not probed for, but instead obtained from the standard
pam-items.

pam_xauth.so

This module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su
command to assume superuser privileges, that user is not able to run X
commands as root without somehow giving root access to the xauth key
used for the current X session. pam_xauth solves the problem by
forwarding the key from the user running su (the source user) to the
user whose identity the source user is assuming (the target user) when
the session is created, and destroying the key when the session is torn
down.


LDAP

While ldap is not an authentication mechanism, anymore than the file /etc/passwd
is, you can store authentication information in ldap, similar to the way it is stored in /etc/passwd and /etc/shadow.
So I felt it was important to include an overview of ldap as part of this discussion.


What is a directory service?

A directory is a specialized database optimized for reading, browsing
and searching. Directories tend to contain descriptive, attribute-based
information and support sophisticated filtering capabilities.
Directories generally do not support complicated transaction or
roll-back schemes found in database management systems designed for
handling high-volume complex updates. Directory updates are typically
simple all-or-nothing changes, if they are allowed at all. Directories
are tuned to give quick response to high-volume lookup or search
operations. They may have the ability to replicate information widely
in order to increase availability and reliability, while reducing
response time. When directory information is replicated, temporary
inconsistencies between the replicas may be okay, as long as they get
in sync eventually.


What is LDAP?

LDAP stands for Lightweight Directory Access Protocol. As the name
suggests, it is a lightweight protocol for accessing directory
services,
specifically X.500-based directory services. LDAP runs over TCP/IP or
other connection oriented transfer services. The nitty-gritty details
of LDAP are defined in RFC2251 “The Lightweight Directory Access
Protocol (v3).” This section gives an overview of LDAP from a user’s
perspective.


What kind of information can be stored in the directory?

The LDAP information model is based on entries. An entry is a
collection of attributes that has a globally-unique Distinguished Name (DN).
The DN is used to refer to the entry unambiguously. Each of the entry’s
attributes has a type and one or more values. The types are typically mnemonic strings, like cn for common name, or mail for email address. The syntax of values depend on the attribute type. For example, a cn attri
bute might contain the

value Babs Jensen. A mail attribute might contain the value babs@example.com. A jpegPhoto attribute would contain a photograph in the JPEG (binary) format.


How is the information arranged?

In LDAP, directory entries are arranged in a hierarchical tree-like
structure. Traditionally, this structure reflected the geographic
and/or organizational boundaries. Entries representing countries appear
at the top of the tree. Below them are entries representing states
and national organizations. Below them might be entries representing
organizational units, people, printers, documents, or just about
anything else you can think of.

The tree may also be arranged based upon Internet domain names.
This naming approach is becoming increasing popular as it allows for
directory
services to be located using the DNS.

In addition, LDAP allows you to control which attributes are
required and allowed in an entry through the use of a special attribute
called
objectClass. The values of the objectClass attribute determine the schema rules the entry must obey.


How is the information referenced?

An entry is referenced by its distinguished name, which is
constructed by taking the name of the entry itself (called the Relative
Distinguished
Name or RDN) and concatenating the names of its ancestor entries. The
full DN format is described in RFC2253, “Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names.”


How is the information accessed?

LDAP defines operations for interrogating and updating the
directory. Operations are provided for adding and deleting an entry
from the
directory, changing an existing entry, and changing the name of an
entry. Most of the time, though, LDAP is used to search for information
in the directory. The LDAP search operation allows some portion of the
directory to be searched for entries that match some criteria
specified by a search filter. Information can be requested from each
entry that matches the criteria.


How is the information protected from unauthorized access?

Some directory services provide no protection, allowing anyone to see
the information. LDAP provides a mechanism for a client to
authenticate, or prove its identity to a directory server, paving the
way for rich
access control to protect the information the server contains. LDAP
also supports privacy and integrity security services.


How does LDAP work?

LDAP directory service is based on a client-server model. One or
more
LDAP servers contain the data making up the directory information tree
(DIT). The client connects to servers and asks it a question.
The server responds with an answer and/or with a pointer to where the
client can get additional information (typically, another LDAP server).
No matter which LDAP server a client connects to, it sees the same view
of the directory; a name presented to one LDAP server references the
same entry it would at another LDAP server. This is
an important feature of a global directory service, like LDAP.


What about X.500?

Technically, LDAP is a directory access protocol to an X.500 directory
service, the OSI directory service. Initially, LDAP clients accessed
gateways to the X.500 directory service. This gateway ran LDAP between
the client and gateway and X.500′s Directory Access Protocol (DAP)
between the gateway and the X.500 server. DAP is a heavyweight protocol
that operates over a full OSI protocol stack and requires a significant
amount of computing resources. LDAP is designed to operate over TCP/IP
and provides most of the functionality of DAP at a much lower cost.

While LDAP is still used to access X.500 directory service via
gateways, LDAP is now more commonly directly implemented in X.500
servers.

The stand-alone LDAP daemon, or slapd(8), can be viewed as a
lightweight X.500 directory server. That is, it does not implement the
X.500′s
DAP. As a lightweight directory server, slapd(8) implements only a
subset of the X.500 models.


SASL


What SASL is

SASL, the Simple Authentication and Security Layer, is a method for
adding authentication support to connection-based protocols. SASL
is defined in RFC-2222. To use SASL, a protocol includes a command for
identifying and authenticating a user to a server and for optionally
negotiating a security layer between the protocol and the connection.
SASL is a means for authenticating yourself to the server without
providing your password in the clear. This can also be used to provide
extended capabilities based on your authorization. In plainer words,
a SASL mechanism can provide authentication only, or it can also
provide integrity checking, and possibly encryption as well.

During authentication , the mechanism performs authentication,
transmits an authorization identity or userid, from the client to
server, and negotiates the use of a mechanism-specific security layer,
possibly encryption.

If use of a security layer is negotiated, it is applied to all
subsequent data sent over the connection. The security layer takes
effect immediately following the last response of the authentication
exchange for data sent by the client and the completion indication for
data sent by the server. Once the security layer is in effect, all
further data transfers use this encryption.

In order to implement SASL authentication, you need support on the client and on the server

The various implementations of SASL provide the following mechanisms for authentication:

  • ANONYMOUS – used to “authenticate” clients to anonymous services; or rather just indicate that the client wishes to use the
    service anonymously. The client sends a token, usually her email address fast simple, not secure
  • CRAM-MD5 – uses username (authorization identity only) and
    password
    to authenticate users. Only a hashed password is transfered, which
    means that you cannot use normal policy deciding authentication systems
    such as PAM which do not support extraction of passwords, simple, good
    security
  • KERBEROS_V4 – trusted third party authentication, fast, somewhat difficult, strong security
  • PLAIN – uses username (authentication identity and
    authorization identity) and password to authenticate users, fastest,
    simplest, weak security
  • SCRAM-MD5 (deprecated)
  • GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5) – uses a
    framework similar to SASL for authenticating the user, fast difficult
    to implement, strong security
  • DIGEST-MD5 – based on the same cryptographic operation as
    CRAM-MD5 but supports more features, such as an authorization identity
    (proxy authentication) and cryptographic protection of data. Like
    CRAM-MD5, only a hashed password is transfered, which means that you
    cannot use e.g. PAM as a backend since it does not support extraction
    of passwords, simple, good security
  • LOGIN – uses username (authorization identity only) and password to authenticate users, fast, simple, not secure
  • SRP (unsupported, may not work)
  • OTP – One time password
  • SECURID – uses authentication and authorization identity and
    a passcode from a hardware token to authenticate users, good speed,
    hard to implement, good security

SASL is only a framework: specific SASL mechanisms govern the
exact protocol exchange. With the Cyrus SASL library, the mechanisms
need
only be written once, and they’ll work with all servers that use it.

Developers can write their own mechanisms to SASL to provide authentication.

It’s relatively easy to define a protocol that uses SASL- it has
to support a couple of simple functions, and it doesn’t need to know
anything about any particular mechanism. The first requirement is that
servers must be able to tell the client what mechanisms are available.
Typically this is done when the server sends a greeting to the client,
telling it what options it supports. The second requirement is that
clients must be able to tell the server to start a particular
mechanism, and then both must be able to exchange “blobs” of
information to initialize the mechanism, possibly indicating success or
failure. The final requirement is that on success both the client and
the server call a routine to filter traffic to/from the network.
If the mechanism is doing any kind of cryptography, this routine will
transparently handle it for the application.


Authentication and authorization identifiers

An important concept to become familiar with is the difference
between an “authorization identifier” and an “authentication
identifier”.

The transmitted authorization identity may be different than the
identity in the client’s authentication credentials. This permits
agents such as proxy servers to authenticate using their own
credentials, yet request the access privileges of the identity for
which they are proxying. With any mechanism, transmitting an
authorization identity of the empty string directs the server to derive
an authorization identity from the client’s authentication credentials.

userid
(user id, authorization id) The userid is the identifier an
application uses to check allowable options. There might exist on the
server, a user “doe” (account of John Doe) allowed to write
to “/home/doe” and it’s subdirectories but not to “/etc”.
authid
(authentication id) The authentication identifier is the identifier
that is being checked. “doe”‘s password might be “grep45″, and the
system will authenticate anyone who knows “grep45″ as “doe”. However,
it’s possible to authenticate as one user but act as another user.
For instance, John might be away on vacation and assign one of his
assistant, Jane, to read his mail. He might then allow Jane to act as
him merely by supplying her password and her id as authentication but
requesting authorization as “doe”. So Jane might log in with an
authentication identifier of “jane” and an authorization id of “doe”
and her own (Jane’s)
password. Anyone familiar with sudo, will see the similarity.

Applications can set their own proxy policies; by default, the
SASL library will only allow the same user to act for another (that is,
userid must equal authid).


Realms

The Cyrus SASL library supports the concept of “realms”. A realm is
an abstract set of users and certain mechanisms authenticate users in a
certain realm.

In the simplest case, a single server on a single machine, the realm
might be the fully-qualified domain name of the server. If the
applications
don’t specify a realm to SASL, most mechanisms will default to this.

If a site wishes to share passwords between multiple machines, it might
choose it’s authentication realm as a domain name, such as
“kernel-panic.org”. On the other hand, in order to prevent the entire
site’s security from being compromised when one machine is compromised,
each server could have it’s own realm. Certain mechanisms force the
user (client side) to manually configure what realm they’re in, making
it harder for users to authenticate.

The Kerberos mechanisms treat the SASL realm as the Kerberos realm.
Thus, the realm for Kerberos mechanisms defaults to the default
Kerberos
realm on the server. They may support cross-realm authentication; check
your application on how it deals with this.

Some authentication mechanisms, such as PLAIN and CRAM-MD5, do not support the concept of realms.


How SASL works

How SASL works is governed by what mechanism the client and server
choose to use and the exact implementation of that mechanism. This
section describes the way these mechanisms act in the Cyrus SASL
implementation.


The PLAIN mechanism and sasl_checkpass() call

The PLAIN mechanism is not a secure method of authentication by
itself. It is intended for connections that are being encrypted by
another
level. (For example, the IMAP command “STARTTLS”
creates an encrypted connection over which PLAIN might be used.) The
PLAIN mechanism works by transmitting a userid, an authentication
id, and a password to the server, and the server then determines
whether that is an allowable triple.

The principal concern for system administrators is how the
authentication and password are verified. The Cyrus SASL library is
flexible in this regard:


  • passwd

    /etc/passwd is supported innately in the library. Simply set the configuration
    option “pwcheck_method” to “passwd”.

  • shadow

    /etc/shadow is somewhat trickier. If the servers that use SASL run as root (such as Sendmail) there’s no problem: just set the pwcheck_method; option to shadow.
    However, many daemons do not run as root for additional security, such
    as Cyrus imapd. In order for these servers to check passwords, they
    either need a helper program that runs as root, or need special
    privileges to read /etc/shadow. The easiest way is to give the server the rights to read /etc/shadow
    by, for instance, adding the cyrus user to the shadow group and then setting pwcheck_method to shadow.It is also possible to write a special PAM module that has the required
    privileges; default PAM setups do not (to my knowledge) come with this.

  • kerberos_v4
    The first challenge consists of a random 32-bit number in network
    byte order. The client responds with a Kerberos ticket and an
    authenticator
    for the principal “service.hostname@realm”, where
    “service” is the service name specified in the protocol’s profile,
    “hostname” is the first component of the host name of the server with
    all letters in lower case, and where “realm” is the Kerberos realm of
    the server. The encrypted checksum field included within the Kerberos
    authenticator contains the server provided challenge in network byte
    order.

  • pam
    PAM, the pluggable authentication module, is the default way of
    authenticating users on Solaris and Linux. It can be configured to
    check passwords in many different ways: through Radius, through NIS,
    through LDAP, or even using the traditional /etc/passwd file. If you
    wish to use
    PAM for authentication and the Cyrus SASL library found the PAM library
    when it was configured at compilation time, it is the default (or set
    “pwcheck_method” to “PAM”). It uses PAM with the service name (for
    example, Sendmail uses “smtp”
    and Cyrus imapd uses “imap”).The PAM authentication for SASL only affects the plaintext
    authentication it does. It has no effect on the other mechanisms, so it
    is incorrect to try to use PAM to enforce additional restrictions
    beyond correct password on an application that uses SASL for
    authentication.

  • sasldb
    This stores passwords in the SASL secrets database, the same
    database that stores the secrets for shared secret methods. Its
    principal advantage is that it means that the passwords used by the
    shared secrets mechanisms will be in sync with the plaintext password
    mechanisms. However, system built-in routines will not use sasldb.Note that to set plaintext passwords in sasldb, you need to
    configure “saslpasswd” to do so. The “saslpasswd” uses the same
    configuration files like any SASL server. Make /usr/lib/sasl/saslpasswd.conf contain the line “pwcheck_method: sasldb” to instruct
    “saslpasswd” to create plaintext secrets in addition to the normal secrets.

  • write your own

    Last, but not least, the most flexible method of authentication for
    PLAIN is to write your own. If you do so, any application that calls
    the “sasl_checkpass()” routine or uses PLAIN will
    invoke your code. The easiest place to modify the plaintext
    authentication routines is to modify the routine _sasl_checkpass()
    in the file lib/server.c to support a new method, and to add that
    method to lib/checkpw.c. Be sure to add a prototype in lib/saslint.h!


Shared secrets mechanisms

The Cyrus SASL library also supports some “shared secret”
authentication methods: CRAM-MD5 and it’s successor DIGEST-MD5. These
methods rely on the client and the server sharing a “secret”,
usually a password. The server generates a challenge and the client a
response proving that it knows the shared secret. This is much more
secure than simply sending the secret over the wire proving that the
client knows it.

There’s a downside: in order to verify such responses, the server must
keep password equivalents in a database; if this database is
compromised, it is the same as if every user’s password for that realm
is compromised.

The Cyrus SASL library stores these secrets in the /etc/sasldb
database. Depending on the exact database method used (gdbm, ndbm, or
db) the file may have different suffixes or may even have two different
files (“sasldb.dir” and “sasldb.pag”). It is also possible for a server
to define it’s own way of storing authentication secrets. Currently, no
application is known to do this.

The principle problem for a system administrator is to make sure that
sasldb is properly protected; only the servers that need to read it
to verify passwords should be able to. If there are any normal shell
users on the system, they must not be able to read it.

Managing password changes is outside the scope of the library. However,
system administrators should probably make a way of letting user’s
change their passwords available to users. The “saslpasswd” utility is
provided to change the secrets in sasldb. It does not affect PAM,
/etc/passwd, or any other standard system library; it only affects
secrets stored in sasldb.

Finally, system administrators should think if they want to enable
“auto_transition”. If set, the library will automatically create
secrets in sasldb when a user uses PLAIN to successfully authenticate.
However, this means that the individual servers, such as imapd, need
read/write access to sasldb, not just read access. By default,
“auto_transition”
is set to false; set it to true to enable. (There’s no point in
enabling this option if “pwcheck_method” is “sasldb”.)


Kerberos mechanisms

The Cyrus SASL library also comes with two mechanisms that make use
of Kerberos: KERBEROS_V4, which should be able to use any Kerberos v4
implementation, and GSSAPI (tested against MIT Kerberos 5 and Heimdal
Kerberos 5). These mechanisms make use of the kerberos infrastructure
and thus have no password database.


How to set configuration options

The Cyrus SASL library comes with a built-in configuration file reader.
However, it is also possible for applications to redefine where the
library gets it’s configuration options from.


The default configuration file

By default, the Cyrus SASL library reads it’s options from /usr/lib/sasl/App.conf
(where “App” is the application defined name of
the application). For instance, Sendmail reads it’s configuration from /usr/lib/sasl/Sendmail.conf and the sample
server application included with the library looks in /usr/lib/sasl/sample.conf.

A standard Cyrus SASL configuration file looks like:

srvtab: /var/app/srvtab
pwcheck_method: kerberos_v4


Application configuration

Applications can redefine how the SASL library looks for
configuration information. Check your application’s documentation for
specifics.

For instance, Cyrus imapd reads its sasl options from it’s own configuration file, /etc/imapd.conf, by prepending all SASL options with sasl_: the SASL option pwcheck_method is set by changing
sasl_pwcheck_option in /etc/imapd.conf. Check your application’s documentation for more information.


Kerberos


What is Kerberos?

Kerberos is a network authentication protocol. It is designed to
provide strong authentication for client/server applications by using
secret-key
cryptography. A free implementation of this protocol is available from
the Massachusetts Institute of Technology. Kerberos is available
in many commercial products as well.


The Internet is an insecure place.

Many of the protocols used in the Internet do not provide any
security. Tools to “sniff” passwords off of the network are in common
use by malicious hackers. Thus, applications which send an unencrypted
password over the network are extremely vulnerable. Worse yet, other
client/server applications rely on the client program to be honest
about the identity of the user who is using it. Other applications rely
on the client to restrict its activities to those which it is allowed
to do, with no other enforcement by the server.


Kerberos was created by MIT

Kerberos was created by MIT as a solution to these network security
problems. The Kerberos protocol uses strong cryptography so that a
client can prove its identity to a server (and vice versa) across an
insecure network connection. After a client and server has used
Kerberos to prove their identity, they can also encrypt all of their
communications to assure privacy and data integrity as they go about
their business.

Kerberos is freely available from MIT, under copyright
permissions very similar those used for the BSD operating system and
the X Window
System. MIT provides Kerberos in source form so that anyone who wishes
to use it may look over the code for themselves and assure themselves
that the code is trustworthy. In addition, for those who prefer to rely
on a professionally supported product, Kerberos is available
as a product from many different vendors.

In summary, Kerberos is a solution to your network security
problems. It provides the tools of authentication and strong
cryptography over
the network to help you secure your information systems across your
entire enterprise.


How Kerberos Works

This section provides a simplified description of a general user’s
interaction with the Kerberos system. This interaction happens
transparently-users don’t need to know and probably don’t care about
what’s going on-but
Kerberos administrators might find a schematic description of the
process useful. This description glosses over a lot of details.


Network Services and Their Client Programs

In an environment that provides network services, you use client
programs to request services from server programs that are somewhere on
the
network. Suppose you have logged in to a workstation and you want to rlogin to a typical UNIX host. You use the local rlogin client
program to contact the remote machine’s rlogind daemon.


Kerberos Tickets

Under Kerberos, the `klogind’ daemon allows you to login to a remote
machine if you can provide `klogind’ a Kerberos ticket which proves
your identity. In addition to the ticket, you must also have possession
of the corresponding ticket session key. The combination of a ticket
and the ticket’s session key is known as a credential.

Typically, a client program automatically obtains credentials
identifying the person using the client program. The credentials are
obtained
from a Kerberos server that resides somewhere on the network. A
Kerberos server maintains a database of user, server, and password
information.


The Kerberos Database

Kerberos will give you credentials only if you have an entry in the
Kerberos server’s Kerberos database. Your database entry includes
your Kerberos principal (an identifying string, which is often just
your username), and your Kerberos password. Every Kerberos user must
have an entry in this database.


Kerberos Realms

Each administrative domain will have its own Kerberos database,
which contains information about the users and services for that
particular
site or administrative domain. This administrative domain is the
Kerberos realm.

Each Kerberos realm will have at least one Kerberos server,
where the master Kerberos database for that site or administrative
domain
is stored. A Kerberos realm may also have one or more slave servers,
which have read-only copies of the Kerberos database that are
periodically
propagated from the master server.


The Ticket-Granting Ticket

The kinit command prompts for your password. If you enter it
successfully,
you will obtain a ticket-granting ticket and a ticket session key which
gives you the right to use the ticket. This combination of the
ticket and its associated key is known as your credentials. As
illustrated below, client programs use your ticket-granting ticket
credentials in order to obtain client-specific credentials as needed.

Your credentials are stored in a credentials cache, which is often just a file in /tmp. The credentials cache is also called the ticket
file, especially in Kerberos V4 documentation. Note, however, that a credentials cache does not have to be stored in a file.


Network Services and the Master Database

The master database also contains entries for all network services
that require Kerberos authentication. Suppose that your site has a
machine, laughter.mit.edu, that requires Kerberos authentication from anyone who wants to `rlogin’ to it. The host’s Kerberos realm
is ATHENA.MIT.EDU.

This service must be registered in the Kerberos database, using the proper service name, which in this case is the principal:

host/laughter.mit.edu@ATHENA.MIT.EDU

The / character separates the Kerberos primary (in this case, host) from the instance (in this case, laughter.mit.edu); the @ character separates the realm name (in this case, ATHENA.MIT.EDU) from the
rest of the principal. The primary, host, denotes the name or type of the service that is being offered: generic host-level access to
the machine. The instance, laughter.mit.edu,
names the specific
machine that is offering this service. There will generally be many
different machines, each offering one particular type of service,
and the instance serves to give each one of these servers a different
Kerberos principal.


The Keytab File

For each service, there must also be a service key known only by
Kerberos and the service. On the Kerberos server, the service key is
stored
in the Kerberos database.

On the server host, these service keys are stored in key tables, which
are files known as keytabs.(1) For example, the service keys used
by services that run as root are usually stored in the keytab file /etc/krb5.keytab.


The User/Kerberos Interaction

Suppose that you walk up to a host intending to login to it, and then rlogin to the machine laughter. Here’s what happens:

  • You login to the workstation and use the kinit command to
    get a ticket-granting ticket. This command prompts you for your
    Kerberos password. (On systems running the Kerberos V5 login program, this
    may be done as part of the login process, not requiring the user to run a separate program.)
  • The kinit command sends your request to the Kerberos master server machine. The server software looks for your principal name’s entry
    in the Kerberos database.
  • If this entry exists, the Kerberos server creates and returns a ticket-granting
    ticket and the key which allows you to use it, encrypted by your password. If kinit
    can decrypt the Kerberos reply using the password you provide, it
    stores this ticket in a credentials cache on your local machine for
    later use. The name of the credentials cache can be specified
    in the KRB5CCNAME environment variable. If this variable is not set, the name of the file will be /tmp/krb5cc_, where
    is your UNIX user-id, represented in decimal format.
  • Now you use the rlogin client to access the machine laughter.


host% rlogin laughter

  • The rlogin client checks your ticket file to see if you have a ticket for the host service for laughter. You don’t, so rlogin uses the credential cache’s ticket-granting ticket to make a request to the master server’s ticke
    t-granting service.
  • This ticket-granting service receives the request for a ticket for host/laughter.mit.edu, and looks in the master database for an entry for host/laughter.mit.edu. If the entry exists, the ticket-granting service issues you a ticket for t
    hat service. That ticket is also
    cached in your credentials cache.
  • The rlogin client now sends that ticket to the laughter klogind
    service program. The service program checks the ticket by using its own
    service key. If the ticket is valid, it now knows your identity.
    If you are allowed to login to laughter (because your username matches one in /etc/passwd, or your Kerberos principal is in the appropriate .k5login file), klogind will let you login.


Definitions

Following are definitions of some of the Kerberos terminology.

  • client – an entity that can obtain a ticket. This entity is usually either a user or a host.
  • host – a computer that can be accessed over a network.
  • Kerberos – in Greek mythology, the three-headed dog that guards the entrance to the underworld. In the computing world, Kerberos is a
    network security package that was developed at MIT.
  • KDC – Key Distribution Center. A machine that issues Kerberos tickets.
  • keytab – a key table file containing one or more keys. A host or
    service uses a keytab file in much the same way as a user uses his/her
    password.
  • principal – a string that names a specific entity to which a set of credentials may be assigned. It generally has three parts:
    • primary – the first part of a Kerberos principal. In the case of
      a user, it is the username. In the case of a service, it is the name of
      the service.
    • instance – the second part of a Kerberos principal. It gives
      information that qualifies the primary. The instance may be null. In
      the case of a user, the instance is often used to describe the intended
      use of the corresponding credentials. In the case of a host, the
      instance
      is the fully qualified hostname.
    • realm – the logical network served by a single Kerberos database
      and a set of Key Distribution Centers. By convention, realm names are
      generally all uppercase letters, to differentiate the realm from the
      Internet domain. The typical format of a typical Kerberos principal is
      primary/instance@REALM.
  • service – any program or computer you access over a network.
    Examples of services include “host” (a host, e.g., when you use telnet
    and rsh), “ftp” (FTP), “krbtgt” (authentication; cf. ticket-granting
    ticket), and “pop” (email).
  • ticket – a temporary set of electronic credentials that verify the identity of a client for a particular service.
  • TGT – Ticket-Granting Ticket. A special Kerberos ticket that
    permits the client to obtain additional Kerberos tickets within the
    same Kerberos realm.


NIS NIS+


What are NIS and NIS+?

The Network Information Service (NIS) provides a simple network lookup
service consisting of databases and processes. It was formerly known
as Sun Yellow Pages (YP). The name had to be changed when British
Telecom claimed to have the copyright of this term, and so it became
NIS. The functionality of the two remains the same; only the name has
changed. Its purpose is to provide information, that has to be
known throughout the network, to all machines on the network.
Information likely to be distributed by NIS is:

  • login names/passwords/home directories (/etc/passwd)
  • group information (/etc/group)
  • host names and IP numbers (/etc/hosts)

So, for example, if your password entry is recorded in the NIS
passwd database, you will be able to login on all machines on the net
which
have the NIS client programs running.

NIS+ (Network Information Service Plus) was introduced by Sun
Microsystems with the Solaris 2.x OS. It is compatible with NIS, but
has a lot
of additional features. With NIS+ it is possible to have hierarchical
domains. All changes are done in the NIS+ database, it is not longer
necessary to make changes on source files and to rebuild the complete
maps. All changes are logged, so that a replica server can sync if
it was down for some time.

The choice between NIS and NIS+ is easy – use NIS+ only if you
have severe security needs. NIS+ is _much_ more problematic to
administer
(it’s pretty easy to handle on the client side, but the server side is
horrible). Another problem is that the support for NIS+ under Linux
contains a lot of bugs and that the development has stopped.

NIS benefits users because it improves ease of use of a
network. Without NIS, having a large number of systems on the network
can create problems for the user. The user would need to remember a
different password for every system they use, or else maintain the same
password for
every system themselves, and update their password on each system
separately.

NIS benefits system administrators because it improves ease of
administration of a network. NIS reduces the effort of maintaining a
large number
of systems and provides a global user ID (UID) and group ID (GID) name
space. Suppose you are using NFS to make the user’s directories
and files available on every system. Because NFS does not try to
translate UIDs or GIDs between systems, you must ensure that each user
in the
network has the same user ID and group ID on every system. For example,
a user on a workstation whose UID is 205 and whose GID is 35 must have
the same UID and GID (205 and 35) in the /etc/passwd file on every workstation that user accesses. If this is not done, a user
on one system who creates a file and logs into another system may find that the file is owned by another user.


How NIS works

Within a network there must be at least one machine acting as a NIS
server. You can have multiple NIS servers, each serving different
NIS “domains” – or you can have cooperating NIS
servers, where one is the master NIS server, and all the other are
so-called slave NIS servers (for a certain NIS “domain”, that is!) – or
you can have a mix of them…

Slave servers only have copies of the NIS databases and receive
these copies from the master NIS server whenever changes are made to
the master’s databases. Depending on the number of machines in your
network and the reliability of your network, you might decide to
install one
or more slave servers. Whenever a NIS server goes down or is too slow
in responding to requests, a NIS client connected to that server will
try to find one that is up or faster.

Slave servers will be notified of any change to the NIS maps,
(via the yppush program), and automatically retrieve the necessary
changes
in order to synchronize their databases. NIS clients do not need to do
this since they always talk to the NIS server to read the information
stored in it’s DBM databases.

Old ypbind versions do a broadcast to find a running NIS
server. This is insecure, due the fact that anyone may install a NIS
server and
answer the broadcast queries. Newer Versions of ypbind (ypbind-3.3 or
ypbind-mt) are able to get the server from a configuration file – thus
no need to broadcast.


How NIS+ works

NIS+ is a new version of the network information nameservice from
Sun. The biggest difference between NIS and NIS+ is that NIS+ has
support for data encryption and authentication over secure RPC.

The naming model of NIS+ is based upon a tree structure. Each
node in the tree corresponds to an NIS+ object, from which we have six
types: directory, entry, group, link, table and private.

The NIS+ directory that forms the root of the NIS+ namespace is
called the root directory. There are two special NIS+ directories:
org_dir
and groups_dir. The org_dir directory consists of all administration
tables, such as passwd, hosts, and mail_aliases. The groups_dir
directory consists of NIS+ group objects which are used for access
control. The collection of org_dir, groups_dir and their parent
directory is referred to as an NIS+ domain.

NIS+ servers were created with the ability to “speak” the NIS/YP client
protocol. This means that a NIS+ server can support both NIS and NIS+
clients. However, the converse is not true.


What are some terminology differences between NIS and NIS+?

  • Objects – NIS “maps” are called “tables” in NIS+.
  • Servers – NIS secondary/backup/read-only servers are “slaves;”
    in NIS+, they are “replicas.”


NIS Requirements


  • The RPC Portmapper
    The RPC portmapper (portmap(8)) is a server that converts RPC
    program numbers into TCP/IP (or UDP/IP) protocol port numbers. It must
    be
    running in order to make RPC calls (which is what the NIS/NIS+ client
    software does) to RPC servers (like a NIS or NIS+ server) on that
    machine. When an RPC server is started, it will tell portmap what port
    number it is listening to, and what RPC program numbers it is prepared
    to serve. When a client wishes to make an RPC call to a given
    program number, it will first contact portmap on the server machine to
    determine the port number where RPC packets should be sent.

  • ypserv
    The server providing the main NIS service. The NIS domain is completely
    independent of the IP domain of which the machines are part. It is
    possible, and may seem convenient, to use the same name for both
    services.

  • ypbind
    Clients run the ypbind daemon, which enables client processes to
    obtain information from a server. Clients do not maintain maps
    themselves,
    but rather query servers for system and user account information.
    (Clients do not make a distinction between querying the master server
    or a slave server.) To access system information contained in an map, a
    client makes a Remote Procedure Call (RPC) to a server. The server
    searches its local database and returns the requested information to
    the client.

  • NIS Maps
    NIS maps are databases that specify certain system information
    such as user names, passwords, and host names, in a database format
    called
    DBM (Database Management). Each map is constructed from a standard text
    file by associating an index key with a value. For example, the
    information in the master server’s /etc/hosts file is used to create a
    map that uses each host name as a key, and the IP address as the value.
    The key and value pairs (also known as records) that are created from
    the entries in the /etc/hosts file comprise the hosts.byname map.

  • The nsswitch.conf File
    The Network Services switch file /etc/nsswitch.conf determines the
    order of lookups performed when a certain piece of information is requested, just like the /etc/host.conf file which determines the
    way host lookups are performed.For example, the line

    hosts: files nis dns

    specifies that host lookup functions should first look in the local /etc/hosts file, followed by a NIS lookup and finally through the
    domain name service (/etc/resolv.conf and named), at which point if no match is found an error is returned. This file must be readable
    for every user!


  • Shadow Passwords with NIS
    Shadow passwords over NIS are always a bad idea. You loose the
    security, which shadow gives you, and it is supported by only some few
    Linux
    C Libraries. A good way to avoid shadow passwords over NIS is, to put
    only the local system users in /etc/shadow. Remove the NIS user entries
    from the shadow database, and put the password back in passwd. So you
    can use shadow for the root login, and normal passwd for NIS user. This
    has the advantage that it will work with every NIS client.


    • Linux
      The only Linux libc which supports shadow passwords over NIS, is
      the GNU C Library 2.x. Linux libc5 has no support for it. Linux libc5
      compiled with NYS enabled has some code for it. But this code is badly
      broken in some cases and doesn’t work with all correct shadow entries.

    • PAM
      Linux-PAM 0.75 and newer does support Shadow passwords over NIS
      if you use the pam_unix.so Module or if you install the extra
      pam_unix2.so
      Module. Old systems using pam_pwdb/libpwdb (for example Red Hat Linux
      5.x) need to change the /etc/pam.d/* entries. All pam_pwdb rules should
      be replaced through a pam_unix_* module.


NIS+ Requirements

There is no NIS+ server for Linux and it doesn’t look like that
there ever will be one. Currently all NIS+ development has ceased.

The Linux NIS+ client code was developed for the GNU C library
2. There is also a port for Linux libc5, since most commercial
Applications
where linked against this library in the past, and you cannot recompile
them for using glibc. There are problems with libc5 and NIS+: static
programs cannot be linked with it, and programs compiled with this
library will not work with other libc5 versions.


  • NIS+, keylogin, login and PAM
    When the user logs in, he need to set his secretkey to keyserv. This is done by calling keylogin.
    The login from the shadow package will do this for the user, if it was
    compiled against glibc 2.1. For a PAM aware login, you have to change
    the /etc/pam.d/login file to use pam_unix2, not pwdb, which doesn’t support NIS+.

  • The nsswitch.conf File
    The Network Services switch file /etc/nsswitch.conf
    determines the order of lookups performed when a certain piece of
    information is requested, just like the /etc/host.conf file which
    determines the
    way host lookups are performed. For example, the line

    hosts: files nisplus dns

    specifies that host lookup functions should first look in the local /etc/hosts file, followed by a NIS+ lookup and finally through the domain name service (/etc/resolv.conf and named), at which point if no match is found an error is returned
    .


SSH


What is SSH?

The Acronym SSH stands for Secure Shell. There are a couple of ways
that you can access most Linux/Unix systems. The most common way is
to use a telnet program such as the one called telnet(for Unix and
Windows). Accessing a shell account in this fashion though poses a
danger in that everything that you do over that telnet session is
visible in plain text on your local network, and the local network of
the machine you are connecting to.

As one solution SSH was created to encrypt the data being sent
over the network as well as provide an option that prevents passwords
from
being ever passed over the network. SSH can use several different forms
of encryption, anywhere from 56 to 1024 bit. SSH has been ported
to Operating Systems on several platforms including Linux, Microsoft
Windows and Macintosh.

The following safeguards are provided by SSH:

  • After an initial connection, the client verifies it is connecting to the same server during subsequent sessions.
  • The client transmits its authentication information to the server, such as a username and password, in an encrypted format.
  • All data sent and received during the connection is transferred
    using strong, 128 bit encryption, making it extremely difficult to
    decrypt and read.
  • The client has the ability to use X11 [1] applications launched
    from the shell prompt. This technique, called X11 forwarding, provides
    a secure means to use graphical applications over a network.

Because the SSH protocol encrypts everything it sends and
receives, it can be used to secure otherwise insecure protocols. Using
a technique
called port forwarding, an SSH server can become a conduit to secure
insecure protocols, like POP, increasing overall system and data
security.


Why Use SSH?

Threats to network traffic include packet sniffing, DNS and IP
spoofing [2] and the proliferation of fake routing information. In
general terms, these threats can be categorized as follows:

  • Interception of communication between two systems – In this
    scenario, a third party exists somewhere on the network between
    communicating
    entities and makes a copy of the information being passed between them.
    The intercepting party may intercept and keep the information, or it
    may alter the information and send it on to the intended recipient.
  • Impersonation of a particular host – Using this strategy, an
    intercepting system pretends to be the intended recipient of a message.
    If the
    strategy works, the client remains unaware of the deception and
    continues to communicate with the interceptor as if its traffic had
    successfully
    reached its destination.

Both techniques cause information to be intercepted, possibly for
hostile reasons. The results can be disastrous, whether that goal
is achieved by listening for all packets on a LAN or a hacked DNS
server pointing to a maliciously duplicated host.

If SSH is used for remote shell logins and file copying, these
security threats can be greatly diminished. A server’s digital
signature provides
verification for its identity. The entire communication between client
and server systems cannot be used if intercepted, because each of
the packets is encrypted. Attempts to spoof the identity of either side
of a communication will not work, since each packet is encrypted
using a key known only by the local and remote systems.


Heimdal

Heimdal is a free implementation of Kerberos 5.


Refeferences


The Linux-PAM System Administrators’ Guide


Pluggable Authentication Modules


Linux Journal Archive: Pluggable Authentication Modules for Linux


O’Reilly Article on PAM Modules


Linux PAM FAQ


Linux Documentation Project: User-Authentication HOWTO


Introduction to OpenLDAP Directory Services


RFC 2551 Lightweight Directory Access Protocol (v3)


RFC2553 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names


Carnegie Mellon University:Cyrus SASL


The GNU SASL Manual


RFC 2222 Simple Authentication and Security Layer (SASL)


Cyrus SASL for System Administrators


Kerberos: The Network Authentication Protocol


Kerberos V5 System Administrator’s Guide


The Linux NIS(YP)/NYS/NIS+ HOWTO


Red Hat Linux 7.3: The Official Red Hat Linux Reference Guide: Chapter 10; SSH Protocol

Share