Two-Node SSH Client-Server Recipe

List of ingredients:

• Primary server (preferably with two Network Interface Cards and cables)

• Backup server (preferably with two Network Interface Cards and cables)

• Crossover cable or mini hub

• Copy of the rsync RPM file

• Copy of Open SSH (version 2.2 or later)

Included on the CD-ROM with this book is a copy of the Open SSH package and the rsync package in RPM format in the chapter4 subdirectory. Your distribution should already contain Open SSH. To find out which version is loaded on your system, type:

 #rpm -qa | grep ssh 

If you do not have version 2.2 or later, you will need to install a newer version either from your distribution vendor or from the CD-ROM included with this book before starting this recipe.

Note 

Please check for the latest versions of these software packages from your distribution or from the project home pages so you can be sure you have the most recent security updates for these packages.

Create a User Account that Will Own the Data Files

Perform this step on the SSH client and the SSH server. The SSH client in this recipe is the primary server at IP address 10.1.1.1. The SSH server is the backup server at IP address 10.1.1.2 (see Figure 4-1).

You can use the root account or any user account (you can create a special non-root account dedicated to providing SSH access). You can then grant this user access to commands or scripts as the root user using the sudo program (see man sudo for more information). But if you want to take a shortcut and just use the root account, you will need to modify the default SSHD config file (/etc/ssh/sshd_config) that comes with the Red Hat distribution and change the PermitRootLogin variable so it looks like this:

 PermitRootLogin without-password 

In this recipe, we will use the more secure technique of creating a new account called web and then giving access to the files we want to transfer to the backup node (in the directory /www) to this new account; however, for most high-availability server configurations, you will need to use the root account or the sudo program.

1. Add the web user account with the following command:

    #useradd -u 100 -g 48 -d /home/web -s /bin/bash -c "Web File Owner" -p password web 

   Note 

   For added security, we will (later in this recipe) remove the shell and password for this account in order to prevent normal logons as user web.

   The useradd command automatically created a /home/web directory and gave ownership to the web user, and it set the password for the web account to password.

2. Now create the /www directory and place a file or two in it:

    #mkdir /www #mkdir /www/htdocs #echo "This is a test" > /www/htdocs/index.html #chown -R web /www 

   These commands create the /www/htdocs directory and subdirectory and place the file index.html with the words This is a test in it. Ownership of all of these files and directories is then given to the web user account we just created.

Configure the Open SSH2 Host Key on the SSH Server

If you installed the sshd daemon on your system using the Red Hat RPM file, then all you need to do to create your SSH host keys on the backup server is start the sshd daemon. Check to see if it is already running on the backup server with the command:

 #ps -elf | grep sshd 

If it is not running, start it with the command:

 #/etc/init.d/sshd start 

or

 #service sshd start 

Note 

If sshd was not running, you should make sure it starts each time the system boots—see Chapter 1.

Use the following two commands to check to make sure the Open SSH version 2 (RSA) host key has been created. These commands will show you the public and private halves of the RSA host key created by the sshd daemon.

The private half of the Open SSH2 RSA host key:

 #cat /etc/ssh/ssh_host_rsa_key 

The public half of the Open SSH2 RSA host key:

 #cat /etc/ssh/ssh_host_rsa_key.pub 

Note 

The /etc/rc.d/init.d/sshd script on Red Hat systems will also create Open SSH1 DSA host keys (that we will not use) with similar names.

Create a User Encryption Key for this New Account on the SSH Client

To create a user encryption key for this new account:

1. Log on to the SSH client as the web user you just created. If you are logged on as root, use the following command to switch to the web account:

    #su web 

2. Make sure you are the web user with the command:

    #whoami 

3. Now create an Open SSH2 key with the command:

    #ssh-keygen -t rsa 

   The output of this command will look like this:

    Generating public/private rsa key pair. Enter file in which to save the key (/home/web/.ssh/id_rsa): Enter passphrase (empty for no passphrase): <return> ← Enter same passphrase again: <return> ← Your identification has been saved in /home/web/.ssh/id_rsa. Your public key has been saved in /home/web/.ssh/id_rsa.pub. The key fingerprint is: a3:ec:9f:63:52:4e:42:66:11:6a:38:8d:de:5e:66:84 [e-mail] 

   Leave the lines marked with arrows (←) blank.

   Note 

   We do not want to use a passphrase to protect our encryption key, because the SSH program would need to prompt us for this passphrase each time a new SSH connection was needed.^[5]

   As the output of the above command indicates, the public half of our encryption key is now stored in the file:

    /home/web/.ssh/id_rsa.pub 

