The importance of the GPG/PGP key expiration date

Most people set their GPG keys to never expire. There is no problem with that. Unless they lose the private key or it gets stolen or they just forget its passphrase. In such a case, the public key, which has probably been published to several key servers around the world and retrieved by an arbitrary number of other people, is practically useless and, apart from removing it from some of the keyservers, they can do absolutely nothing else about it, unless, of course, they had previously generated a revocation certificate for the public key and they still have access to this certificate. In those not so rare cases that the revocation certificate is not available, the only way to let those who have already grabbed a copy of the public key know that they should not use that key any more is by notifying them directly, which is not always possible since the actual number of the holders of that specific public key is not known.

Setting an expiration date on your keys is a very good security measure. It lets the holders of the public key know the key’s end-of-life date. On the other hand, you can always extend the key’s expiration date and send the updated key to the key servers. When others find out that your public key has expired, the very first thing they do will be to refresh it from a key server, in which case they’ll retrieve your updated public key. Even if you lose the private key or forget the passphrase or even lose the revocation certificate too, a time will come that the public key will expire, which indicates that it is invalid and should not be trusted any more. This is important.

Change the expiration date of a GPG key

In this section I describe how to extend or reset a key’s expiration date using gpg from the command line. There are probably several graphical front-ends out there that might simplify this procedure, but, since graphical frontends are not usually cross-platform, I choose to use the command-line gpg utility. So, here is how we do it.

First of all, you have to know the ID of the key you need to edit:

$ gpg --list-keys
pub   1024D/B989893B 2007-03-07 [expired: 2009-12-31]
uid                  George Notaras <gnotaras@example.org>
sub   4096g/320D81EE 2007-03-07 [expired: 2009-12-31]

The ID in question is B989893B, so we edit the key with that ID:

$ gpg --edit-key B989893B

You should have entered the gpg shell by now. To see a list of the available commands you can always invoke the help command.

First of all, list the keys so you know what you are editing:

gpg> list
pub  1024D/B989893B  created: 2007-03-07  expired: 2009-12-31  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

By default, no subkey (sub) is selected, which means that we work on the primary key (pub). It is possible to select the subkey you will be working on by invoking the key command followed by the number (index) of the subkey you wish to select. If no arguments or index ’0′ is passed to the key command, any subkey is deselected and you will be working on the primary key.

gpg> key 0
pub  1024D/B989893B  created: 2007-03-07  expired: 2009-12-31  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Now use the expire command to set an expiration time for the primary key.

gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y
Key expires at 10/28/12 03:51:07
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "George Notaras <gnotaras@example.org>"
1024-bit DSA key, ID XXXXXXXX, created 2007-03-07
pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

The output above indicates that the expiration date of the primary public key has been set to 2012-10-28. Note that, the expiration date has also been changed on your primary private key of the keypair. You can issue the toggle command to verify the private key’s expiration date. Don’t worry about that. It is the private subkeys, which never expire, that are actually used when you decrypt and sign data. Read more on this in a special note at the end of this section. For now, just issue the toggle command once again to return to public key editing mode.

In this example case, there is one public subkey on which we need to set a new expiration date. That’s key number 1. We select that with the key command:

gpg> key 1
pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub*  4096g/320D81EE  created: 2007-03-07  expired: 2009-12-31  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Set a new expiration time on that subkey by invoking the expire command:

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 2y
Key expires at 10/28/12 03:02:43
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "George Notaras <gnotaras@example.org>"
1024-bit DSA key, ID XXXXXXXX, created 2007-03-07
pub  1024D/B989893B  created: 2007-03-07  expires: 2012-10-28  usage: SCA
                     trust: ultimate       validity: ultimate
sub* 4096g/320D81EE  created: 2007-03-07  expires: 2012-10-28  usage: E
[ ultimate] (1). George Notaras <gnotaras@example.org>

Now it seems that everything is set up fine. You have changed the expiration dates of your keys. You can always use the list command to list the keys. Use the toggle command to toggle between public and private key editing mode.

As a final step you need to save your changes. Invoke the save command.

gpg> save

So, now you can update the public key that is stored on the various keyservers. To achieve this use the following command. In this example, the keyserver at pgp.mit.edu is used.

$ gpg --keyserver pgp.mit.edu --send-keys B989893B
gpg: sending key B989893B to hkp server pgp.mit.edu

Enjoy.

Important Note

If you tried to use the expire command in private key editing mode, you would notice that it is not possible to change the expiration date of any subkeys in this mode. Actually, the private subkeys never expire. Although, I haven’t investigated this, common sense indicates that, since private subkeys are used to sign and decrypt data and that they are not meant to be distributed, it wouldn’t make any sense if they expired.

Theoritically speaking, the owner of an expired private key should still have the ability to decrypt data and also be able to sign data, even if all public subkeys of the current keypair have expired, since it is always possible to reset the expiration date on the currently expired public keys.

As I mentioned earlier, I haven’t investigated this, but I think that non-expiring private keys make a lot of sense.

Final Thoughts

This article described in detail how to change the expiration date of GPG/PGP keys. This should be a standard key maintenance procedure if you set an expiration date on your keys.

Setting an expiration date on your keys is not mandatory as long as you have taken other measures to protect the private key and the public key’s revocation certificate by backing it up and storing it at another location. But, in general, it is a good habit as explained in this article’s introduction. I by no means am a GPG/PGP expert. I wrote this guide because I realized that most people do not set an expiration date on their keys because they do not know how to change it and extend the key’s life or because they have not realized the importance of the expiration date or simply because they do not care. I hope you find this tutorial useful and start setting an expiration date on your keys from now on.

Related Articles

• Be your own Certificate Authority (CA)
• Setup the SSH server to use keys for authentication
• A change of plans regarding a web-based VCS manager

Introduction

Searching the web for mod_gnutls binary distribution packages or information on how to set it up returned very few relevant results. This was a surprise, as, at this moment, the only implementation that supports SNI is mod_gnutls. So, I decided to write a tutorial on how to set things up for a test. I hope you find it useful.

The test that is described in this guide includes:

1. The compilation of the mod_gnutls module.
2. The generation of SSL certificates.
3. The configuration of the SSL-enabled name-based virtual hosts.

This test was performed on a server that runs Fedora 7.

Installation

In order to compile mod_gnutls, you will need the development tools for Fedora:

# yum groupinstall "Development Tools"

Install the mod_gnutls dependencies:

# yum install httpd-devel gnutls-devel

As an unprivileged user, download the mod_gnutls distribution and compile it.

$ wget http://www.outoforder.cc/downloads/mod_gnutls/mod_gnutls-0.2.0.tar.bz2
$ tar -xjvf mod_gnutls-0.2.0.tar.bz2
$ cd mod_gnutls-0.2.0
$ ./configure --prefix=/usr
$ make

