Configure SSH for User EquivalencePosted: 07/12/2010 | |
During the installation of Oracle RAC, OUI needs to copy files to and execute programs on the other nodes in the cluster. In order to allow OUI to do that, you must configure SSH to allow user equivalence. Establishing user equivalence with SSH provides a secure means of copying files and executing programs on other nodes in the cluster without requiring password prompts.
The first step is to generate public and private keys for SSH. There are two versions of the SSH protocol; version 1 uses RSA and version 2 uses DSA, so we will create both types of keys to ensure that SSH can use either version. The ssh-keygen program will generate public and private keys of either type depending upon the parameters passed to it.
When you run ssh-keygen, you will be prompted for a location to save the keys. Just press Enter when prompted to accept the default. You will then be prompted for a passphrase. Enter a password that you will remember and then enter it again to confirm. When you have completed the steps below, you will have four files in the ~/.ssh directory: id_rsa, id_rsa.pub, id_dsa, and id_dsa.pub. The id_rsa and id_dsa files are your private keys and must not be shared with anyone. The id_rsa.pub and id_dsa.pub files are your public keys and must be copied to each of the other nodes in the cluster.
From each node, logged in as oracle:
mkdir ~/.ssh chmod 755 ~/.ssh /usr/bin/ssh-keygen -t rsa
Cut and paste the following line separately:
/usr/bin/ssh-keygen -t dsa
Now the contents of the public key files id_rsa.pub and id_dsa.pub on each node must be copied to the ~/.ssh/authorized_keys file on every other node. Use ssh to copy the contents of each file to the ~/.ssh/authorized_keys file. Note that the first time you access a remote node with ssh its RSA key will be unknown and you will be prompted to confirm that you wish to connect to the node. SSH will record the RSA key for the remote nodes and will not prompt for this on subsequent connections to that node.
From the first node ONLY, logged in as oracle (copy the local account’s keys so that ssh to the local node will work):
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
Now copy the keys to the other node so that we can ssh to the remote node without being prompted for a password.
ssh oracle@ds2 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
(If you are cut and pasting these commands, run each of them separately. SSH will prompt for the oracle password each time and if the commands are pasted at the same time, the other commands will be lost when the first one flushes the input buffer prior to prompting for the password.)
ssh oracle@ds2 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys chmod 644 ~/.ssh/authorized_keys
Now do the same for the second node. Notice that this time SSH will prompt for the passphrase you used when creating the keys rather than the oracle password. This is because the first node (ds1) now knows the public keys for the second node and SSH is now using a different authentication protocol. Note, if you didn’t enter a passphrase when creating the keys with ssh-keygen, you will not be prompted for one here.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys ssh oracle@ds1 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys ssh oracle@ds1 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys chmod 644 ~/.ssh/authorized_keys
Establish User Equivalence
Finally, after all of the generating of keys, copying of files, and repeatedly entering passwords and passphrases (isn’t security fun?), you’re ready to establish user equivalence. When user equivalence is established, you won’t be prompted for a password again.
As oracle on the node where the Oracle 10g Release 2 software will be installed (ds1):
exec /usr/bin/ssh-agent $SHELL /usr/bin/ssh-add
(Note that user equivalence is established for the current session only. If you switch to a different session or log out and back in, you will have to run ssh-agent and ssh-add again to re-establish user equivalence.)
If everything is set up correctly, you can now use ssh to log in, execute programs, and copy files on the other cluster nodes without having to enter a password. Verify user equivalence by running a simple command like date on a remote cluster node:
$ ssh ds2 date Sat Jan 21 13:31:07 PST 2006
It is crucial that you test connectivity in each direction from all servers. That will ensure that messages like the one below do not occur when the OUI attempts to copy files during CRS and database software installation. This message will only occur the first time an operation on a remote node is performed, so by testing the connectivity, you not only ensure that remote operations work properly, you also complete the initial security key exchange.
The authenticity of host 'ds2 (192.168.200.52)' can't be established. RSA key fingerprint is 8f:a3:19:76:ca:4f:71:85:42:c2:7a:da:eb:53:76:85. Are you sure you want to continue connecting (yes/no)? yes
- Share on Facebook (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to share on Google+ (Opens in new window)
- Click to email (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to print (Opens in new window)