 | Level: Introductory Harish Chauhan (hchauhan@in.ibm.com), Linux Architect, IBM
15 Aug 2006
Updated 21 Sep 2006 Configure Secure Shell (SSH) on IBM System p™ and System x™ computers so the UNIX® server can access a remote server without a password.
Note: This article is strictly for beginning UNIX users and administrators. Experts will likely already know several ways of accomplishing this task.
Introduction: Executing a remote command on multiple computers
When you hear someone referring to a shell, do you know what that really entails? It basically means that you can open a terminal session on any UNIX® machine, where you type your commands to perform an activity, such as useradd username, passwd username, system-config-printers, and so on. This shell is local to your machine, and whatever command you execute is performing activity on your local machine.
However, what if you want to execute a command on a set of machines, such as setting the date on all of the machines in the network. One way is to log in individually to each machine and execute the date command, one machine at a time. A better way would be to set it automatically, where you log in to a server and have that machine set the date on the rest of the machines serially. To set the date remotely, you need tools like Secure Shell (SSH), or remote shell (rsh), installed on your machines. Usually, when you try to access the remote machines, you will be prompted for a password to make sure that you are an authorized user. However, you can configure SSH and rsh in your environment to bypass password verification. In this article, you'll concentrate on how to configure SSH in your environment. In Part 2, you'll look at rsh.
Hardware, software, and setup
Use the following hardware and software, to perform the tasks described in this article:
- IBM System p™ and System x™ servers, such as System p520 or System x345
- Red Hat Enterprise Linux® Version 4.0 Update 3 (RHEL Version 4.0 Update 3)
Figure 1. Setup diagram
Now follow these steps:
- Install RHEL Version 4.0 Update 3 on all machines in the environment, such as node1.my.com, node2.my.com, and node3.my.com, as shown in Figure 1. Note that any of the nodes can be System p, or System x, servers.
- Make sure
openssh Red Hat Package Manager (RPM) is installed on all your machines, as shown in Figure 2.
Figure 2. openssh RPMs
- If you already have
openssh installed, you will find the /etc/ssh directory on your machine, as shown in Figure 3. This directory holds all SSH-related configuration files. You can customize sshd by modifying the files here, but I'm not going to cover this in detail in this article.
Figure 3. Installed path, that is /etc/ssh
- If you don't have
openssh installed, then install it from the RHEL Version 4.0 Update 3 CDs using the following commands: #rpm -ivh openssh-* or #system-config-packages.
Configuring for root and standard users
You have the following two different types of configurations to consider:
-
Root user
- Standard user, in this case
myuser
Let's first consider configuring SSH for the Rootuser. To configure the Rootuser, follow these steps:
- Generate the public and private key pairs. In order to generate the key pairs, you have to execute the
ssh-keygen command, as shown in Figure 4. Note:
ssh-keygen prompts you to set a passphrase, but you just continue by pressing the Enter key. As shown in Figure 5, the .ssh folder gets created in the /root folder, which holds the generated public (id_rsa.pub) and private (id_rsa) keys.
Figure 4. ssh-keygen
Figure 5. Generated private and public keys pair
- Repeat the above step for every machine participating in your environment; public and private keys are different for each machine. Note: The generated public and private keys don't match even if you execute the
ssh-keygen multiple times on the same machine.
- Once you have executed
ssh-keygen on all the nodes, you can collect the generated id_rsa.pub key from each machine. You can use any method for collecting the id_rsa.pub keys, including a floppy drive, USB device, FTP, and so forth.
- In this step, I have assumed you have copied all the public keys in the
/root/.ssh folder on node1.my.com, as shown in Figure 6, where id_rsa.pub_node2 is the public key of node2.my.com and id_rsa.pub_node3 is the public key of node3.my.com. Basically, you append the contents of all three files in one file using the cat command.
Figure 6. Collected id_rsa.pub keys
- Now concatenate the contents of all the collected public keys in a file known as
authorized_keys, as shown in Figure 7 below, and place the file in the /root/.ssh folder. Note: The file must be named as authorized_keys. Any other name will not work.
Figure 7. Create authorized_keys file
Note: authorized_keys2 works as well, and only for SSH protocol Version 2.
- The final contents of the
authorized_keysfile will look like the code shown in Figure 8. Note: Each stanza shown in Figure 8 corresponds to one machine in your environment.
Figure 8. Contents of authorized_keys file
- Finally, you are ready to copy the
authorized_keys file into the /root/.ssh folder on each machine where you would like to log in without receiving a password prompt. You can use any standard method to copy the file to each machine, including a floppy drive, USB device, FTP, and so on.
- Once the
authorized_keys file has been copied to all the machines, you can test your setup by executing the following command:
If everything has been done correctly, you should see the date output from node2.my.com without being prompted for a password.
Figure 9. Sample script
Next, you should consider configuring SSH for any standard user, in this case, myuser.
To do this, make the assumption that user name, myuser, exists on all the nodes. You want to make sure myuser is able to execute the command without any password prompt. For example:
- Log in to any computer in the system as
myuser.
- Execute the
#ssh-keygen -t rsa command, which generates the public and private keys for myuser user in the /home/myuser/.ssh folder, as shown in Figure 10.
Figure 10. User public and private keys
- Execute
ssh-keygen on all the nodes as the myuser user.
- Collect all the public keys and create the
authorized_keys file, as explained in Step 5 for the root user above. Refer to Figure 11 for the contents of authorized_keys.
Figure 11. User authorized_keys file
- Finally, copy the
authorized_keys file into the /home/myuser/.ssh folder on all the machines and set the permission as 600, as shown in Figure 12, using the $chmod 600 /home/myuser/.ssh/authorized_keys command. This sets the access permission to 600, which means that only the owner or myuser has permission to read and write this file. No one else can modify it.
Figure 12. Permission on authorized_keys file
- Test your environment by executing the
$ssh node3.my.com date command. Doing so should return the date output of node3.my.com.
 |
Conclusion: Saving time, providing flexibility
In this article, you learned how to configure SSH in your environment so that you can perform activities more easily and quickly. This not only helps in saving time, but it also gives you flexibility to perform activities serially on more machines automatically. Part 2 concentrates on configuring rsh, another way of executing serial commands in your environment when security is not of prime importance.
Resources Learn
Get products and technologies
-
IBM trial software: Build your next development project with software for download directly from developerWorks.
Discuss
About the author | 
| | Harish has been with IBM since 1998 and has 14 years of experience. During his last eight years with IBM, he has spent five years at the India Research Lab and one year at the IBM T.J.Watson Research Center. Harish has been leading the Linux Center of Competency in Bangalore, India for the past two years. You can contact him at hchauhan@in.ibm.com. |
Rate this page
| |