Do not use the ‘make install‘ script, but perform the installation manually – it is only one library.

As root, copy libmod_gnutls.so to the directory that holds the Apache modules (usually /usr/lib/httpd/modules) and rename it to mod_gnutls.so for consistency:

# cp mod_gnutls-0.2.0/src/.libs/libmod_gnutls.so /usr/lib/httpd/modules/mod_gnutls.so

During the compilation, two keys, dhfile and rsafile, have been generated in the mod_gnutls-0.2.0/data/ directory. It is absolutely important to copy these files in httpd’s configuration directory (usually /etc/httpd/conf/), otherwise mod_gnutls will never work. This is undocumented, and I found out about it after some trial&error.

As root:

# cp mod_gnutls-0.2.0/data/{dh,rsa}file /etc/httpd/conf/

Installation is complete.

SSL certificates

In this test installation, two virtual hosts will be used. Thus, two SSL certificates will be required. Please read my article on how to generate SSL certificates for your servers, as this information is beyond the scope of this document. Alternatively, you may use a ready-made script which will create those certificates for you quickly. Such scripts are shipped will almost all Linux distributions. Please consult your distribution’s documentation for more information.

HTTPd Configuration

The configuration of the Apache web server includes two phases:

1. The configuration of the main server.
2. The configuration of the virtual hosts.

In the following instructions, some brief notes about what each directive does is included. For more detailed information, please consult the mod_gnutls documentation.

Main Server Configuration

This includes setting some general mod_gnutls options, which will be inherited by all virtual hosts.

But, first of all, httpd needs to be set to listen on port 443 (in addition to port 80). Instead of specifying the SSL port only (Listen 443) which will lead httpd to listen to all the available network interfaces, you may specify the exact network interface on which the server will listen. For example:

Listen 192.168.0.1:443

Next, load mod_gnutls:

LoadModule gnutls_module modules/mod_gnutls.so

Add some MIME-types for downloading Certificates and CRLs from your web sites (taken from the mod_ssl configuration):

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

It is suggested that you use a session cache for mod_gnutls. This will increase its performance. In this example, the dbm cache type is used. This cache type requires a directory where mod_gnutls will actually save SSL session data. So, creating a directory for this purpose and giving ownership to the user that runs Apache (usually apache or www-data) is needed. Assuming that the Apache user is apache, as root issue the commands:

# mkdir -m 0700 /var/cache/mod_gnutls_cache
# chown apache:apache /var/cache/mod_gnutls_cache

Now, back to the Apache configuration. The following directive sets the dbm SSL Session Cache for mod_gnutls:

GnuTLSCache dbm "/var/cache/mod_gnutls_cache"

Set a timeout for the SSL Session Cache entries. Usually, this is set to 300 seconds:

GnuTLSCacheTimeout 300

Finally, specify that on the 192.168.0.1:443 interface and port there will be name-based virtual hosts; that is vhosts that share the specified interface and port:

NameVirtualHost 192.168.0.1:443

Virtual Host Configuration

The example virtual hosts are: v1.example.org and v2.example.org. It is assumed that two SSL certificates with the canonical name (CN) correctly set to each of the aforementioned vhost domains have been generated.

In the following vhost configs, only the absolutely required directives have been used. The rest of the options are inherited from the main server.

<VirtualHost 192.168.0.1:443>
    ServerName v1.example.org:443
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/pki_custom/certs/v1.example.org.crt
    GnuTLSKeyFile /etc/pki_custom/private/v1.example.org.key
    DocumentRoot "/var/www/v1/public_html"
</VirtualHost>
<VirtualHost 192.168.0.1:443>
    ServerName v2.example.org:443
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/pki_custom/certs/v2.example.org.crt
    GnuTLSKeyFile /etc/pki_custom/private/v2.example.org.key
    DocumentRoot "/var/www/v2/public_html"
</VirtualHost>

Testing the setup

Having finished with the configuration, review the changes, restart the server and check the error logs for any errors.

Use a web browser to visit each of the virtual hosts by using the HTTPS protocol:

https://v1.example.org/
https://v2.example.org/

Until now, the web server did not support the SNI TLS extension. Therefore, when visiting the v2.example.org virtual host, you would see two warnings in your browser. The first one would be because the vhost’s certificate has not been issued by a trusted Certificate Authority – this is normal as it was you who issued that certificate – and the other one because on a server without SNI support it is actually the V1 vhost’s certificate that is used when visiting V2 vhost over https. Remember the limitation with SSL and name-based virtual hosts?

With mod_gnutls, the server supports the SNI TLS extension. Although the virtual hosts are name-based, no matter which one you visit, the relevant certificate for each vhost is used and the only warning you see is the one about the certificates being self-signed. You can get rid of these by purchasing a certificate that is issued by a trusted Certificate Authority.

Conclusion

mod_gnutls works. Actually, it was a real pleasure to see SNI work!

It is important to note though that mod_gnutls is still in experimental phase. Therefore, performance issues should be considered as normal when using it.

At the moment of writing, my server uses Fedora 7 as an operating system. As I haven’t upgraded my desktop to F7 yet and my server does not have any development tools installed, I compiled mod_gnutls on a Fedora 6 system and used it on Fedora 7. I do not know if that was the reason – and I did not have the necessary free time to investigate – or anything else, but, during the use of mod_gnutls, my server’s load average increased significantly.

I will test mod_gnutls again soon and post the new results, if they are different than the ones I present in this article. I highly recommend that you try it, as it is currently the only way to easily achieve SSL-enabled name-based virtual hosts using the SNI TLS extension. Note, that this extension will be supported by openssl 0.99, so the moment that SNI goes mainstream and such a setup becomes easy and cheap to implement with any Linux distribution is close.

One last thing that has not been mentioned at all is about SNI support in web browsers. Currently, with the exception of Safari (this is unconfirmed, please correct me if I am wrong), the latest versions of all major web browsers, Firefox and other Mozilla-based browsers, Internet Explorer, Opera, support SNI.

Related Articles

• mod_gnutls binary for Apache
• Assign Virtual IPs to your NIC
• Speed up Apache by including htaccess files into httpd.conf
• How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability
• Use mod_deflate to Compress Web Content delivered by Apache

What is a tunnel

Assume that an SSH and a VNC server are up and running on the machine remote.example.org. The remote firewall does not allow direct connections to the VNC port – assume that this is TCP port 5901 – from the network, which is generally a good idea. In this case, we will connect to the remote VNC service from the local workstation through the remote SSH server, by using a feature of the SSH protocol, called local port forwarding or, simply, tunneling.

