Case Study: Clusters and Image Processing, Part II - page 8
The ImageLink Case, Reviewed
To add ssh into the cluster mix, you have to get ssh, install it, and set it up. To do this, follow these steps:
- Use your Web browser or an FTP client to go to ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm.
- Download openssl-0.9.5a-1.i386.rpm and openssh-2.1.1p4-1.i386.rpm.
- Install both RPMs on all your LVS machines, adding openssl before openssh.
- One reason that ssh is considered to be a secure shell is that it uses keys to verify that machines and people are who they say they are. Two different protocols are available for you to use, and each of these requires a different key:
- ssh 1.3 and 1.5, which require an RSA key
- ssh 2.0, which requires a DSA key
Determine which of these you want to use.
- Start the command to generate the appropriate key. Regardless of which key type you need, start by typing ssh-keygen.
- If you want the 2.0 protocol, extend this to ssh-keygen -d.
- Assign a file name to the file that contains the key so you know exactly what to look for later if you need it. Here are the commonly used ones:
- /etc/ssh/ssh_host_key- (for the RSA key)
- /etc/ssh/ssh_host_dsa_key- (for the DSA key)
ssh-keygen -d -f /etc/ssh/ssh_host_key -N ' '
This program now generates your public and private keys.
TIP: If you would rather answer prompts than do everything at the command line, just type ssh-keygen and you will be asked a series of questions.
- Return to ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm and download the openssh-server RPM.
- Install this RPM on your LVS router(s).
- Open the file /etc/ssh/sshd_config in your favorite text editor. This file already contains a default configuration. You'll simply modify it for your purposes.
- If you want the secure shell daemon (sshd) to listen on a nonstandard port for requests, change the Port value.
NOTE: If you do this, make sure to tell the clients that they need to talk to a nonstandard port.
- By default, it's assumed that you're using the ssh 1 family of protocols. Here's what to do if this is not the case:
- If you're using 2, uncomment the Protocol line and change it to this:
- If you're using both, uncomment the Protocol line by deleting the hash mark (#) and use what is already there:
- By default, it's assumed that you want the ssh daemon to handle requests from all IP addresses on your network. You can narrow this down, however, by commenting out the default ListenAddress entry by removing the hash mark, uncommenting the second, and editing the second. You might end up with something like this:
#ListenAddress 0.0.0.0 ListenAddress 192.168.0.1:192.168.0.5:192.168.0.15
- If you are only using protocol 2 for ssh, comment out the HostKey option by putting a hash mark in front of it. Otherwise, ensure that its value matches the path and name you assigned to your RSH key file. If you're using the defaults listed earlier, here's what you should have:
- The ssh server has its own key. By default, that key size is 768 bits. If you want to change this value, edit the following line:
The minimum key size allowed is 512 bits.
- By default, the user has 600 seconds to successfully log in over ssh. That can be a lot of time--10 minutes--on a fast connection. If you want to change this value, edit the following line:
- One reason ssh is considered so secure is that the server actually creates a new key at regular intervals. This makes it very hard for those who are trying to sniff keys to be sure they've got the most recent one, if they can manage to sniff it at all. The option KeyRegenerationInterval sets how often this key is reset. Here's the default entry:
Change this value (which is in seconds) if you want, but remember that if you make this value too large, it will be easier for people to break in, and if you make this value too small, it places a heavier burden on the server and the network.
- Change PrintMotd to this:
The ssh logins are being done by machines, not users. There's no need for a Message of the Day.
- Save and exit the file.
TIP: If you want to explore the other options further, type man sshd for a full listing of all parameters available in this file.
- Restart sshd by typing /etc/rc.d/init.d/sshd restart if you are using Red Hat Linux or one of its derivatives.
- Add sshd to the list of daemons that start at boot time. It doesn't matter whether you do this by using a graphical tool, editing rc.local, placing links in the startup daemon directories, or via another method, as long as it gets done.
- Return to ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm and download the openssh-clients RPM.
- Install openssh-clients on all the cluster machines.
- On all the cluster machines, create the file /etc/ssh/hosts.equiv.
- Enter the name of each machine in the cluster--nodes and router(s) alike--one per line. Only omit this machine's name.
- Save and exit these files.
- As root, run the ssh-keygen program on all the cluster machines that you have not already done this for.
- On the server machine, create the file /etc/ssh_known_hosts.
- For each machine in the cluster, create the following entry:
You copy in the public key from the client machine's ssh_host_key.pub file.
- Save and exit the file.
- Believe it or not, there is still more to configure. On all the machines, open the file /etc/ssh/ssh_config.
- This is the client configuration file that sets its connection-accepting behavior. Everything in here is commented out by default. Some items will need to be changed, and others can be left as they are. I'm going to stick with discussing the items that are pertinent to the cluster context. The first line to consider is Host. Uncomment it and then decide what it should be set to:
- *--If you leave Host set to *, all machines will be allowed to connect to this machine.
- pattern*--Use this wildcard to set a name pattern. I recommend that you name all the machines in your cluster using a pattern, such as cluster1, cluster2, and so on. For example, you could change the line to this:
TIP: If you want to know about the rest of the configuration parameters in this file, type man ssh.
- Uncomment the RhostsAuthentication line and change it to this:
There's no point in adding ssh if you're going to allow rhost connections.
- Uncomment the RhostsRSAAuthentication line so that it appears as follows:
This will allow rhost connections if they are authenticated through ssh.
- Uncomment the RSAAuthentication line so that it appears as follows:
- Uncomment the PasswordAuthentication line. Because you're specifically setting this up for the cluster, change it to this:
- Uncomment the following lines so that the client will not allow an rhost connection if ssh fails:
FallBackToRsh no UseRsh no
- Uncomment the BatchMode line and change it to this:
This will ensure that the server and client do not expect user interaction.
- If you changed the port that sshd uses, uncomment and change the following line to match it:
# Port 22
- If you changed the protocol setting for sshd, change the following line to match it:
# Protocol 2,1
- Now, at the end of the file, comment out the following default settings because you're using the ones higher up instead:
Host * ForwardAgent no ForwardX11 no FallBckToRsh no
- Save and exit the files. Believe it or not, that's it!
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.
- 1Linux Top 3: Ubuntu 14.04, Debian Gives Squeeze More Life and Red Hat Goes Atomic
- 2Linux Top 3: CoreOS, Oracle Enterprise Linux 7 and Ubuntu 14.10
- 3Linux Top 3: Debian Dumps SPARC, Ubuntu Takes Over Linux 3.13 and the Core Infrastructure Initiative
- 4Linux Top 3: Fedora, Ubuntu and Gluster Lose Community Leaders
- 5Red Hat Enterprise Linux 7 Finally Hits the Big Time