Tuesday, February 2, 2016

Setting up ssh on oracle RAC node without password

This was tried using oracle's provided utility (sshUserSetup.sh). Help is available under 

./sshUserSetup.sh -help

I have tried is under oracle user with

./sshUserSetup.sh -user oracle -hosts "rac1 rac2" -noPromptPassphrase

But this will not configure it properly.

In order to configure it right, we need to run this from root user with following options:

[root@rac2 sshsetup]# ./sshUserSetup.sh -user oracle -hosts "rac1 rac2" -advanced -exverify -noPromptPassphrase


After this it would work fine.

Just for record below is the information from where I ran this utility.

[root@rac2 sshsetup]# pwd
/media/sf_vshare/12.1.0.2/grid/sshsetup
[root@rac2 sshsetup]#
[root@rac2 sshsetup]# ls -lah
total 36K
drwxrwx---. 1 root vboxsf    0 Jul  8  2014 .
drwxrwx---. 1 root vboxsf 4.0K Jul  8  2014 ..
-rwxrwx---. 1 root vboxsf  32K Jun  7  2013 sshUserSetup.sh
[root@rac2 sshsetup]# 


[root@rac2 sshsetup]# ./sshUserSetup.sh -user oracle -hosts "rac1 rac2" -advanced -exverify -noPromptPassphrase
The output of this script is also logged into /tmp/sshUserSetup_2016-02-02-11-18-52.log
Hosts are rac1 rac2
user is oracle
Platform:- Linux
Checking if the remote hosts are reachable
PING rac1.localdomain (192.168.56.101) 56(84) bytes of data.
64 bytes from rac1.localdomain (192.168.56.101): icmp_seq=1 ttl=64 time=0.211 ms
64 bytes from rac1.localdomain (192.168.56.101): icmp_seq=2 ttl=64 time=0.410 ms
64 bytes from rac1.localdomain (192.168.56.101): icmp_seq=3 ttl=64 time=0.403 ms
64 bytes from rac1.localdomain (192.168.56.101): icmp_seq=4 ttl=64 time=0.407 ms
64 bytes from rac1.localdomain (192.168.56.101): icmp_seq=5 ttl=64 time=0.353 ms
--- rac1.localdomain ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.211/0.356/0.410/0.079 ms
PING rac2.localdomain (192.168.56.102) 56(84) bytes of data.
64 bytes from rac2.localdomain (192.168.56.102): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from rac2.localdomain (192.168.56.102): icmp_seq=2 ttl=64 time=0.035 ms
64 bytes from rac2.localdomain (192.168.56.102): icmp_seq=3 ttl=64 time=0.036 ms
64 bytes from rac2.localdomain (192.168.56.102): icmp_seq=4 ttl=64 time=0.036 ms
64 bytes from rac2.localdomain (192.168.56.102): icmp_seq=5 ttl=64 time=0.034 ms
--- rac2.localdomain ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.018/0.031/0.036/0.009 ms
Remote host reachability check succeeded.
The following hosts are reachable: rac1 rac2.
The following hosts are not reachable: .
All hosts are reachable. Proceeding further...
firsthost rac1
numhosts 2
The script will setup SSH connectivity from the host rac2.localdomain to all
the remote hosts. After the script is executed, the user can use SSH to run
commands on the remote hosts or copy files between this host rac2.localdomain
and the remote hosts without being prompted for passwords or confirmations.
NOTE 1:
As part of the setup procedure, this script will use ssh and scp to copy
files between the local host and the remote hosts. Since the script does not
store passwords, you may be prompted for the passwords during the execution of
the script whenever ssh or scp is invoked.
NOTE 2:
AS PER SSH REQUIREMENTS, THIS SCRIPT WILL SECURE THE USER HOME DIRECTORY
AND THE .ssh DIRECTORY BY REVOKING GROUP AND WORLD WRITE PRIVILEDGES TO THESE
directories.
Do you want to continue and let the script make the above mentioned changes (yes/no)?
yes
The user chose yes
User chose to skip passphrase related questions.
Creating .ssh directory on local host, if not present already
Creating authorized_keys file on local host
Changing permissions on authorized_keys to 644 on local host
Creating known_hosts file on local host
Changing permissions on known_hosts to 644 on local host
Creating config file on local host
If a config file exists already at /root/.ssh/config, it would be backed up to /root/.ssh/config.backup.
Creating .ssh directory and setting permissions on remote host rac1
THE SCRIPT WOULD ALSO BE REVOKING WRITE PERMISSIONS FOR group AND others ON THE HOME DIRECTORY FOR oracle. THIS IS AN SSH REQUIREMENT.
The script would create ~oracle/.ssh/config file on remote host rac1. If a config file exists already at ~oracle/.ssh/config, it would be backed up to ~oracle/.ssh/config.backup.
The user may be prompted for a password here since the script would be running SSH on host rac1.
Warning: Permanently added 'rac1,192.168.56.101' (RSA) to the list of known hosts.
oracle@rac1's password:
Done with creating .ssh directory and setting permissions on remote host rac1.
Creating .ssh directory and setting permissions on remote host rac2
THE SCRIPT WOULD ALSO BE REVOKING WRITE PERMISSIONS FOR group AND others ON THE HOME DIRECTORY FOR oracle. THIS IS AN SSH REQUIREMENT.
The script would create ~oracle/.ssh/config file on remote host rac2. If a config file exists already at ~oracle/.ssh/config, it would be backed up to ~oracle/.ssh/config.backup.
The user may be prompted for a password here since the script would be running SSH on host rac2.
Warning: Permanently added 'rac2,192.168.56.102' (RSA) to the list of known hosts.
oracle@rac2's password:
Done with creating .ssh directory and setting permissions on remote host rac2.
Copying local host public key to the remote host rac1
The user may be prompted for a password or passphrase here since the script would be using SCP for host rac1.
oracle@rac1's password:
Done copying local host public key to the remote host rac1
Copying local host public key to the remote host rac2
The user may be prompted for a password or passphrase here since the script would be using SCP for host rac2.
oracle@rac2's password:
Done copying local host public key to the remote host rac2
Creating keys on remote host rac1 if they do not exist already. This is required to setup SSH on host rac1.
Generating public/private rsa key pair.
Your identification has been saved in .ssh/id_rsa.
Your public key has been saved in .ssh/id_rsa.pub.
The key fingerprint is:
91:bc:de:26:12:39:27:b6:2f:f6:8a:8f:a5:97:dc:be oracle@rac1.localdomain
The key's randomart image is:
+--[ RSA 1024]----+
|                 |
|       . .       |
|        +        |
|       . o       |
|      * S        |
|     . B .       |
|     .+oo o      |
|     =*o.o       |
|    ++o=E.       |
+-----------------+
Creating keys on remote host rac2 if they do not exist already. This is required to setup SSH on host rac2.
Generating public/private rsa key pair.
Your identification has been saved in .ssh/id_rsa.
Your public key has been saved in .ssh/id_rsa.pub.
The key fingerprint is:
ff:9e:4d:56:d4:d8:bb:08:93:d4:52:c0:8d:5b:14:2b oracle@rac2.localdomain
The key's randomart image is:
+--[ RSA 1024]----+
|          ..=+.  |
|           ooo.o.|
|           Eoo. +|
|          ..+  ..|
|        S  +   ..|
|         .  o ...|
|          .  .o. |
|           . =   |
|           .+ .  |
+-----------------+
Updating authorized_keys file on remote host rac1
Updating known_hosts file on remote host rac1
Updating authorized_keys file on remote host rac2
Updating known_hosts file on remote host rac2
SSH setup is complete.
------------------------------------------------------------------------
Verifying SSH setup
===================
The script will now run the date command on the remote nodes using ssh
to verify if ssh is setup correctly. IF THE SETUP IS CORRECTLY SETUP,
THERE SHOULD BE NO OUTPUT OTHER THAN THE DATE AND SSH SHOULD NOT ASK FOR
PASSWORDS. If you see any output other than date or are prompted for the
password, ssh is not setup correctly and you will need to resolve the
issue and set up ssh again.
The possible causes for failure could be:
1. The server settings in /etc/ssh/sshd_config file do not allow ssh
for user oracle.
2. The server may have disabled public key based authentication.
3. The client public key on the server may be outdated.
4. ~oracle or ~oracle/.ssh on the remote host may not be owned by oracle.
5. User may not have passed -shared option for shared remote users or
may be passing the -shared option for non-shared remote users.
6. If there is output in addition to the date, but no password is asked,
it may be a security alert shown as part of company policy. Append the
additional text to the <OMS HOME>/sysman/prov/resources/ignoreMessages.txt file.
------------------------------------------------------------------------
--rac1:--
Running /usr/bin/ssh -x -l oracle rac1 date to verify SSH connectivity has been setup from local host to rac1.
IF YOU SEE ANY OTHER OUTPUT BESIDES THE OUTPUT OF THE DATE COMMAND OR IF YOU ARE PROMPTED FOR A PASSWORD HERE, IT MEANS SSH SETUP HAS NOT BEEN SUCCESSFUL. Please note that being prompted for a passphrase may be OK but being prompted for a password is ERROR.
Tue Feb  2 11:19:15 AEDT 2016
------------------------------------------------------------------------
--rac2:--
Running /usr/bin/ssh -x -l oracle rac2 date to verify SSH connectivity has been setup from local host to rac2.
IF YOU SEE ANY OTHER OUTPUT BESIDES THE OUTPUT OF THE DATE COMMAND OR IF YOU ARE PROMPTED FOR A PASSWORD HERE, IT MEANS SSH SETUP HAS NOT BEEN SUCCESSFUL. Please note that being prompted for a passphrase may be OK but being prompted for a password is ERROR.
Tue Feb  2 11:19:16 AEDT 2016
------------------------------------------------------------------------
------------------------------------------------------------------------
Verifying SSH connectivity has been setup from rac1 to rac1
------------------------------------------------------------------------
IF YOU SEE ANY OTHER OUTPUT BESIDES THE OUTPUT OF THE DATE COMMAND OR IF YOU ARE PROMPTED FOR A PASSWORD HERE, IT MEANS SSH SETUP HAS NOT BEEN SUCCESSFUL.
Tue Feb  2 11:19:16 AEDT 2016
------------------------------------------------------------------------
------------------------------------------------------------------------
Verifying SSH connectivity has been setup from rac1 to rac2
------------------------------------------------------------------------
IF YOU SEE ANY OTHER OUTPUT BESIDES THE OUTPUT OF THE DATE COMMAND OR IF YOU ARE PROMPTED FOR A PASSWORD HERE, IT MEANS SSH SETUP HAS NOT BEEN SUCCESSFUL.
Tue Feb  2 11:19:17 AEDT 2016
------------------------------------------------------------------------
-Verification from rac1 complete-
------------------------------------------------------------------------
Verifying SSH connectivity has been setup from rac2 to rac1
------------------------------------------------------------------------
IF YOU SEE ANY OTHER OUTPUT BESIDES THE OUTPUT OF THE DATE COMMAND OR IF YOU ARE PROMPTED FOR A PASSWORD HERE, IT MEANS SSH SETUP HAS NOT BEEN SUCCESSFUL.
Tue Feb  2 11:19:18 AEDT 2016
------------------------------------------------------------------------
------------------------------------------------------------------------
Verifying SSH connectivity has been setup from rac2 to rac2
------------------------------------------------------------------------
IF YOU SEE ANY OTHER OUTPUT BESIDES THE OUTPUT OF THE DATE COMMAND OR IF YOU ARE PROMPTED FOR A PASSWORD HERE, IT MEANS SSH SETUP HAS NOT BEEN SUCCESSFUL.
Tue Feb  2 11:19:19 AEDT 2016
------------------------------------------------------------------------
-Verification from rac2 complete-
SSH verification complete.
[root@rac2 sshsetup]# 