Such a tunnel can be initialized from the local workstation with the following:

[me@local]$ ssh -L 25901:127.0.0.1:5901 me@remote.example.org

When executed, the above statement has the following results:

1. forwards the local port 25901 on the local workstation to port 5901 on the remote machine through the ssh connection. The port 25901 is an example and it could be any other available TCP port on the local machine. The result is that any request made on the local port 25901 is transfered to port 5901 on the remote machine through the encrypted SSH connection.
2. connects us to the remote SSH server and logs our remote user “me” in.

In order to connect to the remote VNC service through that tunnel, it is required to keep the connection to the ssh server open and, from another local terminal, connect to the local port 25901 with the vnc client:

[me@local]$ vncviewer 127.0.0.1:25901:1

By closing the vnc client and by logging out of the remote shell, the tunnel is destroyed too.

A better way

The previous method is too far from being convenient in the everyday use. Things could be a lot better if we could just create the SSH tunnel and launch vncviewer in one line of code. This can be achieved by using the -f and -N flags when connecting to the remote SSH server:

[me@local]$ ssh -f -N -L 25901:127.0.0.1:5901 me@remote.example.org; \
              vncviewer 127.0.0.1:25901:1

The -f switch instructs the ssh client to fork the ssh session to the background. Therefore, we remain at our local terminal’s prompt, from where we can execute more commands on our local machine. In this case, with a single line of code, we created the tunnel and executed vncviewer. However, the -f switch has one requirement. It cannot be used on its own. It needs to be accompanied either by the -N switch or we have to execute a specific command on the remote machine.

In this case, the -f -N combination keeps the tunnel up and running in the background, but the drawback is that it runs forever, requiring us to explicitly kill the ssh process if the tunnel is not needed any more. Even if we close vncviewer, the following command confirms that the tunnel is still running, which was actually expected:

[me@local]$ ps ax | grep ssh | grep -v grep

The best way – Tunnels that auto-close

As it has been mentioned previously, instead of using the -f -N switch combination, we can just use -f alone, but also execute a command on the remote machine. But, which command should be executed, since we only need to initialize a tunnel?

This is when sleep can be the most useful command of all! In this particular situation, sleep has two advantages:

1. it does nothing, so no resources are consumed
2. the user can specify for how long it will be executed

How these help in auto-closing the ssh tunnel is explained below.

We start the ssh session in the background, while executing the sleep command for 10 seconds on the remote machine. The number of seconds is not crucial. At the same time, we execute vncviewer exactly as before:

[me@local]$ ssh -f -L 25901:127.0.0.1:5901 me@remote.example.org sleep 10; \
              vncviewer 127.0.0.1:25901:1

In this case, the ssh client is instructed to fork the ssh session to the background (-f), create the tunnel (-L 25901:127.0.0.1:5901) and execute the sleep command on the remote server for 10 seconds (sleep 10).

The difference between this method and the previous one (-N switch), basically, is that in this case the ssh client’s primary goal is not to create the tunnel, but rather to execute the sleep command for 10 seconds. The creation of the tunnel is some kind of side-effect, a secondary goal. If vncviewer was not used, the ssh client would exit after the 10 sec period, as it would have no more jobs to do, destroying the tunnel at the same time.

During the execution of the sleep command, if another process, vncviewer in this case, starts using that tunnel and keeps it occupied beyond the 10 sec period, then, even if the ssh client finishes its remote job (execution of sleep), it cannot exit because another process occupies the tunnel. In other words, the ssh client cannot destroy the tunnel because it would have to kill vncviewer as well. When vncviewer stops using the tunnel, then the ssh client exits too, as it has already accomplished its goal.

This way, no ssh processes are left running in the background.

Further Enhancements

Although this is not a general article about the SSH protocol, the following ssh client switches may prove useful in some situations.

The -C switch may be used in order to apply compression to the transfered data between the local workstation and the remote server. This will save some bandwidth, but will increase the cpu load.

Also, a specific encryption algorithm may be specified with the -c option. The blowfish cipher is a rather good choice, which offers good encryption and low cpu utilization.

[me@local]$ ssh -C -c blowfish -f -L 25901:127.0.0.1:5901 me@remote.example.org sleep 10; \
              vncviewer 127.0.0.1:25901:1

Finally, the -v flag can also be used for verbose output.

Related Articles

• SSH Tunnels Headaches
• Set up the VNC Server in Fedora
• Netcat – a couple of useful examples
• Partition images with Partimage and Partimaged
• Setup the SSH server to use keys for authentication

There are many different methods to encrypt data using various encryption algorithms (ciphers). In this document I describe in short how to encrypt a device with one of the most contemporary methods, using dm-crypt and LUKS. Actually, devices cannot be encrypted. It’s the block devices which are volumes that can be. This means that you can encrypt a hard disk partition, a ZIP disk, a usb flash stick, or even a volume within a file.

dm-crypt is a device mapper that uses the 2.6 kernel’s cryptoapi. We will not use dm-crypt directly to setup the block device mappings because of its complexity, but instead we’ll use an enhanced version of a program called cryptsetup, which has the LUKS extension enabled. The reason for using LUKS (Linux Unified Key Setup) is that it uses a partition header to store the encryption-setup information, so, in contrast to other existing methods, the user can:

• change the encrypted volume’s passphrase without having to re-encrypt the data
• have multiple passphrases for the same data
• transport or migrate data on different systems

The most important thing though is that all this convenience does not have an impact on data security, meaning that data is still very safe. Well, this is LUKS. Win32 compatibility is not yet possible, but will be in the near future through TrueCrypt.

Prerequisites

A Linux 2.6 kernel with device mapper and dm-crypt support is needed. On Fedora Core 4 systems you really don’t have to do anything as the kernel has device mapper and dm-crypt enabled as modules (dm-mod and dm-crypt respectively). The modules are loaded automatically when the system needs them.

Before reading any further, you must be sure that you know the exact device node you are going to encrypt. This is no joke, as you can lose your data, by a simple and fool mistake. So, take note!

Furthermore, you need to install cryptsetup-luks package and util-linux package. We will need the latter for encrypting a filesystem within a file, but this is probably already installed.

Encrypting a volume

In this section I will encrypt a ZIP disk. The very same process can be used for any block device that is a volume, meaning that it can be formatted with a mountable filesystem. So, you can encrypt a hard disk partition, a USB stick, a Compact Flash card etc.

