FS
Documentation

COSmanager FAQ

This page was last modified 02:35, 6 August 2007.

From Documentation

(Difference between revisions)
Jump to: navigation, search
Revision as of 03:37, 4 October 2006
Daniels (Talk | contribs)
(Schedule: Daily - except Thursday Friday)
← Previous diff
Current revision
Moff (Talk | contribs)
(How do I configure SSH communications?)
Line 80: Line 80:
=== How do I configure SSH communications? === === How do I configure SSH communications? ===
-When COSmanager is installed a cosmos user is created, and this user needs to be configured at an OS level to use ssh. The end result is that as the cosmos user on HostA you can run ‘ssh HostB <command>(and vice versa) without entering a passphrase.+When [[COSmanager]] is installed a <var>cosmos</var> user is created, and this user needs to be configured at an OS level to use ssh. The end result is that as the cosmos user on HostA you can run <code>ssh HostB <var>&lt;command&gt;</var></code> (and vice versa) without entering a passphrase.
-The COSmanager Framework version 4.1 and later optionally support ssh as their communications. However, its configuration requires some 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 COSmanager Framework version 4.1 and later optionally support ssh as their communications. However, its configuration requires some effort, because keys for the <var>cosmos</var> 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.+The following commands assume that you are running a reasonably modern version of ssh which supports <var>protocol version 2</var>, and the <var>DSA algorithm</var>. 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:+To allow COSmanager on host <var>hostA</var> to run remote COSmanager commands on <var>hostB</var>, follow the following instructions:
-#On ‘hostB’, login as root, and run: su cosmos+#On <var>hostB</var>, login as <small>root</small>, and run: <code>su cosmos</code>
-#Type the command ‘id’ to make sure that your user ID is ‘cosmos’.+#Type the command <code>id</code> to make sure that your user ID is <var>cosmos</var>.
-#Generate a dsa public key/private key pair: ssh-keygen -t dsa or ssh-keygen -d+#Generate a dsa public key/private key pair: <code>ssh-keygen -t dsa or ssh-keygen -d</code>
-If you get the message ‘not found’, check that the SSH ‘bin’ directory is in your shell's path, and if not add it.+If you get the message ‘not found’, check that the SSH <tt>bin</tt> 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 command should generate a <var>dsa</var> private/public key pair for user <var>cosmos</var>. Hit <big>Enter</big> to accept all default value when it asks for the file name to save the key, and also hit <big>Enter</big> each time you are asked for a passphrase (we do NOT want to use a passphrase).
This should create the files: This should create the files:
-*~cosmos/.ssh/id_dsa+*<tt>~cosmos/.ssh/id_dsa</tt>
-*~cosmos/.ssh/id_dsa.pub+*<tt>~cosmos/.ssh/id_dsa.pub</tt>
-*~cosmos/.ssh+*<tt>~cosmos/.ssh</tt>
-Copy the file ‘id_dsa.pub’ to a temporary directory on ‘hostA’. This file will be accessed later when you log onto hostA.+Copy the file <var>id_dsa.pub</var> to a temporary directory on <var>hostA</var>. This file will be accessed later when you log onto <var>hostA</var>.
-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.+Login in as your normal user ID (assumed to be registered to COSmanager as a <var>Manager</var>), and run: <code>cos cosmos -C</code>. This should bring up the <var>COSmanager Global Configuration</var> 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’.+Double-click on <big>Hosts</big>, and a list of COSmanager hosts should appear in another window. Double-click on <var>hostA</var>, and when the form appears, change the <em>Comm method</em> field to <var>ssh</var>. Hit <big>Accept</big> to save the change. If <var>hostA</var> is NOT in the list, select <cite>Maintain > Add</cite>, and add an entry for hostA, with the <em>Comm method</em> field set to <var>ssh</var>.
-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.+Login to <var>hostA</var> as <small>Root</small>, and run: <code>su cosmos</code> then <code>ssh-keygen -t dsa</code> or <code>ssh-keygen -d</code> 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.+Change to the <tt>~cosmos/.ssh</tt> directory and append the copy of <tt>id_dsa.pub</tt> copied from <var>hostB</var> (NOT the one in the local directory which was just created by the ssh-keygen command) to the file <tt>authorized_keys2</tt>. If <tt>authorized_keys2</tt> does not exist simply copy the <tt>id_dsa.pub</tt> file from <var>hostB</var> to it. This allows the <small>cosmos</small> user on hostB to run a command as user <small>cosmos</small> on hostA.
-ssh is very fussy about the permissions and ownerships of the files in the .ssh directory, and the ~cosmos & ~cosmos/.ssh directories themselves. Ensure that they are all owned by user "cosmos" and that the permissions are:+ssh is very fussy about the permissions and ownerships of the files in the <tt>.ssh</tt> directory, and the <tt>~cosmos</tt> & <tt>~cosmos/.ssh</tt> directories themselves. Ensure that they are all owned by user <small>cosmos</small> and that the permissions are:
 +<pre>
 +~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)
 +</pre>