Help can be accessed using:

[root@rac2 sshsetup]# ./sshUserSetup.sh -help
Usage ./sshUserSetup.sh -user <user name> [ -hosts "<space separated hostlist>" | -hostfile <absolute path of cluster configuration file> ] [ -advanced ]  [ -verify] [ -exverify ] [ -logfile <desired absolute path of logfile> ] [-confirm] [-shared] [-help] [-usePassphrase] [-noPromptPassphrase]
This script is used to setup SSH connectivity from the host on which it is run to the specified remote hosts. After this script is run, the user can use  SSH to run commands on the remote hosts or copy files between the local host and the remote hosts without being prompted for passwords or confirmations.  The list of remote hosts and the user name on the remote host is specified as a command line parameter to the script.
-user : User on remote hosts.
-hosts : Space separated remote hosts list.
-hostfile : The user can specify the host names either through the -hosts option or by specifying the absolute path of a cluster configuration file. A sample host file contents are below:
   stacg30 stacg30int 10.1.0.0 stacg30v  -
   stacg34 stacg34int 10.1.0.1 stacg34v  -
 The first column in each row of the host file will be used as the host name.
-usePassphrase : The user wants to set up passphrase to encrypt the private key on the local host.
-noPromptPassphrase : The user does not want to be prompted for passphrase related questions. This is for users who want the default behavior to be followed.
-shared : In case the user on the remote host has its home directory NFS mounted or shared across the remote hosts, this script should be used with -shared option.
  It is possible for the user to determine whether a user's home directory is shared or non-shared. Let us say we want to determine that user user1's home directory is shared across hosts A, B and C.
 Follow the following steps:
    1. On host A, touch ~user1/checkSharedHome.tmp
    2. On hosts B and C, ls -al ~user1/checkSharedHome.tmp
    3. If the file is present on hosts B and C in ~user1 directory and
       is identical on all hosts A, B, C, it means that the user's home
       directory is shared.
    4. On host A, rm -f ~user1/checkSharedHome.tmp
 In case the user accidentally passes -shared option for non-shared homes or viceversa,SSH connectivity would only be set up for a subset of the hosts. The user would have to re-run the setyp script with the correct option to rectify this problem.