First of all, be sure that you know your volume’s exact device node in /dev. If you use multiple hotplugable devices, which you connect to your machine in a random order, you should consider writing some UDEV rules, so that you know which node corresponds with a certain actual device. You can read my blog post on that. A simple mistake can lead to loss of data. I have setup UDEV in a such way, that every time I connect my USB ZIP drive and insert a disk, a symlink to the disk’s node is created in a directory /dev/mydev/. So, I can reach the ZIP diskette by directing the commands to the symlink /dev/mydev/zipdisk.

If your volume is already mounted, unmount it before proceeding. Mine is, so I run:

# umount /dev/mydev/zipdisk

Fill the disk with random data

Filling the disk with random data before encrypting is a good habit and it strengthens security as well. If you don’t want to do so, you can simply skip this step. This process is CPU intensive and the time it takes depends on the available CPU horsepower, the size of the partition and the speed it can be written. It can be many hours, even days, for very large hard disk partitions. The worst thing is that there is no progress indicator, so you just wait for it to finish. I run this:

# dd if=/dev/urandom of=/dev/mydev/zipdisk

Substitute /dev/mydev/zipdisk with the path to your device node. In my case, it took my USB 1.1 ZIP drive 10 whole minutes to fill an 100MB ZIP disk. Well, it’s not the fastest thing in the world, but I still like it.

Create the LUKS partition

Now, I will create a LUKS partition on the ZIP disk. As root I run:

# cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat /dev/mydev/zipdisk

If you use a kernel older than 2.6.10, do not include the –cipher option. The default AES with 256-bit key is absolutely fine. Cryptsetup will ask for a passphrase twice. What this does is the initialization of the LUKS partition.

Set up the device mapping

In order to use this partition, a device mapping must be set up between the physical partition on the ZIP diskette and a new virtual block device, which can then be mounted. I call it virtual because it’s just a layer between the physical ZIP disk and the system. Writes to this virtual block device will be encrypted and reads decrypted. To create the device mapping as root:

# cryptsetup luksOpen /dev/mydev/zipdisk encr-zipdisk

encr-zipdisk is just a name for the new block device that is created in /dev/mapper/. After creating a filesystem on it, this virtual block device can be mounted and used as normal.

Create a filesystem on the new block device

You can create any file system you like on the new volume. For my ZIP diskette, an MSDOS FAT16 filesystem is more than enough, so I run as root:

# mkdosfs -v -F 16 -n "ENCR1" /dev/mapper/encr-zipdisk

What worths mentioning is that you create the filesystem on the virtual volume, /dev/mapper/encr-zipdisk in my case, and not the physical one.

Mount the new volume

Now I can mount the volume as normal. For example:

# mount -t vfat -o rw /dev/mapper/encr-zipdisk /mnt/tmp/

An fstab entry with all the proper mount options could simplify mounting. All data that is written to the disk gets encrypted.

Unmounting

Before removing the disk from the drive, I have to unmount it:

# umount /mnt/tmp/

And then delete the device mapping as root:

# cryptsetup luksClose encr-zipdisk

This removes the association and I normally can eject the ZIP disk.

In short

Just a review of the procedure to mount and unmount the disk, considering that a proper fstab entry has been added.

To mount:

# cryptsetup luksOpen /dev/mydev/zipdisk encr-zipdisk
# mount /dev/mapper/encr-zipdisk

To unmount:

# umount /dev/mapper/encr-zipdisk
# cryptsetup luksClose encr-zipdisk

Pretty fast and easy.

Encrypt a filesystem within a file

In order to use LUKS to encrypt a filesystem that is contained in a file, you actually have to follow the same steps as when encrypting a physical partition, plus two. These include:

• The creation of a file that will contain the encrypted partition
• Set up an association between this file and a free loop device, so that it can be used by cryptsetup as a block device. At the moment, cryptsetup cannot use a file as a block device directly. That’s why this step is needed.

So, let’s create the file. The following command creates an 100MB file, named "container1", which is full of random data:

dd if=/dev/urandom of=container1 bs=1024 count=100000

To create a mapping between this file and a free loop device, we’ll use losetup (part of util-linux). Check which loop device is free in your system with the command:

losetup -f

For me it was /dev/loop0. So, I map the "container1" file to /dev/loop0. As root:

# losetup /dev/loop0 /path/to/container1

From now on, the steps are exactly the same as before. We just use /dev/loop0 instead of the ZIP disk:

# cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat /dev/loop0
# cryptsetup luksOpen /dev/loop0 encr-container1
# mkfs.ext3 /dev/mapper/encr-container1
# mount -t ext3 -o rw,defaults /dev/mapper/encr-container1 /mnt/tmp/

We can now copy some files to our encrypted partition, like on a regular disk partition. We unmount it and delete the device mappings with the following commands:

# umount /mnt/tmp/
# cryptsetup luksClose encr-container1
# losetup -d /dev/loop0

So, to mount a LUKS encrypted filesystem within a file you need to create two device mappings before you mount it for use. Of course some automation can be achieved using scripts, but you will still have to supply the passphrase in order to use the encrypted partitions.

Further Reading

Apart from reading the cryptsetup and losetup man pages, you can check the following URLs for more info:

1. The dm-crypt homepage
2. The dm-crypt wiki
3. A HOWTO about encrypting a USB HDD
4. The LUKS homepage

Related Articles

• TrueCrypt on 2.6.18 kernels
• A different approach…HAL
• UDEV
• Packet Writing on CDRW and DVDRW media
• Always use a block device label or its UUID in fstab

Prerequisites

The package openssl should be installed in the machine you will use to manage your certificates or create the certificate requests.

First things first…

The openssl package comes with some scripts that can help you create your server certificates fast, but here I will describe how to set things up from scratch in a new directory, so that you can customize things later if you like or delete everything without touching openssl’s or the system’s default files. This article is based on a Fedora installation, but will do for all distributions.

Creating the necessary directories

First of all we will create a directory tree where all certificate stuff will be kept. Fedora’s default directory is /etc/pki/tls/. So, as root, we create our own directories:

# mkdir -m 0755 /etc/pki_jungle

And then we create our CA’s directory tree:

# mkdir -m 0755 \
     /etc/pki_jungle/myCA \
     /etc/pki_jungle/myCA/private \
     /etc/pki_jungle/myCA/certs \
     /etc/pki_jungle/myCA/newcerts \
     /etc/pki_jungle/myCA/crl

• myCA is our Certificate Authority’s directory.
• myCA/certs directory is where our server certificates will be placed.
• myCA/newcerts directory is where openssl puts the created certificates in PEM (unencrypted) format and in the form cert_serial_number.pem (eg 07.pem). Openssl needs this directory, so we create it.
• myCA/crl is where our certificate revokation list is placed.
• myCA/private is the directory where our private keys are placed. Be sure that you set restrictive permissions to all your private keys so that they can be read only by root, or the user with whose priviledges a server runs. If anyone steals your private keys, then things get really bad.

