View Source

h4. This document describes the process of setting up the SSH connection for running plug-ins from the Nagios component of GroundWork. Once in place, you can easily monitor many aspects of your UNIX hosts as long as they are running SSH.

{html}
<h2>Setting up SSH Monitoring on UNIX Hosts for GroundWork</h2>
<a name="Introduction"></a>
<h3>Introduction</h3>
<p>This document describes the process of setting up the SSH connection for running plug-ins from the Nagios component of GroundWork. Once this access is in place, you can easily monitor many aspects of your UNIX hosts as long as they are running SSH.</p>
<p>You need this setting of authentication keys so that the plug-ins run in a secure mode as the user from the GroundWork server may avoid embedded passwords.</p>
<p>The username on the Monitored systems, for simplicity, can be "nagios" and if it is possible, assign a uid of "502". Neither is essential but it can simplify the installation of the keys and the plugins. <br /></p>
<p>The username on the Monitored systems can also be named "gwrk" or whatever. In this case it may be necessary to copy both the public key for user "gwrk" and for user "nagios" to the Monitored systems "gwrk" authorized_keys file.</p>
<a name="Monitored_System_Requirements"></a>
<h3>Monitored System Requirements</h3>
<table>
<tbody>
<tr>
<td width="120"><i><b>User Login</b></i></td>
<td>An ordinary user login to the target host(s)</td>
</tr>
<tr>
<td><i><b>Home Directory</b></i></td>
<td>A home directory on the target host(s)</td>
</tr>
<tr>
<td><i><b>Sshd</b></i></td>
<td>Sshd daemon running on the target host(s)</td>
</tr>
<tr>
<td><i><b>Public Keys</b></i></td>
<td>Public key authentication enabled on the target host(s)</td>
</tr>
</tbody>
</table>
<hr /><a name="Red_Hat_Linux"></a>
<h3>Red Hat Linux</h3>
<table width="924">
<tbody>
<tr>
<td>
<ul><li>Log in as root to the target server </li><li>Add the user, plus directory </li></ul>
<pre>useradd –m <username></pre>
<ul><li>Check that the user directory itself has permissions 755 </li></ul>
<p>(read-write-execute for owner, read-execute for group and for others)</p>
<pre>ls –lad /home/<username></pre>
<ul><li>Set the user password </li></ul>
<pre>passwd <username></pre>
<ul><li>Give the user a password consistent with local policy. </li><li>This should be the same password for all target systems to make it easy of the SE. </li></ul>
<pre>cd /etc/ssh<br /><br />vi sshd_config</pre>
<ul><li>locate entry for PubkeyAuthentication </li><li>Make sure that it is set to "yes" and is not commented out. </li><li>Save the file. </li><li>Restart the daemon. </li></ul>
<pre>service sshd restart</pre>
</td>
</tr>
</tbody>
</table>
<hr /><a name="Solaris"></a>
<h3>Solaris</h3>
<table width="926">
<tbody>
<tr>
<td>
<ul><li>Login in as root on the target server. </li><li>Add the user and the user's home directory </li></ul>
<pre>useradd -m <username></pre>
<ul><li>check permissions of the user's home directory. </li></ul>
<pre>ls -iald /home/<username></pre>
<p>or</p>
<pre>ls -iald /export/home/<username></pre>
<ul><li>If this client is using the autohome feature (one exported filesystem for all user home directories) there are some extra issues to deal with not covered here. The main issue is to configure so that all hosts are included for login privilege and that the actual home directory that all target hosts share is the one accessed for this setup process. </li></ul>
<ul><li>Give the user a password </li></ul>
<pre>passwd <username></pre>
<ul><li>Give the user a password consistent with local policy. </li><li>This should be the same password for all target systems to make it easy of the SE. </li><li>Go to the ssh configuration directory (could be one of these:)
<ul><li>/opt/csw/etc </li><li>/usr/local/etc </li></ul>
</li><li>Another was to find it: </li></ul>
<pre>find / -name sshd_config -print</pre>
<ul><li>Edit the file </li></ul>
<pre>vi sshd_config</pre>
<ul><li>locate entry for PubKeyAuthentication </li><li>Make sure that it is set to "yes" and is not commented out. </li><li>Save the file. </li><li>Restart the daemon. </li></ul>
<pre>/etc/init.d/sshd stop<br />/etc/init.d/sshd start</pre>
<ul><li>Notice that the sshd daemon stops and restarts with a new process id </li></ul>
<ul><li>If this is Solaris 8 then OpenSSL SSH is a Freeware addition (not a package). You will have to:
<ul><li>Get the source and install it on your system </li><li>Create an init script sshd for startup and shutdown and put it in /etc/init.d </li><li>Create links to that file in the appropriate state directories </li><li>Edit the sshd_config to disable role separation </li><li>Correctly set /etc/hosts.deny and /etc/hosts.allow with entries that permit the GroundWork server to access the ssh daemon. (There may be tcp wrapper issues) </li></ul>
</li></ul>
<p>At this point the client system is ready for GroundWork to create a public key for the user “gwrk” which will be connecting securely to execute agent plugins on the client system. The remaining steps are performed from the GroundWork server.</p>
</td>
</tr>
</tbody>
</table>
<a name="Groundwork"></a>
<h2>GroundWork</h2>
<p>This example will use the username “nagios”. Any valid username may be used, as long as the checkcommands.cfg file refers to the same user name in the check_by_ssh definitions.</p>
<table>
<tbody>
<tr>
<td>
<p>The example target host will be called "target".</p>
<ul><li>Log in to the GroundWork server as root, then become nagios </li></ul>
<pre>su - nagios</pre>
<ul><li>Check that you are in the directory /home/nagios </li></ul>
<ul><li>Create the public and private keys </li></ul>
<pre>ssh-keygen -t dsa -b 2048</pre>
<p></p>
<ul><li>Hit enter on the passphrase prompts three times.</li><li>Make sure the private key is locked down as owner, group “nagios” and permissions read write by owner only. If for some reason this is not so then make it so:</li></ul>
<pre>chmod 600 /home/nagios/.ssh/id_dsa<br />chown nagios:nagios /home/nagios/.ssh/id_dsa</pre>
<ul><li>Next, for each target, do the next 9 steps </li>
<ol start="1"><li>ssh to the target system. The First time you'll see a message about verifying the key, Enter yes and notice that the taget host has been added to the known hosts file. </li><li>Check that you are now in the home directory on the target. If not, there is a problem you have to fix before continuing with this target. Fix it and continue. </li><li>Create the libexec sub-directory under the users' home directory to hold the plugins. </li><li>Create the .ssh sub-directory under the users' home directory to hold the public and private keys. chmod it to 700. </li><li>Exit back to the GroundWork server. </li><li>Copy the plugins to the targets /home/<username>/libexec directory.
<ol start="1"><li>Be sure that they are the proper architecture for the target. </li><li>Check that they have the right protections to allow them to be executed by the <username> on the target server. </li></ol>
</li><li>Copy the PUBLIC side of the DSA key to the target </li>
<ol start="1"><li>Copy using: scp .ssh/id_dsa.pub <username>@target:/home/<username>/.ssh/authorized_keys </li><li>You may also copy the content of multiple id_dsa.pub files (e.g., for "gwrk" and for "nagios") using a cut and paste editor (these are text files). </li><li>The point is to get them into the target machine’s "nagios" .ssh home directory in a file named authorized_keys. </li><li>If this file already exists, or if there are multiple GW or other servers/users that will do ssh to this target, append the keys instead of overwriting the existing file. </li></ol>
<li>Test the connection from the GroundWork server with ssh. You should get in without a password prompt. </li><li>Test the plugins as nagios, to simulate Monitoring. </li></ol>
</ul>
</td>
</tr>
</tbody>
</table>

{html}