-advanced :  Specifying the -advanced option on the command line would result in SSH  connectivity being setup among the remote hosts which means that SSH can be used to run commands on one remote host from the other remote host or copy files between the remote hosts without being prompted for passwords or confirmations.
-confirm: The script would remove write permissions on the remote hosts for the user home directory and ~/.ssh directory for group and others. This is an SSH requirement. The user would be explicitly informed about this by the script and prompted to continue. In case the user presses no, the script would exit. In case the user does not want to be prompted, he can use -confirm option.
As a part of the setup, the script would use SSH to create files within ~/.ssh directory of the remote node and to setup the requisite permissions. The script also uses SCP to copy the local host public key to the remote hosts so that the remote hosts trust the local host for SSH. At the time, the script performs these steps, SSH connectivity has not been completely setup  hence the script would prompt the user for the remote host password.
For each remote host, for remote users with non-shared homes this would be done once for SSH and  once for SCP. If the number of remote hosts are x, the user would be prompted  2x times for passwords. For remote users with shared homes, the user would be prompted only twice, once each for SCP and SSH.  For security reasons, the script does not save passwords and reuse it. Also, for security reasons, the script does not accept passwords redirected from a file. The user has to key in the confirmations and passwords at the prompts.
-verify : -verify option means that the user just wants to verify whether SSH has been set up. In this case, the script would not setup SSH but would only check whether SSH connectivity has been setup from the local host to the remote hosts. The script would run the date command on each remote host using SSH. In case the user is prompted for a password or sees a warning message for a particular host, it means SSH connectivity has not been setup correctly for that host.  In case the -verify option is not specified, the script would setup SSH and then do the verification as well.
-exverify : In case the user speciies the -exverify option, an exhaustive verification for all hosts would be done. In that case, the following would be checked:
   1. SSH connectivity from local host to all remote hosts.
   2. SSH connectivity from each remote host to itself and other remote hosts.