4. View the contents of this file with the command:

    #cat /home/web/.ssh/id_rsa.pub 

   You should see something like this:

    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAz1LUbTSq/ 45jE8Jy8lGAX4e6Mxu33HVrUVfrn0U9+nlb4DpiHGWR1DXZ15dZQe26pITxSJqFabTD47uGWVD 0Hi+TxczL1lasdf9124jsleHmgg5uvgN3h9pTAkuS06KEZBSOUvlsAEvUodEhAUv7FBgqfN2VD mrV19uRRnm30nXYE= [e-mail] 

   Note 

   This entire file is just one line.

Copy the Public Half of the User Encryption Key From the SSH Client to the SSH Server

Because we are using user authentication with encryption keys to establish the trust relationship between the server and the client computer, we need to place the public half of the user's encryption key on the SSH server. Again, you can use the web user account we have created for this purpose, or you can simply use the root account.

1. Use the copy-and-paste feature of your terminal emulation software (or use the mouse at one of the system consoles)—even if you are just typing at a plain-text terminal, this will work on Red Hat—and copy the above line (from the id_rsa.pub file on the SSH client) into the paste buffer.^[6]

2. From another window, log on to the SSH server and enter the following commands:

    #mkdir /home/web/.ssh #vi /home/web/.ssh/authorized_keys2 

   This screen is now ready for you to paste in the private half of the web user's encryption key.

