SSH Communications

From Documentation

The COSmanager Framework version 4.2 and later optionally support ssh as their communications method rather than rsh (Remote Shell). However, its configuration requires more effort, because keys for the cosmos user must be generated and copied to the remote hosts. This process must be repeated for each host on which COSmanager is installed.

The following commands assume that you are running a reasonably modern version of ssh which supports ‘protocol version 2’, and the ‘DSA algorithm’. They also assume that the ssh package has been installed correctly on your hosts, and that the sshd daemon process is running on each.

To allow COSmanager on host ‘hostA’ to run remote COSmanager commands on ‘hostB’, follow the following instructions:

#On ‘hostB’, login as root, and run: su cosmos 
#Type the command ‘id’ to make sure that your user ID is ‘cosmos’. 
#Generate a dsa public key/private key pair: ssh-keygen -t dsa or ssh-keygen -d 

If you get the message ‘not found’, check that the SSH ‘bin’ directory is in your shell's path, and if not add it.

This command should generate a ‘dsa’ private/public key pair for user cosmos. Hit ENTER to accept all default value when it asks for the file name to save the key, and also hit ENTER each time you are asked for a passphrase (we do NOT want to use a passphrase).

This should create the files:

;~cosmos/.ssh/id_dsa 
;~cosmos/.ssh/id_dsa.pub 
;~cosmos/.ssh 

Copy the file ‘id_dsa.pub’ to a temporary directory on ‘hostA’. This file will be accessed later when you log onto hostA.

Login in as your normal user ID (assumed to be registered to COSmanager as a ‘Manager’), and run: cos cosmos -C This should bring up the ‘COSmanager Global Configuration’ window.

Double-click on ‘Hosts’, and a list of COSmanager hosts should appear in another window. Double-click on ‘hostA’, and when the form appears, change the ‘Comm method’ field to ‘ssh’. Hit Accept to save the change. If ‘hostA’ is NOT in the list, select ‘Maintain > Add’, and add an entry for hostA, with the ‘Comm method’ field set to ‘ssh’.

Login to hostA as ROOT, and run: su cosmos Run the command: ssh-keygen -t dsa or ssh-keygen -d to generate the keys for hostA.

Change to the ~cosmos/.ssh directory and append the copy of id_dsa.pub copied from hostB (NOT the one in the local directory which was just created by the ssh-keygen command) to the file ‘authorized_keys2’. If ‘authorized_keys2’ does not exist simply copy the id_dsa.pub file from hostB to it. This allows the ‘cosmos’ user on hostB to run a command as user ‘cosmos’ on hostA.

ssh is very fussy about the permissions and ownerships of the files in the .ssh directory, and the ~cosmos and ~cosmos/.ssh directories themselves. Ensure that they are all owned by user "cosmos" and that the permissions are:

~cosmos drwxr-xr-x (755) ~cosmos/.ssh drwxr-xr-x (755) ~cosmos/.ssh/authorized_keys2 -rw------- (600) ~cosmos/.ssh/id_dsa -rw------- (600) ~cosmos/.ssh/id_dsa.pub -rw-r--r-- (644)

Copy the file id_dsa.pub from the .ssh directory to a temporary directory on hostB.

Now go back to hostB, login as ROOT, run: su cosmos and then try the command: ssh hostA pwd (of course the ‘ssh’ program must be in a directory in your search path). When run for the first times to a new host, ssh may say that the host cannot be authenticated, and will ask you if you want to connect. Reply "yes". ssh should add hostA to list of known hosts (file known_hosts2), and you should never be asked again.

If the ~cosmos directory name is NOT returned, then you have a problem! It may be that the public key was not copied into authorized_keys2 correctly, or that the permissions or ownerships of some ssh files are not correct. The easiest way of debugging is to kill the sshd process on the other host (hostA), and run in in DEBUG mode (as root): sshd -Dddd This will NOT start it as a daemon, and will give a lot of debugging information, which should help you pinpoint the problem. Note: sshd will probably NOT be in your search path. Some common locations for it are: /sbin /usr/sbin /usr/local/sbin You will probaly need to use the full pathname when running it. Note: killing sshd is probably not a good idea if other people or applications are using ssh to that host.

Finally, you must go back to hostA, and repeat steps e & f, this time using hostB rather than hostA. Then login as ROOT, run ‘su cosmos’ and repeat steps i through l, using hostB instead of hostA.

Congratulations, COSmanager is now configured to use ssh in both directions between hostA and hostB.

Note: If you are using an older version of ssh, which does not support protocol version 2, you should follow the above instructions, except the filenames under the .ssh directory are different:

id_dsa == identity id_dsa.pub == identity.pub authorized_keys2 == authorized_keys known_hosts2 == known_hosts

There is also an ssh configuration file often found in /etc/ssh/ssh_config. In this file you can effectively force ssh to use either protocol 1 or protocol 2 by specifying the identity file. Normally no identity file should be specified as ssh is smart enough to determine which to use in any given situation. If you are having problems configuring ssh to use protocol 2 (symptoms include falling back to password authentication even though the keys have been exchanged correctly), check this file and comment out the IdentityFile line:

1. IdentityFile ~/.ssh/identity