Secure Cooking with Linux, Part 1

Editor's note: The authors of Linux Security Cookbook have selected a number of recipes from their book to present here. These recipes are organized into basic, intermediate, and advanced categories. This week's set consists of three recipes of a basic flavor. Over the next two weeks we'll present the intermediate and then advanced recipes. There'll be something for everyone here. Enjoy.

Recipe 6.4: Authenticating by Public Key (OpenSSH)

Author's note: SSH is a protocol for secure, remote logins and file copying; and OpenSSH, provided with most Linux distributions, is its most popular implementation. This recipe, selected from Chapter 6 on "Protecting Outgoing Network Connections," shows you how to use public-key authentication to prove your identity to a remote OpenSSH server, a technique more secure than using login passwords.

Problem

You want to set up public-key authentication between an OpenSSH client and an OpenSSH server.

Tip

OpenSSH public keys go into the file ~/.ssh/authorized_keys. Older versions of OpenSSH,
however, require SSH-2 protocol keys to be in ~/.ssh/authorized_keys2.

Discussion

Public-key authentication lets you prove your identity to a remote host using
a cryptographic key instead of a login password. SSH keys are more secure than
passwords because keys are never transmitted over the network, whereas passwords
are (albeit encrypted). Also, keys are stored encrypted, so if someone steals
yours, it's useless without the passphrase for decrypting it. A stolen password,
on the other hand, is immediately usable.

An SSH "key" is actually a matched pair of keys stored in two
files. The private or secret key remains on the client machine, encrypted with a
passphrase. The public key is copied to the remote (server) machine. When
establishing a connection, the SSH client and server perform a complex
negotiation based on the private and public key, and if they match (in a
cryptographic sense), your identity is proven and the connection succeeds.

To set up public-key authentication, first create an OpenSSH key pair, if you
don't already have one:

and you're done! If things aren't working, rerun ssh
with the -v option (verbose) to help diagnose the
problem.

The SSH server must be configured to permit
public-key authentication, which is the default:

/etc/ssh/sshd_config:
PubkeyAuthentication yes If no, change it and restart sshd

For more convenience, you can eliminate the passphrase prompt using ssh-agent [Recipe 6.9] and create host
aliases in ~/.ssh/config. [Recipe 6.12]

See Also

ssh(1), scp(1), ssh-keygen(1).

SSH-2 Key File Formats

The two major implementations of SSH—OpenSSH and SSH Secure Shell ("SSH2")—use different file formats for SSH-2 protocol keys.
(Their SSH-1 protocol keys are compatible.) OpenSSH public keys for the
SSH-2 protocol begin like this:

These keys are installed differently too. For OpenSSH, you insert
your public keys into the file ~/.ssh/authorized_keys. For SSH
Secure Shell, you copy your public key files into the directory ~/.ssh2 and reference them in the file ~/.ssh2/authorization by name:

Key public_key_filename

As for private keys, OpenSSH has no special requirements for
installation, but SSH Secure Shell does. You
must reference them in the file ~/.ssh2/identification by name:

IdKey private_key_filename

Recipe 7.25: Encrypting Backups

Author's note: If someone steals one of your backup tapes, your sensitive information could become compromised. This recipe, excerpted from Chapter 7 on "Protecting Files," illustrates how to encrypt the contents of a backup tape using GnuPG (gpg), a popular encryption program for Linux and other operating systems.

where SPEED and SCSIDEVICE
are specific to your system; see cdrecord(1).

Method 2: Encrypt files separately.

Make a new directory containing links to your original files:

$ cp -lr mydir newdir

In the new directory, encrypt each file, and remove the links to the
unencrypted files:

$ find newdir -type f -exec gpg -e '{}' \; -exec rm '{}' \;

Back up the new directory with the encrypted data:

$ tar c newdir

Discussion

Method 1 produces a backup that may be considered fragile: one big encrypted
file. If part of the backup gets corrupted, you might be unable to decrypt any
of it.

Method 2 avoids this problem. The cp -l option creates
hard links, which can only be used within a single filesystem.
If you want the encrypted files on a separate filesystem, use symbolic links instead:

Note that a full, absolute pathname must be used for the original directory
in this case.

gpg does not preserve the owner, group, permissions, or
modification times of the files. To retain this information in your backups,
copy the attributes from the original files to the encrypted files, before the
links to the original files are deleted:

Method 2 and the CD-ROM variant of method 1 use disk space (at least
temporarily) for the encrypted files.

See Also

gpg(1), tar(1), find(1), cdrecord(1).

Recipe 9.35: Combining Log Files

Author's note: Each system log file in /var/log contains different information about your running Linux system. This recipe from Chapter 9 on "Testing and Monitoring" shows how to merge multiple log files, keeping the lines in sorted order by timestamp, which is trickier than you might think.

Problem

You want to merge a collection of log files into a single, chronological log
file.

Discussion

The system logger automatically prepends a timestamp to each message, like
this:

Feb 21 12:34:56 buster kernel: device eth0 entered promiscuous mode

To merge log files, sort each one by its timestamp entries,
using the first three fields (month, date, and time) as keys.

A complication arises because the system logger inserts "repetition messages"
to conserve log file space:

Feb 21 12:48:16 buster last message repeated 7923 times

The timestamp for the repetition message is often later than the last
message. It would be terribly misleading if possibly unrelated messages from
other log files were merged between the last message and its associated
repetition message.

To avoid this, our Perl script glues together the last message with a
subsequent repetition message (if present), inserting a null character between
them: this is reliable because the system logger never writes null characters to
log files. The script writes out the final line before the end of each file and
then forgets the last line, to avoid any possibility of confusion if the next
file happens to start with an unrelated repetition message.

The sort command sees these null-glued
combinations as single lines, and keeps them together as the files are merged.
The null characters are translated back to newlines after the files are sorted,
to split the combinations back into separate lines.

We use sort -s to avoid sorting entire lines if all of
the keys are equal: this preserves the original order of messages with the same
timestamp, at least within each original log file.

If you have configured the system logger to write messages to multiple log
files, then you may wish to remove duplicates as you merge. This can be done by
using sort -u instead of -s, and
adding an extra sort key -k 4 to compare the message
contents. There is a drawback, however: messages could be rearranged if they
have the same timestamp. All of the issues related to sort
-s and -u are consequences of the one-second resolution
of the timestamps used by the system logger.

We'll note a few other pitfalls related to timestamps. The system logger does
not record the year, so if your log files cross a year boundary, then you will
need to merge the log files for each year separately, and concatenate the
results. Similarly, the system logger writes timestamps using the local time
zone, so you should avoid merging log files that cross a daylight saving time
boundary, when the timestamps can go backward. Again, split the log files on
either side of the discontinuity, merge separately, and then concatenate.

If your system logger is configured to receive messages from other machines,
note that the timestamps are generated on the machine where the log files are
stored. This allows consistent sorting of messages even from machines in
different time zones.

See Also

sort(1).

Be sure to check back here next week for recipes from Linux Security Cookbook on how to restrict access to network services by time of day, and on how to use sudo to permit read-only access to a shared file.