3. Before doing so, however, enter the following:

    from="10.1.1.1",no-X11-forwarding,no-agent-forwarding, ssh-dss 

   This adds even more restriction to the SSH transport.^[7] The web user is only allowed in from IP address 10.1.1.1, and no X11 or agent forwarding (sending packets through the SSH tunnel on to other daemons on the SSH server) is allowed. (In a moment, we'll even disable interactive terminal access.)

4. Now, without pressing ENTER, paste in the public half of the web user's encryption key (on the same line). This file should now be one very long line that looks similar to this:

    from="10.1.1.1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding, ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAz1LUbTSq/ 45jE8Jy8lGAX4e6Mxu33HVrUVfrn0U9+nlb4DpiHGWR1DXZ15dZQe26pITxSJqFabTD47uGWVD 0Hi+TxczL1lasdf9124jsleHmgg5uvgN3h9pTAkuS06KEZBSOUvlsAEvUodEhAUv7FBgqfN2VD mrV19uRRnm30nXYE= [e-mail] 

5. Set the security of this file:

    #chmod 600 /home/web/.ssh/authorized_keys2 

Note 

See man sshd and search for the section titled AUTHORIZED_KEYS FILE FORMAT for more information about this file.

You should also make sure the security of the /home/web and the /home/web/.ssh directories is set properly (both directories should be owned by the web user, and no other user needs to have write access to either directory).

The vi editor can combine multiple lines into one using the keys SHIFT+J. However, this method is prone to errors, and it is better to use a telnet copy-and-paste utility (or even better, copy the file using the ftp utility or use the scp command and manually enter the user account password).

Test the Connection From the SSH Client to the SSH Server

Log on to the SSH client as the web user again, and enter the following command:

 #ssh 10.1.1.2 hostname 

Because this is the first time you have connected to this SSH server, the public half of the SSH server's host encryption key is not in the SSH client's known_hosts database. You should see a warning message like the following:

 The authenticity of host '10.1.1.2 (10.1.1.2)' can't be established. RSA key fingerprint is a4:76:aa:ed:bc:2e:78:0b:4a:86:d9:aa:37:bb:2c:93. Are you sure you want to continue connecting (yes/no)? 

When you type yes and press ENTER, the SSH client adds the public half of the SSH server's host encryption key to the known_hosts database and displays:

 Warning: Permanently added '10.1.1.2' (RSA) to the list of known hosts. 

Note 

To avoid this prompt, we could have copied the public half of the SSH server's host encryption key into the known_hosts database on the SSH client.

The SSH client should now complete your command. In this case, we asked it to execute the command hostname on the remote server, so you should now see the name of the SSH server on your screen and control returns to your local shell on the SSH client.

A new file should have been created (if it did not already exist) on the SSH client called /home/web/.ssh/known_hosts2.

Instead of the remote host name, your SSH client may prompt you for a password with a display such as the following:

 web@10.1.1.2's password: 

AVOIDING SSH VERSION 1

If you see (RSA1) instead of (RSA) in the above message, this means you have fallen back to SSH-level security instead of SSH2, and you will need to do the following (you will also need to do this if you see a complaint about the fact that you might be doing something NASTY):

On the SSH client, remove the known_hosts file that was just created:

 #rm /home/web/.ssh/known_hosts 

On the SSH server, check the file /etc/ssh/sshd_conf and make sure the Protocol entry looks like this:

 Protocol 2,1 

This indicates that we want the SSHD server to first attempt to use the SSH2 protocol and only if this doesn't work should it fall back to the SSH1 version of the protocol. Now restart the SSHD daemon on the SSH server with the command:

 #/etc/rc.d/init.d/sshd restart 

Now try the ssh 10.1.1.2 hostname command again to see if you can log on to the SSH server (at IP address 10.1.1.2 in this example).

If you receive the message Connection refused, this might indicate that the sshd daemon on the server is listening to the wrong network interface card or not listening at all (or you may have ipchains/iptables firewall rules blocking access to the sshd server). To see if sshd is listening on the server, run the command netstat -apn | grep ssh. You should see that sshd is listening on port 22. To check or modify which interface sshd is listening on (again on the server), examine the ListenAddress line in the /etc/ssh/sshd_config file.

This means the SSH server was not able to authenticate your web user account with the public half of the user encryption key you pasted into the /home/web/.ssh/authorized_keys2 file. (Check to make sure you followed all of the instructions in the last section.)

If this doesn't help, try the following command to see what SSH is doing behind the scenes:

 #ssh -v 10.1.1.2 hostname 

The output of this command should display a listing similar to the following:

 OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: getuid 100 geteuid 0 anon 1 debug1: Connecting to 10.1.1.2 [10.1.1.2] port 22. debug1: Connection established. debug1: unknown identity file /home/web/.ssh/identity debug1: identity file /home/web/.ssh/identity type -1 debug1: unknown identity file /home/web/.ssh/id_rsa debug1: identity file /home/web/.ssh/id_rsa type -1 debug1: identity file /home/web/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.5.2p2 debug1: match: OpenSSH_2.5.2p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.5.2p2 debug1: send KEXINIT debug1: done debug1: wait KEXINIT debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1- sha1 debug1: got kexinit: ssh-rsa,ssh-dss debug1: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256- cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael- [e-mail] debug1: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256- cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael- [e-mail] debug1: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- [e-mail],hmac-sha1-96,hmac-md5-96 debug1: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- [e-mail],hmac-sha1-96,hmac-md5-96 debug1: got kexinit: none,zlib debug1: got kexinit: none,zlib debug1: got kexinit: debug1: got kexinit: debug1: first kex follow: 0 debug1: reserved: 0 debug1: done debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug1: Wait SSH2_MSG_KEX_DH_GEX_GROUP. debug1: Got SSH2_MSG_KEX_DH_GEX_GROUP. debug1: dh_gen_key: priv key bits set: 129/256 debug1: bits set: 1022/2049 debug1: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug1: Wait SSH2_MSG_KEX_DH_GEX_REPLY. debug1: Got SSH2_MSG_KEXDH_REPLY. debug1: Host '10.1.1.2' is known and matches the RSA host key. debug1: Found key in /home/web/.ssh/known_hosts2:1 debug1: bits set: 1025/2049 debug1: ssh_rsa_verify: signature correct debug1: Wait SSH2_MSG_NEWKEYS. debug1: GOT SSH2_MSG_NEWKEYS. debug1: send SSH2_MSG_NEWKEYS. debug1: done: send SSH2_MSG_NEWKEYS. debug1: done: KEX2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password debug1: next auth method to try is publickey debug1: try privkey: /home/web/.ssh/identity debug1: try privkey: /home/web/.ssh/id_dsa debug1: try pubkey: /home/web/.ssh/id_rsa debug1: Remote: Port forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Pty allocation disabled. debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8083a58 hint 2 debug1: read SSH2 private key done: name rsa w/o comment success 1 debug1: sig size 20 20 debug1: Remote: Port forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Pty allocation disabled. debug1: ssh-userauth2 successful: method publickey debug1: fd 5 setting O_NONBLOCK debug1: fd 6 IS O_NONBLOCK debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: client_init id 0 arg 0 debug1: Sending command: hostname debug1: channel 0: open confirm rwindow 0 rmax 16384 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: rcvd close debug1: channel 0: input open -> closed debug1: channel 0: close_read bottompc.test.com debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: channel 0: send close debug1: channel 0: is dead debug1: channel_free: channel 0: status: The following connections are open:   #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 

Notice the lines that are bold in this listing, and compare this output to yours.

If you are prompted for the password and you are using the root account, you did not set PermitRootLogin yes in the /etc/ssh/sshd_config file on the server you are trying to connect to. If you did not set the IP address correctly in authorized_keys2 file on the server, you may see an error such as the following:

 debug1: Remote: Your host '10.1.1.1' is not permitted to use this key for login. 

If you see this error, you need to specify the correct IP address in the authorized_keys2 file on the server you are trying to connect to. (You'll find this file is in the .ssh subdirectory under the home directory of the user you are using.)

Further troubleshooting information and error messages are also available in the /var/log/messages file and the /var/log/secure files.

Using the Secure Data Transport

Now that we have established a secure data transport between the SSH client and the SSH server, we can copy files, send commands, or create an interactive shell.

• To copy files, use the scp command. Here is an example command to copy the file /etc/hosts on the SSH client to /tmp/hosts on the SSH server:

   #scp /etc/hosts 10.1.1.2:/tmp/hosts 

• To send commands to the SSH server from the ssh client, use a command such as the following:

   #ssh 10.1.1.2 who 

  This executes the who command on the 10.1.1.2 machine (the SSH server).

• To start an interactive shell on the SSH server, enter the following command on the SSH client:

   #ssh 10.1.1.2 

This logs you on to the SSH server and provides you with a normal, interactive shell. When you enter commands, they are executed on the SSH server. When you are done, type exit to return to your shell on the SSH client.

Improved Security

Once you have tested this configuration and are satisfied that the SSH client can connect to the SSH server, you can improve the security of your SSH client and SSH server. To do so, perform the following steps.

1. Remove the interactive shell access for the web account on the SSH server (the backup server) by editing the authorized_keys2 file and add the no-pty option:

    #vi /home/web/.ssh/authorized_keys2 

2. Change the beginning of this one-line file to look like this:

    from="10.1.1.1",no-X11-forwarding,no-agent-forwarding ssh-dss, no-pty 

3. Once you have finished with the rsync recipe shown later in this chapter, you can deactivate the normal user account password on the backup server (the SSH server) with the following command:

    #usermod -L web 

   This command inserts an ! in front of the web user's encrypted password in the /etc/shadow file. (Don't use this command on the root account!)

rsynzc over SSH

Your distribution should already have the rsync program. Check to make sure it is installed on both systems with the command:

 #rpm -qa | grep rsync 

Note 

If you do not have the rsync program installed on your system, you can load the rsync source code included on the CD-ROM with this book in the chapter4 subdirectory. (Copy the source code to a subdirectory on your system, untar it, and then type ./configure, make then make install.)

Now that we have a secure, encrypted method of transmitting data between our two cluster nodes, we can configure the rsync program to collect and ship data through this SSH transport. In the following steps, we'll create files in the /www directory on the SSH client and then copy these files to the SSH server using the rsync program and the web account.

1. Log on to the SSH client (the primary server) as root, and then enter:

    #mkdir /www #mkdir /www/htdocs #echo "This is a test" > /www/htdocs/index.html 

2. Give ownership of all of these files to the web user with the command:

    #chown -R web /www 

3. Now, on the SSH server (the backup server), we need to create at least the /www directory and give ownership of this directory to the web user because the web user does not have permission to create directories at the root level of the drive (in the / directory). To do so, log on to the SSH server (the backup server) as root, and then enter:

    #mkdir /www #chown web /www 

4. At this point, we are ready to use a simple rsync command on the SSH client (our primary server) to copy the contents of the /www directory (and all subdirectories) over to the SSH server (the backup server). Log on to the SSH client as the web user (from any directory), and then enter:

    #rsync -v -a -z -e ssh --delete /www/ 10.1.1.2:/www 

Note 

If you leave off the trailing / in /www/, you will be creating a new subdirectory on the destination system where the source files will land rather than updating the files in the /www directory on the destination system.

Because we use the -v option, the rsync command will copy the files verbosely. That is, you will see the list of directories and files that were in the local /www directory as they are copied over to the /www directory on the backup node.^[8]

We are using these rsync options:

-v

• Tells rsync to be verbose and explain what is happening.

-a

• Tells rsync to copy all of the files and directories from the source directory.

-z

• Tells rsync to compress the data in order to make the network transfer faster. (Our data will be encrypted and compressed before going over the wire.)

-e ssh

• Tells rsync to use our SSH shell to perform the network transfer. You can eliminate the need to type this argument each time you issue an rsync command by setting the RSYNC_RSH shell environment variable. See the rsync man page for details.

--delete

• Tells rsync to delete files on the backup server if they no longer exist on the primary server. (This option will not remove any primary, or source, data.)

/www/

• This is the source directory on the SSH client (the primary server) with a trailing slash (/). A trailing slash is required if you want rsync to copy the entire directory and its contents.

10.1.1.2:/www

• This is the destination IP address and destination directory.

Note 

To tell rsync to display on the screen everything it will do when you enter this command, without actually writing any files to the destination system, add a -n to the list of arguments.

If you now run this exact same rsync command again (#rsync -v -a -z -e ssh --delete /www/ 10.1.1.2:/www), rsync should see that nothing has changed in the source files and send almost nothing over the network connection, though it will still send a little bit of data to the rsync program on the destination system to check for disk blocks that have changed.

To see exactly what is happening when you run rsync, add the --stats option to the above command, as shown in the following example. Log on to the primary server (the SSH client) as the web user, and then enter:

 rsync -v -a -z -e ssh --delete --stats /www/ 10.1.1.2:/www 

rsync should now report that the Total transferred file size is 0 bytes, but you will see that a few hundred bytes of data were written.

Copying a Single File with rsync

To copy just one file using rsync, enter:

 #rsync -v -a -z -e ssh /etc/sysconfig/iptables 10.1.1.2:/etc/sysconfig/ 

Notice in this example that the destination directory is specified but that the destination file name is optional.

Here is how to copy one file from a remote machine (10.1.1.2) to the local one:

 #rsync -v -a -z -e ssh 10.1.1.2:/etc/sysconfig/iptables /etc/sysconfig/iptables 

In this example, we have specified the destination directory and the (optional) destination file name.

rsync over Slow WAN Connections

If your primary and backup server connect to each other via the Internet (or a slow connection such as a private T1 line), you may also want to add the --bwlimit to the rsync command. The number you specify following --bwlimit is the maximum number of kilobytes that rsync should try to send over the network per second. For example, to limit the rsync connection to 8 KB per second (or 1/24 of the total of a T1 connection), you could log on to the SSH client as the web user and enter:

 rsync -v -a -z -e ssh --delete --bwlimit=8 /www/ 10.1.1.2:/www 

Scheduled rsync Snapshots

Once you are happy with your rsync configuration, you can add a cron job to your primary server that will perform the rsync operation at regular intervals. For example, to synchronize the data in the /www directory at 30 minutes past the hour, every hour, you would enter the following command while logged on to the primary server as the web account:

 #crontab -e 

This should bring up the current crontab file for the web account in the vi editor.^[9] You will see that this file is empty because you do not have any cron jobs for the web account yet. To add a job, press the I key to insert text and enter:

 30 * * * * rsync -v -a -z -e ssh --delete /www/ 10.1.1.2:/www > /dev/null 2>&1 

Note 

You can add a comment on a line by itself to this file by preceding the comment with the # character. For example, your file might look like this:

 # This is a job to synchronize our files to the backup server. 30 * * * * rsync -v -a -z -e ssh --delete /www/ 10.1.1.2:/www 

Then press ESC, followed by the key sequence :wq to write and quit the file.

We have added > /dev/null 2>&1 to the end of this line to prevent cron from sending an email message every half hour when this cron job runs (output from the rsync command is sent to the /dev/null device, which means the output is ignored). You may instead prefer to log the output from this command, in which case you should change /dev/null in this command to the name of a log file where messages are to be stored.

To cause this command to send an email message only when it fails, you can modify it as follows:

 rsync -v -a -z -e ssh --delete /www/ 10.1.1.2:/www || echo "rsync failed"   | mail [e-mail] 

USING RSYNC TO COPY CONFIGURATION FILES FOR HIGH AVAILABILITY

In a Linux Enterprise Cluster, we need to build high-availability server pairs (using the Heartbeat package discussed later in this part of the book) to support the cluster. These high-availability servers will do things like offer print services to the cluster, load balance incoming requests to use the cluster, provide user account authentication information to the cluster nodes, and a variety of other things that help the cluster to function normally.

Most of these functions (except for load balancing) will be placed on a high-availability server pair called the cluster node manager. The cluster node manager will help to support the cluster (printing, user authentication, and so on) from one server while a backup cluster node manager server stands by ready to take over if this primary cluster node manager goes down. To do this, the backup cluster node manager—and every backup server in a high-availability server pair—needs to use the same configuration files as the primary server. The system administrator can create identical configuration files on a primary and backup server in a high-availability server pair by hand-editing each configuration file on both systems, but this method is prone to errors and is difficult to maintain. An easier method of keeping the backup server's configuration files the same as the primary server's is to simply copy them over the network using our secure data transport provided by Open SSH with the rsync utility.

Copying the configuration files from the primary server to the backup server in a high-availability server pair using Open SSH and rsync can also be automated by placing the rsync commands into a shell script that is then regularly executed by the cron daemon.

Here is a sample script that will copy the configuration files for the Heartbeat program itself^[10] (which is described in Chapters 6 through 9), the Mon monitoring daemon (described in Chapter 17) and the LPRng printing system (which is described in Chapter 19).

 #!/bin/bash # # rsync script to copy configuration files between primary # and backup servers. # backup_host="10.1.1.2" OPTS="--force --delete --recursive --ignore-errors -a -e ssh -z" rsync $OPTS /etc/ha.d/         $backup_host:/etc/ha.d/ rsync $OPTS /etc/hosts         $backup_host:/etc/hosts rsync $OPTS /etc/printcap      $backup_host:/etc/printcap rsync $OPTS /var/spool/lpd/    $backup_host:/var/spool/lpd/ rsync $OPTS /etc/mon           $backup_host:/etc/mon rsync $OPTS /usr/lib/mon/      $backup_host:/usr/lib/mon/ 

Note 

Directories contain a / at the end. See Chapter 18 for another example of this script when used on a server that will run batch cron jobs for the cluster.

This script file is also provided on the CD-ROM included with this book. Normally, to copy configuration files, you will need to use the root account, although you can use the sudo program if you do not want to use the root account to copy the configuration files (see the sudo man page for details). This script is then run as a regularly scheduled root cron job on the backup server in the high-availability server pair with additional lines added to copy the configuration files for all of the services that need to be made highly available. (In the next section, we'll describe how to create a cron job entry.)

To view your cron job listing, enter:

 #crontab -l 

This cron job will take effect the next time the clock reads thirty minutes after the hour.

The format of the crontab file is in section 5 of the man pages. To read this man page, type:

 #man 5 crontab 

Note 

See Chapter 1 to make sure the crond daemon starts each time your system boots.

ipchains/iptables Firewall Rules for rsync and SSH

If your primary server uses its eth1 network interface to connect to the backup server, you can prevent unwanted (outside) attempts to use SSH or rsync with the following ipchains/iptables rules.

Note 

You can accomplish the same thing these rules are doing by using access rules in the sshd_config file.

SSH uses port 22:

 ipchains -A input -i eth1 -p tcp -s 10.1.1.0/24 1024:65535   -d 10.1.1.1 22 -j ACCEPT 

or

 iptables -A INPUT -i eth1 -p tcp -s 10.1.1.0/24 --sport 1024:65535   -d 10.1.1.1 --dport 22 -j ACCEPT 

rsync uses port 873:

 ipchains -A input -i eth1 -p tcp -s 10.1.1.0/24 1024:65535   -d 10.1.1.1 873 -j ACCEPT 

or

 iptables -A INPUT -i eth1 -p tcp -s 10.1.1.0/24 --sport 1024:65535   -d 10.1.1.1 --dport 873 -j ACCEPT 

^[5]If you don't mind entering a passphrase each time your system boots, you can set a passphrase here and configure the ssh-agent for the web account. See the ssh-agent man page.

^[6]Security experts cringe at the thought that you might try and do this paste operation via telnet over the Internet because a hacker could easily intercept this transmission and steal your encryption key.

^[7]An additional option that could be used here is no-port-forwarding which, in this case, could mean that the web user on the SSH client machine cannot use the SSH transport to pass IP traffic destined for another UDP or IP port on the SSH server. However, if you plan to use the SystemImager software described in the next chapter, you need to leave port forwarding enabled on the SystemImager Golden Client

^[8]If this command does not work, check to make sure the ssh command works as described in the previous recipe.

^[9]This assumes that vi is your default editor. The default editor is controlled by the EDITOR shell environment variable.

^[10]As we'll see later in these chapters, the configuration files for Heartbeat should always be the same on the primary and the backup server. In some cases, however, the Heartbeat program must be notified of the changes to its configuration files (service heartbeat reload) or even restarted to make the changes take effect (when the /etc/ha.d/haresources file changes).