The -exverify option can be used in conjunction with the -verify option as well to do an exhaustive verification once the setup has been done.
Taking some examples: Let us say local host is Z, remote hosts are A,B and C. Local user is njerath. Remote users are racqa(non-shared), aime(shared).
./sshUserSetup.sh -user racqa -hosts "A B C" -advanced -exverify -confirm
Script would set up connectivity from Z -> A, Z -> B, Z -> C, A -> A, A -> B, A -> C, B -> A, B -> B, B -> C, C -> A, C -> B, C -> C.
Since user has given -exverify option, all these scenario would be verified too.
Now the user runs : ./sshUserSetup.sh -user racqa -hosts "A B C" -verify
Since -verify option is given, no SSH setup would be done, only verification of existing setup. Also, since -exverify or -advanced options are not given, script would only verify connectivity from Z -> A, Z -> B, Z -> C
Now the user runs : ./sshUserSetup.sh -user racqa -hosts "A B C" -verify -advanced
Since -verify option is given, no SSH setup would be done, only verification of existing setup. Also, since  -advanced options is given, script would verify connectivity from Z -> A, Z -> B, Z -> C, A-> A, A->B, A->C, A->D
Now the user runs:
./sshUserSetup.sh -user aime -hosts "A B C" -confirm -shared
Script would set up connectivity between  Z->A, Z->B, Z->C only since advanced option is not given.
All these scenarios would be verified too.
[root@rac2 sshsetup]#
[root@rac2 sshsetup]# 

No comments: