PGP Authentication Support

LPRng Reference Manual: 24 Sep 2004 (For LPRng-3.8.28)
Prev | Chapter 17. Permissions and Authentication | Next

# 17.12. PGP Authentication Support

PGP is a well known encryption and authentication program. For more details see the web site http://www.pgp.net or the ftp site ftp://ftp.pgp.net.

LPRng has greatly simplified the use of PGP for authentication by building in support as follows.

- The user and group configuration entry (defaults daemon and daemon respectively) specify the user and group id used by the lpd server for file and program execution. PGP uses the current user id of the PGP process to determine the locations of various configuration files and information. In this discussion we will assume that lpd runs as uid daemon.

- By default, the PGP program expects the public and secret key rings to be in the `$HOME/.pgp/` directory to be readable only by the user. In order to set up PGP authentication, make sure that the daemon account has a home directory. The daemon user should not allow logins or have its login password disabled.

- Each PGP key has an associated identifier. It is recommended that the lpd key be lpr@hostname, where hostname is the fully qualified domain name of the server.

- Create the public and private keys for the server. For security reasons the daemon account should not have login capabilities.

          #> su /bin/sh      # start root shell
          %> HOME=/tmp
          %> export HOME
          %> mkdir /tmp/.pgp
          %> pgp -kg
                # select 1024 or longer keys
                # set the user id to be lpr@hostname as discussed above
                # set the pass phrase
          %> ls /tmp/.pgp
          pubring.bak   pubring.pgp  randseed.bin  secring.pgp
          %> cd /tmp/.pgp
          %> pgp -kxa lpr@hostname serverkey pubring.pgp  # creates serverkey.asc
                # you will want to give serverkey.asc to users to add to their
                # public key ring
          %> mkdir ~daemon/.pgp
          %> cp * ~daemon/.pgp
          %> chown daemon ~daemon/.pgp ~daemon/.pgp/*
          %> chmod 700 ~daemon/.pgp
          %> chmod 644 ~daemon/.pgp/*

- Next, place the passphrase for the daemon user in `~daemon/.pgp/serverkey`, and make sure it has owner daemon and 600 permissions (read/write only by daemon). This is extremely important. If other users can read this file then security will be severely compromised.

- Next, distribute the servername.asc file to users. LPRng server. This is usually done by placing the key file in a well known file location or making it available to users by some form of Public Key Distribution system (PKD).

- Users add the serverkey.asc key to their public key using:

          pgp -ka serverkey.asc

- Finally, the administrator will need to add the users public keys to the daemonpublic key ring file pubkey.pgp. This can most easily be done by copying all of the users public keys (in ASCII text format) to a single file (`/tmp/keyfile`)and using:

          su daemon
          pgp -ka /tmp/keyfile ~daemon/.pgp/pubring.pgp

- If the lpd server is using PGP to forward jobs or requests, the destination server's public key must be put in the originating servers public keyring. For example:

          su daemon
          pgp -ka /tmp/lpd.keyfile ~daemon/.pgp/pubring.pgp

## 17.12.1. Printcap Configuration

Options used:

- pgp_path=path to PGP program

- pgp_id=destination server key used by clients

- pgp_forward_id=destination server used by server

- pgp_server_key=path to server passphrase file

Example printcap entry:

        pr:
            :lp=pr@wayoff
            :auth=pgp
            :pgp_id=lpr@wayoff.com
            :pgp_path=/usr/local/bin/pgp
        pr:server
            :lp=pr@faroff
            :auth_forward=pgp
            :pgp_id=lpr@wayoff.com
            :pgp_path=/usr/bin/pgp
            :pgp_forward_id=lpr@faroff.com

The pgp_path value is the path to the PGP program. The program must be executable by all users.

The pgp_id value is the id used by PGP to look extract keys from key rings. When doing a client to server transfer this will be supplied as the id to be used for the destination, and the user's public keyring will be checked for a key corresponding to this id. When a request arrives at the server, the server will use this value as the id of a key in its private key ring. Finally, when a server is forwarding a request to a remote server, it will use this value as the id of the key in its private key ring to be used to sign or encode the destination information.

The pgp_forward_id value is used by the lpd server as the id to use to find a key for the destination.

The pgp_server_key is the path to the file containing the server passphrase. This file will be read by lpd to get the passphrase to unlock the server's keyring.

## 17.12.2. User Files and Environment Variables

Options used:

- PGPPASSFILE=File to read PGP passphrase from

- PGPPASSFD=File descriptor to read PGP passphrase from

- PGPPASS=PGP passphrase

One problem with using PGP is the need to have users input their passphrases. The following methods can be used.

- Put the passphrase in a file, say `$(HOME)/.pgp/.hidden`, and set the PGPPASSFILE environment variable to the file name. This file will be opened and read by PGP to get the passphrase. This file should be owned by the user and have 0600 or read/write only by user permissions.

- A more subtle solution is to use the PGPPASSFD environment variable facility. This causes PGP to read the passphrase from a file descriptor. If the user puts his passphrase in a file, say `$(HOME)/.pgp/.hidden`, then the following shell script can be used:

          #!/bin/sh
          #  /usr/local/bin/pgplpr script - passphrase in $(HOME)/.pgp/.hidden
          #
          PGPASSFD=3 3<$(HOME)/.pgp/.hidden lpr "$@"

- The least desirable method is to put the passphrase in the PGPPASS environment variable. Since the ps command can be used to list the environment variables of processes, this is highly undesirable and should not be used under any circumstances.

Prev | Home | Next
Permission Checking | Up | Using Kerberos 5 for Authentication