- ~cosmos drwxr-xr-x (755)+Copy the file <tt>id_dsa.pub</tt> from the <tt>.ssh</tt> directory to a temporary directory on <var>hostB</var>.
- ~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 <var>hostB</var>, login as <small>Root</small>, run: <code>su cosmos</code> and then try the command: <code>ssh <var>hostA</var> pwd</code> (of course the <tt>ssh</tt> 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 <tt>known_hosts2</tt>), and you should never be asked again.
-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 <tt>~cosmos</tt> directory name is NOT returned, then you have a problem! It may be that the public key was not copied into <tt>authorized_keys2</tt> 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 (<var>hostA</var>), and run in in DEBUG mode (as root): <code>sshd -Dddd</code> 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:
 +<tt>/sbin</tt><br>
 +<tt>/usr/sbin</tt><br>
 +<tt>/usr/local/sbin</tt>
 +}}
-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: +You will probably need to use the full pathname when running it.
- /sbin+{{note|Killing sshd is probably not a good idea if other people or applications are using ssh to that host.}}
- /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 <var>hostA</var>, and repeat steps e & f, this time using <var>hostB</var> rather than <var>hostA</var>. Then login as <small>root</small>, run <code>su cosmos</code> and repeat steps i through l, using hostB instead of hostA.
- +
-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 & hostB. Congratulations, COSmanager is now configured to use ssh in both directions between hostA & 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 <tt>.ssh</tt> directory are different:
 +<pre>id_dsa == identity
 +id_dsa.pub == identity.pub
 +authorized_keys2 == authorized_keys
 +known_hosts2 == known_hosts</pre>
 +}}
-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: +There is also an ssh configuration file often found in <tt>/etc/ssh/ssh_config</tt>. 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:
- 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: +<tt># IdentityFile ~/.ssh/identity</tt>
- # IdentityFile ~/.ssh/identity+
Once this is complete you can configure COSmanager to use ssh: Once this is complete you can configure COSmanager to use ssh:
-#Start COSmanager configuration (cos cosmos -C from the command line, or click on Config > COSmanager configuration) and double click on the hosts icon.+#Start COSmanager configuration: <code>cos cosmos -C</code> from the command line, or click on <cite>Config > COSmanager configuration</cite> and double click on the <big>hosts</big> icon.
#Select the remote host that you wish to access via ssh and double click it to modify its configuration. #Select the remote host that you wish to access via ssh and double click it to modify its configuration.
-#Change the ‘comm meth’ field to ssh.+#Change the <em>comm meth</em> field to <var>ssh</var>.
-#Test your connectivity by clicking on the Planet icon on the button bar and select ‘Remote‘.+#Test your connectivity by clicking on the <big>Planet icon</big> on the button bar and select <cite>Remote</cite>.
#Choose the host you just configured. You should see the button bar for the remote host. #Choose the host you just configured. You should see the button bar for the remote host.
#Repeat this process to allow access from HostB back to HostA. #Repeat this process to allow access from HostB back to HostA.
-=== How does COSmanager's remote system management affect the security of remotely managed systems? ===+=== How does [[COSmanager]]'s remote system management affect the security of remotely managed systems? ===
To answer this it is necessary to explain how COSmanager manages those systems. To answer this it is necessary to explain how COSmanager manages those systems.
-For the purpose of system management, COSmanager defines a host as either a Master, a Remote or a Slave. A Master can administer any other host configured as Remote or Slave. A Remote system is another Master on the same network. This enables arbitary management domains to be defined.+For the purpose of system management, COSmanager defines a host as either a <em>Master</em>, a <em>Remote</em> or a <em>Slave</em>. A Master can administer any other host configured as Remote or Slave. A Remote system is another Master on the same network. This enables arbitary management domains to be defined.
-To administer a Slave host, a Master executes commands through a local program called FSremote. This program looks up a communication method, in the comm_meth table, and uses this to execute the command via the <b>cos</b> command on the Slave. The Slave will reject requests from hosts that are not pre-configured in COSmanager.+To administer a Slave host, a Master executes commands through a local program called <tt>FSremote</tt>. This program looks up a communication method, in the <em>comm_meth</em> table, and uses this to execute the command via the <tt>cos</tt> command on the Slave. The Slave will reject requests from hosts that are not pre-configured in COSmanager.
-The standard communication method uses a proprietary protocol implemented by <b>FSremote</b> and <b>COSserver</b> on a fixed, private TCP port. Alternatively <b>rsh</b> or <b>ssh</b> protocols can be used. Neither the <b>rsh</b> nor the proprietary protocol encrypt data, but they do <b>not</b> transmit the user's password across the network. <b>Ssh</b> provides encryption at the expense of speed and being more time consuming to set up.+The standard communication method uses a proprietary protocol implemented by <tt>FSremote</tt> and <tt>COSserver</tt> on a fixed, private TCP port. Alternatively <tt>rsh</tt> or <tt>ssh</tt> protocols can be used. Neither the <tt>rsh</tt> nor the proprietary protocol encrypt data, but they do <strong>not</strong> transmit the user's password across the network. <tt>Ssh</tt> provides encryption at the expense of speed and being more time consuming to set up.
-The command, <b>cos</b>, is a set UID root program used to either start COSmanager or execute a command passed as a parameter. This is because root access is required to perform most System Management activities under Unix and Linux. Under normal usage, the <b>cos</b> command performs security checks to validate the user ID and check that they are authorised to use COSmanager, that they have the appropriate <b>capabilities</b> to perform the request.+The command, <tt>cos</tt>, is a set UID root program used to either start COSmanager or execute a command passed as a parameter. This is because root access is required to perform most System Management activities under Unix and Linux. Under normal usage, the <tt>cos</tt> command performs security checks to validate the user ID and check that they are authorised to use COSmanager, that they have the appropriate <i>capabilities</i> to perform the request.
-When a COSmanager Master executes a request via FSremote to a Slave, the <b>cos</b> command on the Slave is invoked. This ensures that the user on the Master is allowed to run that System Management task. However, because the Slave trusts requests from its Master, and assumes that the Master has already authenticated the user, much of the authentication on the Slave is bypassed. In particular, if a user on the Master can get a cosmos or a root shell, then they can remotely execute any command on any Slave as root. This means that root on the Master system has root privileges on all the Slave systems. Most products currently available on the market are susceptable to the same problem.+When a COSmanager Master executes a request via FSremote to a Slave, the <tt>cos</tt> command on the Slave is invoked. This ensures that the user on the Master is allowed to run that System Management task. However, because the Slave trusts requests from its Master, and assumes that the Master has already authenticated the user, much of the authentication on the Slave is bypassed. In particular, if a user on the Master can get a cosmos or a root shell, then they can remotely execute any command on any Slave as root. This means that root on the Master system has root privileges on all the Slave systems. Most products currently available on the market are susceptable to the same problem.
By ensuring that the root account on COSmanager Master is protected from unauthorised use, COSmanager does not introduce further security risks to a network. COSmanager facilitates this by enabling the use of the root account to be minimised. By ensuring that the root account on COSmanager Master is protected from unauthorised use, COSmanager does not introduce further security risks to a network. COSmanager facilitates this by enabling the use of the root account to be minimised.

Current revision

Contents

Scheduler (for Version 4.x Applications and Newer)

These Schedule Definitions are valid for COSmanager Framework versions 4 or newer. The Schedules for older versions of the products will still work.

Schedule: Daily - except Thursday Friday

  1. Config > COSmanager configuration > Other tables > schedule
  2. select "70 Daily - except Thursday" > Maintain > Clone
  3. change Order to 75
  4. change Schedule name to "Daily - except Thursday Friday"
  5. press choose on Day(s) and use Ctrl-click to select all days EXCEPT Thursday and Friday
  6. press Accept

Note: the above steps can be followed for any combination of days.

Scheduler (for Version 3.x Applications and Newer)

These Schedules are valid for all current versions of COSmanager Suite products.

How do I define a scheduled time for the last Friday of the month?

Set up a new scheduled time as follows:

Ord:nnn
When:Monthly - last Friday
Schedule Cmd:D1=`cal | tail -c4` ; D2=`expr $D1 - 7` ; db_datemat -d$D2-$D1 -w5 $Today $Start
Crontab string:* * 5
Check cron:yes

On some platforms the flag to tail the command may have to be... tail -4c

How do I define a scheduled time for the last working day of the month

Setup new scheduled time as follows:

Ord:nnn
When:Monthly - last working day
Schedule Cmd:day=`cal | tail -c4` ; last="`date +%Y%m$day`" ; [ "`db_date`" -eq "`db_datemat -p -b -w1-5 $last`" ]
Crontab string:* * *
Check cron:yes