Initial openssl configuration

We are going to copy the default openssl configuration file (openssl.cnf) to our CA’s directory. In Fedora, this file exists in /etc/pki/tls. So, we copy it to our CA’s dir and name it openssl.my.cnf. As root:

# cp /etc/pki/tls/openssl.cnf /etc/pki_jungle/myCA/openssl.my.cnf

This file does not need to be world readable, so we change its attributes:

# chmod 0600 /etc/pki_jungle/myCA/openssl.my.cnf

We also need to create two other files. This file serves as a database for openssl:

# touch /etc/pki_jungle/myCA/index.txt

The following file contains the next certificate’s serial number. Since we have not created any certificates yet, we set it to "01":

# echo '01' > /etc/pki_jungle/myCA/serial

Things to remember

Here is a small legend with file extensions we will use for the created files and their meaning. All files that will be created will have one of these extensions:

• KEY – Private key (Restrictive permissions should be set on this)
• CSR – Certificate Request (This will be signed by our CA in order to create the server certificates. Afterwards it is not needed and can be deleted)
• CRT – Certificate (This can be publicly distributed)
• PEM – We will use this extension for files that contain both the Key and the server Certificate (Some servers need this). Permissions should be restrictive on these files.
• CRL – Certificate Revokation List (This can be publicly distributed)

Create the CA Certificate and Key

Now, that all initial configuration is done, we may create a self-signed certificate, that will be used as our CA’s certificate. In other words, we will use this to sign other certificate requests.

Change to our CA’s directory. This is where we should issue all the openssl commands because here is our openssl’s configuration file (openssl.my.cnf). As root:

# cd /etc/pki_jungle/myCA/

And then create your CA’s Certificate and Private Key. As root:

# openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825

This creates a self-signed certificate with the default CA extensions which is valid for 5 years. You will be prompted for a passphrase for your CA’s private key. Be sure that you set a strong passphrase. Then you will need to provide some info about your CA. Fill in whatever you like. Here is an example:

Country Name (2 letter code) [GB]:GR
State or Province Name (full name) [Berkshire]:Greece
Locality Name (eg, city) [Newbury]:Thessaloniki
Organization Name (eg, company) [My Company Ltd]:My Network
Organizational Unit Name (eg, section) []:My Certificate Authority
Common Name (eg, your name or your server's hostname) []:server.example.com
Email Address []:whatever@server.example.com

Two files are created:

• certs/myca.crt – This is your CA’s certificate and can be publicly available and of course world readable.
• private/myca.key – This is your CA’s private key. Although it is protected with a passphrase you should restrict access to it, so that only root can read it:

  # chmod 0400 /etc/pki_jungle/myCA/private/myca.key

More openssl configuration (mandatory)

Because we use a custom directory for our certificates’ management, some modifications to /etc/pki_jungle/myCA/openssl.my.cnf are necessary. Open it in your favourite text editor as root and find the following part (around line 35):

[ CA_default ]
dir     = ../../CA      # Where everything is kept
certs       = $dir/certs        # Where the issued certs are kept
crl_dir     = $dir/crl      # Where the issued crl are kept
database    = $dir/index.txt    # database index file.
#unique_subject = no            # Set to 'no' to allow creation of
                    # several ctificates with same subject.
new_certs_dir   = $dir/newcerts     # default place for new certs.
certificate = $dir/cacert.pem   # The CA certificate
serial      = $dir/serial       # The current serial number
#crlnumber  = $dir/crlnumber    # the current crl number must be
                    # commented out to leave a V1 CRL
crl     = $dir/crl.pem      # The current CRL
private_key = $dir/private/cakey.pem    # The private key
RANDFILE    = $dir/private/.rand    # private random number file
x509_extensions = usr_cert      # The extentions to add to the cert

You should modify the following settings in order to coform to our custom directory and our custom CA key and certificate:

[ CA_default ]
dir     = .                # <--CHANGE THIS
certs       = $dir/certs
crl_dir     = $dir/crl
database    = $dir/index.txt
#unique_subject = no
new_certs_dir   = $dir/newcerts
certificate = $dir/certs/myca.crt   # <--CHANGE THIS
serial      = $dir/serial
#crlnumber  = $dir/crlnumber
crl     = $dir/crl.pem
private_key = $dir/private/myca.key    # <--CHANGE THIS
RANDFILE    = $dir/private/.rand
x509_extensions = usr_cert

Create a Server certificate

Further openssl.my.cnf file’s customization is possible, so that we define our policy for certificate creation and signing or define our desired extensions for the new certificates. I may add this info to a future version of this document. It’s easy though, just try to familiarize yourself with the openssl.cnf’s structure and you’ll figure it out.

Anyway, the certificates we are going to create, without customizing openssl.my.cnf any further, are general purpose certificates and their usage in not restricted to server authentication only. One thing that you should take a note of is that the private keys will not be protected by a passphrase, so that when the services are restarted they do not ask for a passphrase. This means that you should set restrictive permissions on the private keys, so that only root or the user under whose priviledges a server runs can read these files.

Generate a Certificate Request

First, we change to our CA’s directory:

# cd /etc/pki_jungle/myCA/

Then we create the certificate request:

# openssl req -config openssl.my.cnf -new -nodes -keyout private/server.key -out server.csr -days 365

The -nodes option is needed so that the private key is not protected with a passphrase. If you do not intend to use the certificate for server authentication, you should not include it in the above command.
You can customize the number of days you want this certificate to be valid for.

You will be prompted for the certificate’s info. Here is an example:

Country Name (2 letter code) [GB]:GR
State or Province Name (full name) [Berkshire]:Greece
Locality Name (eg, city) [Newbury]:Thessaloniki
Organization Name (eg, company) [My Company Ltd]:My Network
Organizational Unit Name (eg, section) []:My Web Server
Common Name (eg, your name or your server's hostname) []:www.server.example.com
Email Address []:whatever@server.example.com

The Common Name (CN) is the info that uniquely distinguishes your service, so be sure that you type it correctly.
When prompted for some extra attributes (challenge password, optional company name) just hit the [Enter] key.

Two files are created:

• server.csr – this is the certificate request.
• private/server.key – this is the private key, which is not protected with a passphrase.

Set restrictive permissions on the private key. Only root or the user that is used to run the server should be able to read it. For example:

# chown root.root /etc/pki_jungle/myCA/private/server.key
# chmod 0400 /etc/pki_jungle/myCA/private/server.key

Or:

# chown root.apache /etc/pki_jungle/myCA/private/server.key
# chmod 0440 /etc/pki_jungle/myCA/private/server.key

Sign the Certificate Request

Now we are going to sign the certificate request and generate the server’s certificate.

First, we change to our CA’s directory:

# cd /etc/pki_jungle/myCA/

Then we sign the certificate request:

# openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr

You will need to supply the CA’s private key in order to sign the request. You can check the openssl.my.cnf file about what policy_anything means. In short, the fields about the Country, State or City is not required to match those of your CA’s certificate.

After all this is done two new files are created:

• certs/server.crt – this is the server’s certificate, which can be made available publicly.
• newcerts/01.pem – This is exactly the same certificate, but with the certificate’s serial number as a filename. It is not needed.

You can now delete the certificate request (server.csr). It’s no longer needed:

# rm -f /etc/pki_jungle/myCA/server.csr

Verify the certificate

You can see the certificate’s info with the following:

# openssl x509 -subject -issuer -enddate -noout -in /etc/pki_jungle/myCA/certs/server.crt

Or the following:

# openssl x509 -in certs/server.crt -noout -text

And verify that the certificate is valid for server authentication with the following:

# openssl verify -purpose sslserver -CAfile /etc/pki_jungle/myCA/certs/myca.crt /etc/pki_jungle/myCA/certs/server.crt

Server certificate and key in one file

Some servers, for example vsftpd, require that both the private key and the certificate exist in the same file. In a situation like that just do the following:

# cat certs/server.crt private/server.key > private/server-key-cert.pem

You should restrict access to the final file and delete server.crt and server.key since thay are no longer needed.

# chown root.root private/server-key-cert.pem
# chmod 0400 private/server-key-cert.pem
# rm -f certs/server.crt
# rm -f private/server.key

Revoke a Server Certificate

If you do not want a certificate to be valid any more, you have to revoke it. This is done with the command:

# openssl ca -config openssl.my.cnf -revoke certs/server.crt

Then you should generate a new CRL (Certificate Revokation List):

# openssl ca -config openssl.my.cnf -gencrl -out crl/myca.crl

The CRL file is crl/myca.crl.

Distribute your certificates and CRL

Your CA’s certificate and your servers’ certificates should be distributed to those who trust you so they can import them in their client software (web browsers, ftp clients, email clients etc). The CRL should also be published.

Further Reading

As I have said from the beginning, this document is just a summary of what I have read. Here are some useful links that will get you started:

1. The SSL Certificates HOWTO
2. The OpenSSL Documentation
3. The openssl.cnf documentation
4. OpenSSL Certificate Authority Setup

Related Articles

• Root Certificate Programs – The root of all trust
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Free Personal Email Certificates Program discontinued by Thawte
• Setup the SSH server to use keys for authentication
• Set up the VNC Server in Fedora

This article describes in brief how to configure VNC server instances for one or multiple users on a remote machine, how to use VNC to start graphical applications on boot and finally how to enhance security by connecting to the server through encrypted SSH tunnels.

Prerequisites

A user account should exist on the remote machine.
The RPM packages vnc-server and vnc should be installed on the remote machine and your workstation respectively.

Setting up the server

I assume that we have setup a remote user account, named "leopard" and we want to start an X session through VNC for this user.

In Fedora Core or Red Hat based distros in general, all we have to do is define the VNC server instances in /etc/sysconfig/vncservers. These will be started by the vncserver initscript. This has to be done as root. Edit this file so that it contains the following:

VNCSERVERS="3:leopard"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

With these we define that a vnc server instance should be started as user leopard on display 3 and we also set some options for this server such as resolution and color depth. Each VNC server instance listens on port 5900 plus the display number on which the server runs. In our case, leopard’s vnc server would listen on port 5903.

For multiple vnc instances /etc/sysconfig/vncservers would look like this:

VNCSERVERS="1:tiger 2:albatros 3:leopard"
VNCSERVERARGS[1]="-geometry 1024x768 -depth 16"
VNCSERVERARGS[2]="-geometry 800x600 -depth 8"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

These would listen on ports 5901, 5902, 5903 respectively.

User Configuration

There is one more thing that needs to be done on the remote machine. User leopard’s vnc password needs to be set. So, as user leopard give the command:

# vncpasswd

We are prompted for a password. This is the password that we will use when we connect to leopard’s vnc server instance. This password is saved in /home/leopard/.vnc/passwd.

Start the VNC server

After the initial configuration is done we restart the vnc service. As root:

# service vncserver restart

To make VNC server to start on boot:

# chkconfig vncserver on

More User Configuration

After the VNC service is started, some new files are created in /home/leopard/.vnc/ directory. These include leopard’s vnc server log file, pid file and an X startup script. As user leopard we edit the script in order to customize some settings. The default /home/leopard/.vnc/xstartup script contains some commands that are executed when the VNC server is started. These include:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

xsetroot in this case sets the background color.
vncconfig is a supplementary program that can be used to control the vnc server. Apart from this, when run without arguments it acts as a helper application and its main purpose is to provide support for clipboard transfers between the client (vncviewer) and the vnc server.
xterm starts an xterm terminal.
twm starts the X server’s default window manager. We probably want to change that to a more user friendly window manager, eg fluxbox.

The VNC server, apart from letting us control a remote machine using a graphical interface, it serves as a way to start graphical applications on boot. For example, I want my favourite p2p program, amule, to start on boot. So, I add this to the /home/leopard/.vnc/xstartup script. This is how my xstartup file looks like:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" -e ./menu &
amule &
fluxbox & 

menu is a script of mine that is executed when xterm is started.
Remember to put the "&" symbol after each command, so that it goes to the background and the xstartup script continues on.

Restart the VNC service for the changes to take effect. As root:

# service vncserver restart

Connect to the VNC server

In our example, leopard’s vnc server listens for connections on port 5903. So, open this port in the remote machine’s firewall.

We connect to the remote machine using a vnc viewer. Having installed the vnc package, connect to to the server with the following command:

# vncviewer 192.168.0.1:5903:3

The general usage is :

vncviewer [Server's IP]:[Port]:[Display]

We are prompted for the password and eventually connect to the server. Closing the vncviewer’s window, does not affect the server or the programs we run on it. If we reconnect everything will be there.

Special Note: There is no need, actually it’s pointless and could give you some trouble, to logoff from your remote X session. If this happens, generally you need to restart the VNC service on the remote machine to get your remote desktop back. If you want to stop working on your remote desktop, just close the vncviewer’s window and you are done.

Security

The VNC protocol is not a secure communication protocol. The use of a vnc password provides security at the level of server access (it’s vulnerable to brute-force attacks though), but the whole VNC session is transmitted in the clear, without encryption. The easiest, but most effective, way to secure our connection to the VNC server is to connect through an encrypted SSH tunnel. This way the whole session will be encrypted.

The rest assume that you have the SSH server up and running on your remote machine (server.example.com) and you know what SSH tunnels are.

So, what we are going to do is to create an encrypted tunnel, and connect to our VNC server through it. We also want this tunnel to be automatically closed as soon as we shut down vncviewer. All this is done with the following command:

# ssh -f -L 25903:127.0.0.1:5903 leopard@server.example.com sleep 10; vncviewer 127.0.0.1:25903:3

This is what it does:

• -L 25903:127.0.0.1:5903 forwards our local port 25903 to port 5903 on the remote machine. In other words, it creates the tunnel.
• -f forks the SSH session to the background, while sleep is being executed on the remote machine. This ssh option is needed because we want to execute the following command (vncviewer) in the same local machine’s terminal.
• vncviewer connects to the forwarded local port 25903 in order to connect to the VNC server through the encrypted tunnel.

The sleep command is of major importance in the above line as it keeps the encrypted tunnel open for 10 seconds. If no application uses it during this period of time, then it’s closed. Contrariwise, if an application uses it during the 10 sec period, then the tunnel remains open until this application is shut down. This way the tunnel is automatically closed at the time we close vncviewer’s window, without leaving any SSH processes running on our workstation. This is pure convenience! More information can be found at the Auto-closing SSH Tunnels article.

Using SSH tunnels to conect to your VNC server has two advantages:

1. The whole session is encrypted.
2. Keeping port 5903 open on your remote machine is no longer needed, since all take place through the SSH tunnel. So, noone will know that you run a VNC server on the remote machine.

Further Reading

I recommend that you read the man pages. Everything is in there:

# man vncserver
# man Xvnc
# man vncconfig
# man vncviewer
# man ssh

Related Articles

• SSH Tunnels Headaches
• Auto-closing SSH tunnels
• Setup the SSH server to use keys for authentication
• Netcat – a couple of useful examples
• Python SSH Server for UNIX Systems using Twisted.conch

An SSH server can be set up in various ways, but in this document I’ll describe how it can be configured to:

• only support connections through the 2nd version of the SSH protocol (SSH-2)
• use DSA keys for user authentication, without permitting authentication with passwords
• allow only a specific group of users to connect

The SSH-2 protocol, apart from many other useful features, provides stronger security than SSH-1. It’s a bit more cpu hungry than the latter, but this should not be a problem. Using the above configuration, someone must be extremely lucky to manage to break into our system.

But, let me say a few words about how the authentication is done. The user creates a keypair, which consists of a private key, that can be protected with a passphrase, and a public key. The public key is transfered to the server and the private key is kept in our workstation. We assume that the user has accounts in both the server machine and his workstation. Everytime he tries to connect to the server, the keys are validated and the user is granted access.

Prerequisites

A user account in the SSH server machine.

You need to install the following packages to the SSH server machine:

• openssh
• openssh-server

The client machines should have the following:

• openssh
• openssh-clients

First things first…

I assume that our server machine (server.example.com) is a headless one and that the SSH server is up and running with the default configuration. This permits users, including root, to login with their username/password combination. I also assume that we have already set up a user account on the server with the username "leopard". From a client machine (pc1.example.com) we connect like this:

# ssh leopard@server.example.com

Keypair generation

The default key directory is "~/.ssh". Create this directory in both the user leopard’s home on the server and in your current home directory on the client machine and chmod it so that only the users have access to it.

# mkdir ~/.ssh
# chmod 0700 ~/.ssh

Now, we will create our keypair on our client machine. The following command creates a standard 1024-bit DSA keypair:

# ssh-keygen -t dsa -f ~/.ssh/id_dsa

You will be asked for a passphrase for the private key. You can type any phrase here or leave it blank. Keep in mind that if you do not set a passphrase for you private key and someone else gets access to it, then it will take him only a few seconds to connect to your user account on the server. Anyway, this is up to you. After the key generation is finished, the files id_dsa (private key) and id_dsa.pub (public key) are created in the ~/.ssh/ directory.

Now, we will copy the public key to the /home/leopard/.ssh/ directory on the server saving it with the name authorized_keys and delete id_dsa.pub from our client machine, just because it’s not needed to be there.

# scp ~/.ssh/id_dsa.pub leopard@server.example.com:~/.ssh/authorized_keys
# rm -f ~/.ssh/id_dsa.pub

Make sure that you chmod both keys so that only the respective users have access to them. Issue the following command on both the server and the client machine:

# chmod 0600 ~/.ssh/*

A limited group of SSH users

As an extra security measure, we will create a new group on the server machine and configure the SSH server to only allow this group’s members to authenticate. So, we create a group named "sshusers" and add user "leopard" to it. This has to be done as root:

# groupadd sshusers
# usermod -a -G sshusers leopard

The SSH Server configuration

The SSH server’s configuration file is /etc/ssh/sshd_config. Most of the default options do not need to be modified. What we’ll do is to set it up so that only the members of the "sshusers" group can authenticate using keys instead of passwords. So, as root, fire up your favourite text editor and edit the server configuration file.
NOTE: It’s a good habit to create backups before editing system files.
The options that need to be modified are shown below:

Port 22
Protocol 2
AddressFamily inet
ListenAddress 192.168.0.1

With these we configure the server to listen on port 22, accept connections only over the SSH-2 protocol, use the IPv4 address family and bind on the 192.168.0.1 IP address. Only the "protocol" option is really critical. You can set the others as you like or leave the defaults.

HostKey /etc/ssh/ssh_host_dsa_key

Uncomment or add this line. This is exactly the same as the default option, but needs to be uncommented in the server configuration file, so that the server shows its DSA key’s fingerprint when the client tries to authenticate the server during the connection process. If this is not set, then the server shows its RSA key’s fingerprint (the reason is unknown to me).

LoginGraceTime 2m
PermitRootLogin no
MaxAuthTries 1

The LoginGraceTime option sets a time limit for the user authentication process. If this time passes and the user has not yet authenticated succesfully, then the server closes the connection. Leave this value to the default "2m" until everything is set up properly, so that you have enough time to read any server messages. After that, you can lower it to a reasonable value. I have set it to "20s".
Setting the "PermitRootLogin" option to "no" the server does not allow root to login directly. You can still use "su" after you have succesfully logged in as a normal user.
The "MaxAuthTries" option sets the maximum login attempts per connection. Since we use keys and key validation never fails, we set it to "1".

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

These are the default options. I just add them here so that you make sure they are set up properly in your config.

RSAAuthentication no
PasswordAuthentication no
UsePAM no
KerberosAuthentication no
GSSAPIAuthentication no

We do not want the server to let users authenticate using passwords or use SSH-1 based authentication methods. You should comment out any Kerberos or GSSAPI options too.

AllowGroups sshusers

Only users that belong to the "sshusers" group can authenticate. Any other user will be rejected without even being given the oportunity to authenticate.

MaxStartups 2

This option specifies the maximum number of concurrent unauthenticated connections to the SSH Server. It has nothing to do with the number of authenticated connections. The default value is "10". We lower this value in order to limit the connections from third parties which do not have an account on our server machine.

Banner /etc/ssh/banner

Finaly, you can set a text file that will be displayed as a banner when someone connects to the server. Just remember that it is displayed before the authentication takes place, so do not be very descriptive. The banner is not really needed.

This is all we have to do. The rest of the configuration options should be left to their default values, unless you need something different. This is up to you.

Restarting the server

Now, that we have finished editing the config file, we need to restart the server, so that our changes take effect. Before that, I would recommend deleting any existing server keys. Don’t worry, they will be recreated as soon as the service is restarted. A quick way to delete all the keys is to:

# rm -f ssh_host*key*

Then restart the server:

# service sshd restart

Note that the key creation time may vary from machine to machine, so it may take a few minutes if the CPU is slow.

The server logging is done through syslog and authentication information is sent to /var/log/secure. This file should not be world-readable.

A last thing is to take a note of the server’s DSA public key fingerprint, so that we can compare it with the fingerprint the server sends to our client when we connect. This is important for connections to the server from locations other than our LAN in order to be sure that we actually connect to our server. On the server console type:

# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub

Take a note of the fingerprint.

Connect to the server

To connect to our SSH server from our client machine (pc1.example.com), we type:

# ssh leopard@server.example.com

I suggest that the first time you connect you should add the -v option to the above command for verbose output.

Before the user authentication takes place, the ssh client will try to authenticate the SSH server. Since, there is no stored information about your server it will present you the server’s public DSA key fingerprint so you can compare it with the fingerprint you had previously taken a note of during the server configuration. If the fingerprints are identical, you can answer positively to the question. At this time the file ~/.ssh/known_hosts is created on your client machine and it contains the trusted SSH server’s information. You will never be asked again if you trust this server. If the fingerprint comparison took you longer than the server’s LoginGraceTime, the user authentication does not take place. Just try to reconnect. This time you will eventually log in succesfully using key authentication.

Hashing the known_hosts file

Because the servers’ hostnames and addresses are stored in plain text in the known_hosts file, hashing it is a good habit. This can be done using the ssh-keygen utility. Type:

# ssh-keygen -H -f ~/.ssh/known_hosts

This process makes it unreadable, but the ssh programs can still read the contents. Make sure you permanently delete the known_hosts.old backup file.

Change your private key’s passphrase

If you ever need to change the private key’s passphrase you can use ssh-keygen:

# ssh-keygen -p -f ~/.ssh/id_dsa

The ssh-agent

Although key authentication has many advantages over the authentication with passwords, it has one significant drawback: we have to type the passphrase every time we make a connection to the SSH server. One solution would be not to use a passphrase for our private key. But, this is unacceptable. If someone else gets access to our key and finds out to which servers we connect, things get really bad. A second solution is to use the ssh-agent (part of the openssh package) which caches our passphrase in the memory and then it’s automatically used when we make the connection to the SSH server. This way, we only need to type the passphrase once. This is by far more secure than not using a passphrase.

The ssh-agent is a small daemon that runs in the background. When it is run, it exports some environment variables (SSH_AUTH_SOCK, SSH_AGENT_PID) which can be used by programs like ssh-add in order to manage the agent’s cached info or by other programs like the ssh client in order to use this cached info for user authentication. These environment variables must be available to these programs, so the ssh-agent needs to be started in our login shell. There are many different ways to start the agent. Here I’ll describe a rather simple, but very efficient one.

The ssh-agent’s configuration

What we need is to start the agent when we login to our client machine’s shell and stop it when we log out. So, we add the following line to ~/.bash_profile:

eval `ssh-agent`

Why do we use eval? When the ssh-agent is started, it just prints some commands to the stdout. These commands set and export the environment variables we talked about earlier. We use eval, so that these commands are actually executed, or better, evaluated by the shell, so the environment variables are made available to all applications that can use them.

We add the following line to ~/.bash_logout

eval `ssh-agent -k`

This "unsets" the environment variables and kills the agent every time we logout.

Management of cached passphrases

A small utility called ssh-add is used to manage the cached passphrases.

To add a key to the ssh-agent’s cache, we issue the command:

# ssh-add ~/.ssh/id_dsa

We are prompted for the passphrase. After typing it succesfully, it gets cached. From now on, the cached passphrase will be automatically used for every connection we make to the SSH server. Convenient!
If we store our key to the standard location ~/.ssh/ and name it with the standard filename id_dsa, then ssh-add can be run without arguments. Our key will be used.

To list the cached keys we type:

# ssh-add -l

To remove a cached key:

# ssh-add -d ~/.ssh/id_dsa

To empty the ssh-agent’s cache:

# ssh-add -D

Further Reading

There are numerous articles around the web about SSH. Just use google. Keep in mind though that all the necessary info is in the man pages. You should not just read them, but rather study them:

1. The official openssh manuals
2. The openssh FAQ

This article appeared in the digg.com homepage on November 16th, 2005. I thank all “diggers” by heart.

Related Articles

• Set up the VNC Server in Fedora
• Be your own Certificate Authority (CA)
• Auto-closing SSH tunnels
• Python SSH Server for UNIX Systems using Twisted.conch
• Netcat – a couple of useful examples

• create the SSH tunnel (local port forwarding)
• execute vncviewer on the local machine
• have the SSH tunnel to be automatically closed at the time vncviewer was closed

After about one hour of trial and error and man page reading, I ended up with a very useful line of code:

ssh -f -L 25930:127.0.0.1:5904 -C me@remote sleep 10; vncviewer 127.0.0.1:25930:4

What this does is:

• forwards local port 25930 to remote port 5904
• forks the ssh session to the background executing a sleep command on the remote machine
• executes vncviewer so that it connects to the vnc server through the tunnel

What I badly needed was a way to auto-close the tunnel at the time vncviewer was closed. This seems to do it. The sleep command keeps the tunnel open for ten seconds. After this period of time it’s closed, unless vncviewer or some other application uses it. In this case, it is closed at the time this application stops using it. Pretty fu..ing cool!! I have wasted all my head’s juice until I managed to figure this out…

Related Articles

• Auto-closing SSH tunnels
• Set up the VNC Server in Fedora
• Netcat – a couple of useful examples
• Setup the SSH server to use keys for authentication
• Linux Tips – Pack I