No Title[an error occurred while processing this directive]
Reference: Cisco: Internetworking Basics
This guide presents the steps required to configure passwordless SSH connectivity between two Linux nodes for remote access. The user account used in this guide is oracle:
The supported version of SSH for Linux distributions is OpenSSH. OpenSSH should be included in the Linux distribution minimal installation. To confirm that SSH packages are installed, run the following on both nodes.
If you do not see a list of SSH packages, then install those packages for your Linux distribution. For example, load the CD/DVD into each of the nodes and perform the following to install the OpenSSH packages.
The goal in this section is to setup user equivalence for the oracle OS user accounts on two Linux nodes. This will allow the oracle user account to run OS commands and copy files remotely without the need for a password.
To determine if SSH is installed and running, enter the following command.
If SSH is running, then the response to this command is a list of process ID number(s). Run this check on both nodes to verify the SSH daemons are installed and running.
You need either an RSA or a DSA key for the SSH protocol. RSA is used with the SSH 1.5 protocol, while DSA is the default for the SSH 2.0 protocol. With OpenSSH, you can use either RSA or DSA. The instructions that follow are for SSH1. If you have an SSH2 installation, and you cannot use SSH1, then refer to your SSH distribution documentation to configure SSH1 compatibility or to configure SSH2 with DSA.
To configure passwordless SSH, you must first create RSA or DSA keys on each node, and then copy all the keys generated on all other nodes (if more than 2) into an authorized keys file that is identical on each node. Note that the SSH files must be readable only by root and by the OS user account (oracle) as SSH ignores a private key file if it is accessible by others. In the examples that follow, the DSA key is used.
To configure passwordless SSH, complete the following on all nodes.
Complete the following steps on each node.
Log in to all nodes as the oracle OS user account.
To ensure that you are logged in as oracle and to verify that the user ID matches the expected user ID you have assigned to the oracle user, enter the commands id and id oracle. Verify that the user group and user and the user terminal window process you are using have group and user IDs that are identical.
Create the .ssh directory in the oracle user's home directory and set permissions on it to ensure that only the oracle user has read and write permissions.
Enter the following command to generate a DSA key pair (public and private key) for the SSH protocol. At the prompts, accept the default key file location and no passphrase (simply press [Enter] three times).
This command writes the DSA public key to the ~/.ssh/id_dsa.pub file and the private key to the ~/.ssh/id_dsa file.
Never distribute the private key to anyone not authorized.
Now that both nodes contain a public and private key for DSA, you will need to create an authorized key file (authorized_keys) on one of the nodes. An authorized key file is nothing more than a single file that contains a copy of everyone's (every node's) DSA public key. Once the authorized key file contains all of the public keys for each node, it is then distributed to all other nodes.
Complete the following steps on one of the nodes to create and then distribute the authorized key file. For the purpose of this example, I am using vmlinux1.
From vmlinux1, determine if the authorized key file ~/.ssh/authorized_keys already exists in the .ssh directory of the owner's home directory. In most cases this will not exist since this guide assumes you are working with a new install. If the file doesn't exist, create it now.
In the .ssh directory, you should see the id_dsa.pub public key that was created and the blank file authorized_keys.
From vmlinux1, use SCP (Secure Copy) or SFTP (Secure FTP) to copy the public key (~/.ssh/id_dsa.pub) from all nodes to the authorized key file just created (~/.ssh/authorized_keys). Again, this will be done from vmlinux1. You will be prompted for the oracle OS user account password for each node.
The first time you use SSH to connect to a node from a particular system, you will see a message similar to the following:
Enter yes at the prompt to continue. The public hostname will then be added to the known_hosts file in the ~/.ssh directory and you will not see this message again when you connect from this system to the same node.
At this point, we have the DSA public key from every node in the authorized key file (~/.ssh/authorized_keys) on vmlinux1.
We now need to copy the authorized key file to the remaining nodes. In this example, the only remaining node is vmlinux2. Use the scp command to copy the authorized key file to all remaining nodes.
Change the permission of the authorized key file for each node as follows.
After you have copied the authorized_keys file that contains all public keys to each node, complete the steps in this section to ensure passwordless SSH connectivity between all nodes is configured correctly.
When running the test SSH commands in this section, if you see any other messages or text, apart from the date and host name, then certain applications that expect passwordless SSH connectivity will fail. If any of the nodes prompt for a password or pass phrase then verify that the ~/.ssh/authorized_keys file on that node contains the correct public keys and that you have created an OS user account with identical group membership and IDs. Make any changes required to ensure that only the date and host name is displayed when you enter these commands. You should ensure that any part of a login script that generates any output, or asks any questions, is modified so it acts only when the shell is an interactive shell.
Log in as the oracle OS user account.
If SSH is configured correctly, you will be able to use the ssh and scp commands without being prompted for a password or pass phrase from the terminal session.
Perform the same actions above from any remaining nodes (vmlinux2) to ensure they too can access all other nodes without being prompted for a password or pass phrase and get added to the known_hosts file.
Certain GUI applications that require use of an X server may fail if not configured correctly. From a terminal session enabled for user equivalence, set the environment variable DISPLAY to a valid X Windows display.
Bourne, Korn, and Bash Shells
After setting the DISPLAY variable to a valid X Windows display, you should perform another test of the current terminal session to ensure that X11 forwarding is not enabled.
Note that having X11 Forwarding enabled will cause most GUI applications to fail. To correct this problem, create a user-level SSH client configuration file for the OS user account (oracle) that disables X11 Forwarding.
Using a text editor, edit or create the file ~/.ssh/config
Make sure that the ForwardX11 attribute is set to no. For example, insert the following into the ~/.ssh/config file:
Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.
Copyright (c) 1998-2018 Jeffrey M. Hunter. All rights reserved.
All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at firstname.lastname@example.org.
I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.
Last modified on
Thursday, 02-Feb-2012 15:34:18 EST
Page Count: 12947