On some platforms the flag to the tail command may have to be ... tail -4c

How do I define a scheduled time for once a fortnight

Setup new scheduled time based on the following:

Example: schedule time for the first Monday each fortnight:

Ord:nnn
When:Fortnightly - 1st Monday
Schedule Cmd:WK=`date +%U` db_datemat -w1 && [ 1 -eq `expr $WK % 2` ]
Crontab string:* * 1
Check cron:yes

Example: schedule time for the second Wednesday each fortnight:

Ord:nnn
When:Fortnightly - 2nd Wednesday
Schedule Cmd:WK=`date +%U` db_datemat -w3 && [ 0 -eq `expr $WK % 2` ]
Crontab string:* * 3
Check cron:yes

Explanation of example Schedule Commands above:

WK=`date +%U` gets the week number for today.
db_datemat -w3 returns true if today is Wednesday. -w0 is Sunday, -w6 is Saturday.
`expr $WK % 2` returns a modulo 2 number, 1 for the first week in a fortnight, and 0 for the second.

How do I define a scheduled time for the last Friday of June and December (6 monthly)

Setup new scheduled time as follows:

Ord:nnn
When:June, Dec - last Friday
Schedule Cmd:D1=`cal | tail -c4` ; D2=`expr $D1 - 7` ; db_datemat -m6,12 -d$D2-$D1 -w5 $Today $Start
Crontab string:* * 5
Check cron:yes

On some platforms the flag to the tail command may have to be ... tail -4c


General Questions

How do I configure SSH communications?

When COSmanager is installed a cosmos user is created, and this user needs to be configured at an OS level to use ssh. The end result is that as the cosmos user on HostA you can run ssh HostB <command> (and vice versa) without entering a passphrase.

The COSmanager Framework version 4.1 and later optionally support ssh as their communications. However, its configuration requires some 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:

  1. On hostB, login as root, and run: su cosmos
  2. Type the command id to make sure that your user ID is cosmos.
  3. 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:

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 then 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 & ~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
Note
sshd will probably NOT be in your search path. Some common locations for it are:

/sbin
/usr/sbin
/usr/local/sbin

You will probably need to use the full pathname when running it.

Note
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 & hostB.

Note
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:

# IdentityFile ~/.ssh/identity

Once this is complete you can configure COSmanager to use ssh:

  1. Start COSmanager configuration: cos cosmos -C from the command line, or click on Config > COSmanager configuration and double click on the hosts icon.
  2. Select the remote host that you wish to access via ssh and double click it to modify its configuration.
  3. Change the comm meth field to ssh.
  4. Test your connectivity by clicking on the Planet icon on the button bar and select Remote.
  5. Choose the host you just configured. You should see the button bar for the remote host.
  6. Repeat this process to allow access from HostB back to HostA.

How does COSmanager's remote system management affect the security of remotely managed systems?

To answer this it is necessary to explain how COSmanager manages those systems.

For the purpose of system management, COSmanager defines a host as either a Master, a Remote or a Slave. A Master can administer any other host configured as Remote or Slave. A Remote system is another Master on the same network. This enables arbitary management domains to be defined.

To administer a Slave host, a Master executes commands through a local program called FSremote. This program looks up a communication method, in the comm_meth table, and uses this to execute the command via the cos command on the Slave. The Slave will reject requests from hosts that are not pre-configured in COSmanager.

The standard communication method uses a proprietary protocol implemented by FSremote and COSserver on a fixed, private TCP port. Alternatively rsh or ssh protocols can be used. Neither the rsh nor the proprietary protocol encrypt data, but they do not transmit the user's password across the network. Ssh provides encryption at the expense of speed and being more time consuming to set up.

The command, cos, is a set UID root program used to either start COSmanager or execute a command passed as a parameter. This is because root access is required to perform most System Management activities under Unix and Linux. Under normal usage, the cos command performs security checks to validate the user ID and check that they are authorised to use COSmanager, that they have the appropriate capabilities to perform the request.

When a COSmanager Master executes a request via FSremote to a Slave, the cos command on the Slave is invoked. This ensures that the user on the Master is allowed to run that System Management task. However, because the Slave trusts requests from its Master, and assumes that the Master has already authenticated the user, much of the authentication on the Slave is bypassed. In particular, if a user on the Master can get a cosmos or a root shell, then they can remotely execute any command on any Slave as root. This means that root on the Master system has root privileges on all the Slave systems. Most products currently available on the market are susceptable to the same problem.

By ensuring that the root account on COSmanager Master is protected from unauthorised use, COSmanager does not introduce further security risks to a network. COSmanager facilitates this by enabling the use of the root account to be minimised.