SiteScope User's Guide


SiteScope Monitoring via Secure Shell (SSH)

As network security is increasingly important, SiteScope supports a number of security capabilities. One of these is support for remote server monitoring using Secure Shell (SSH) connections. You can use SSH to connect to a server and automatically send a command, so that the server will run that command and then disconnect. This is useful for creating automated processing and scripting.

This section describes:

SiteScope and SSH

Secure Shell (SSH), sometimes known as Secure Socket Shell, is a UNIX-based command interface and protocol for securely getting access to a remote computer. It is widely used by network administrators to control Web and other kinds of servers remotely. SSH commands are encrypted and secure in several ways. Both ends of the client/server connection are authenticated using a digital certificate, and passwords are protected by encryption. Secure Shell client machines make requests of SSH daemons or servers on remote machines.

Monitoring with SiteScope over SSH has the following basic requirements:

  1. The servers that you want to have monitored by SiteScope using SSH need to have a SSH daemon (or server) installed and active
  2. The machine where SiteScope is running needs to be configured with a SSH client.

There are a number of possibilities and issues involved in using SSH for SiteScope Monitoring.

Beginning with the 7.8.1.1 release of SiteScope, there are two SSH client options for use on the server or machine where SiteScope is running. SiteScope now includes a SSH client written in Java and native to the SiteScope application code. This client eases the setup of SSH connections and generally uses fewer system resources than external SSH clients.

SiteScope for Windows also ships with a copy of the PuTTY SSH client and utilities. The PuTTY SSH client, plink.exe, has been used to enable SSH connectivity for SiteScope for Windows prior to the 7.8.1.1 release. SiteScope for Solaris and Redhat Linux make use of the SSH utilities normally bundled with those operating systems or available for download.

The following table outlines the SSH connectivity options currently supported with SiteScope. See the notes below the table for important information about configuring and managing SSH connectivity.

SiteScope Platform and Client Options

Monitored Server Platform and Daemon

Windows PuTTY SSH client (included with SiteScope) or

UNIX / Linux

SSH host daemon (sshd - either proprietary or OpenSSH)

SiteScope integrated Java SSH Client
UNIX / Linux SSH client (/usr/local/bin/ssh or usr/bin/ssh ) or

UNIX / Linux

SSH host daemon (sshd - either SunSSH, proprietary or OpenSSH)

SiteScope integrated Java SSH Client
Windows PuTTY SSH client (included with SiteScope) or

Windows

  1. SSH server (Cygwin OpenSSH or OpenSSH for Windows)
  2. RemoteNTSSH package (included with SiteScope), to be installed into the appropriate directory on the remote server)
SiteScope integrated Java SSH Client

The following are important notes regarding the use of SSH in general and specific to using SSH and SiteScope.

Notes:

  1. There are two different versions of the SSH protocol: version 1 and version 2. Version 1 and version 2 are different protocols and are not compatible with each other. This means that the SSH clients and SSH hosts must be configured to use the same protocol version between them in order to communicate. In many cases, SSH version 1 (SSH1) is the default version used. Some security vulnerabilities have been found in SSH version 1. Also, the SSH1 protocol is not being developed anymore and SSH2 is being considered the current standard. We recommend using SSH version 2 (SSH2) for all SSH connections.
  2. The release version number of the SSH utilities and libraries you have installed must not be confused with the version of the SSH protocol that you want to be using. For example, OpenSSH release 3.5 supports both SSH1 and SSH2 protocols. The release version 3.5 does not mean that the libraries are using a SSH version 3.5 protocol. You must configure the OpenSSH software to use either SSH1 or SSH2.
  3. If you have set up SiteScope remote monitoring using SSH connections and then you make configuration changes or upgrades to the SSH daemon or server software deployed on remote servers in the environment, it may be necessary to reconfigure the SSH connectivity between the machine where SiteScope is running and the remote servers that were been monitoring.
  4. The availability of the Integrated Java SSH Client is indicated via the drop-down lists menu in the SSH Connection Method of the SSH Advanced Options section of the Add Remote UNIX Server and Remote Windows Server pages. If the option for Internal Java Libraries does not appear in the list, you can still use the Plink external SSH Client for SSH connections. You can also contact a Mercury Interactive sales representative to upgrade to a later version of SiteScope that includes the Integrated Java SSH Client.

Index

Configuring Remote UNIX Servers for SSH Monitoring

SiteScope for Solaris or Linux supports remote monitoring via SSH. Setting up the SSH hosts on the remote servers you want to monitor in the UNIX environment can be very involved and is beyond the scope of this document. Some suggested resources on installation of the OpenSSH daemon are http://www.sunfreeware.com/openssh.html (for Solaris) and http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-ssh-configfiles.html for Redhat Linux

The following are requirements for configuring remote UNIX servers for SSH monitoring with SiteScope in a UNIX environment:

  • Secure Shell daemons or servers (sshd) must be installed on each remote server you want to monitor with SiteScope.
  • The SSH daemons on the remote servers must be running and the applicable communication ports must be open. For example, the default for SSH is port number 22.
  • A SSH client must be installed on the server where SiteScope is running. The SiteScope integrated Java SSH client will normally fill this requirement.
  • If you use an external SSH client on Solaris or Linux, the SSH client binaries must be accessible to SiteScope. When SiteScope invokes the SSH client process, it will search in both /usr/bin and /usr/local/bin for the ssh command. The ssh binaries must be in one of these two locations and SiteScope must have permissions to execute the ssh command.

You should verify SSH client-to-server connectivity from the machine where SiteScope is running to the remote machine you want to monitor. You should check SSH connectivity outside of the SiteScope application before setting up remote server connections using SSH in SiteScope. For example, if SiteScope is running on Solaris or Linux, using the following command line requests a ssh connection using SSH2 to the server remotehost:

ssh -2 remotehost

This normally will return text information that indicates the version of SSH protocol that is being used. Also, this will attempt to authenticate as the current user. Use the -l username switch to request a login as a different user.

For SiteScope running on Windows, see the section on Testing SSH connectivity with PuTTY utilities for information about testing SSH connectivity outside of the SiteScope application on Windows NT/2000 machines.

Once you have confirmed SSH connectivity, create or configure UNIX Remote settings in SiteScope to use SSH as the connection method.

Index

Configuring Remote Windows Servers for SSH Monitoring

The default remote connection method used by SiteScope for Windows-to-Windows connectivity and monitoring in Windows NT/2000/2003 networks is NetBIOS. While this has provided ease of connectivity, it does have several disadvantages. One is that NetBIOS is relatively vulnerable in terms of network security. Another is that it does not support remote execution scripts. Running commands on remote servers requires that scripts be executed locally with commands to the remote machine being written using the UNC syntax of remote servers. Even then, some parameters are not returned from the remote server via NetBIOS.

Starting with version 7.8, SiteScope supports monitoring of remote Windows NT/2000 servers using SSH. This technology has been tested with the OpenSSH binaries from Cygwin available at http://www.cygwin.com/ installed as the SSH server on the remote server. You may also try OpenSSH for Windows (formerly Network Simplicity "OpenSSH on Windows") which has been available on SourceForge. The following is an overview comparison of these two packages.

OpenSSH Package

Advantages

Disadvantage

Cygwin OpenSSH

  • Provides access to either Windows or UNIX-style scripting on a Windows machine
  • Provides access to UNIX-style system tools and utilities
  • SiteScope can access the remote server both as a Windows Remote an d/or a UNIX Remote

Complicated setup procedure

OpenSSH for Windows

  • Simple setup procedure

Only provides access to Windows commands, scripts, and utilities.

Note: OpenSSH for Windows and the Cygwin SSH implementations have been shown to be incompatible with each other and should not both be installed on the same machine.

Note: If there are more than one version of the Cygwin utilities or more than one SSH server installed a machine, there may be conflicts which prevent the SSH connections from working. An error message such as: "could not find entry point" is one indication of this kind of conflict. If you suspect this error, search the machine for multiple copies of cygwin1.dll. It may be necessary to remove all versions of the utilities and then reinstall only a single installation to resolve this problem.

There are two main steps for configuring remote Windows Servers for SSH monitoring with SiteScope:

  1. Installation and Configuration of a SSH Server
  2. Installation of SiteScope Remote NT SSH Files

1. Installation and Configuration of a SSH Server

In order to enable SiteScope monitoring using SSH, a SSH server must be installed and configured on each remote server to which you want SiteScope to connect. There are two software packages generally available that will enable SSH capability. One is the Cygwin environment available from RedHat at http://www.cygwin.com/. Another package is the OpenSSH for Windows available at OpenSSH for Windows. The following describes the steps to:

Note: These setup steps must be performed for each server that will run the SSH daemon or server.

Cygwin OpenSSH (on Windows)

To install and configure a Cygwin OpenSSH server on Windows NT/2000 servers

Note: The following instructions assume that no other Cygwin or other ssh utilities are installed on the machine and that the machine has Internet access.

Note: The user login account used to install and run the SSH daemon will need adequate permissions to install the necessary programs, configure several file options, and control Windows services. It does not need to be the account that SiteScope will use to connect to the subject server although that account must be configured within the Cygwin installation before you can monitor that server with SiteScope.

  1. Create a new System Environment variable with the following definition:
    CYGWIN = ntsec tty
  2. Add the string
    ;C:\cygwin\bin
    to your PATH variable. Save the changes to the variables.
  3. Download the Cygwin setup program into a temporary folder. For example: C:\temp. The setup program is used to select, download, and install different packages and components available with Cygwin.
  4. Run the downloaded setup program and choose the Install from Internet option when prompted to Choose A Download Source. Click Next to continue.
  5. If prompted, select a root install directory where the Cygwin package should be installed. This will be where the SSH daemon and related files will be installed. For example, C:\cygwin. Click Next to continue.
  6. If prompted, select a temporary directory where the Cygwin installation files should be stored. For example, C:\temp. Click Next to continue.
  7. If prompted, Select an Internet Connection option. Normally, Direct Connection can be used. Click Next to continue.
  8. Select a suitable mirror site from which to retrieve the files using the selection list when prompted. Click Next to continue.
  9. The Setup program queries the mirror site for the packages available and displays a hierarchy tree of package categories. To view and select the packages to download, click on the plus (+) symbol to the left of the Category name to expand any of the package trees. Packages that are selected for download and installation will display a version number in the New column. If a version number is not displayed for a particular package, it will not be downloaded and installed. Click on the word Skip to the left of package name to select the package for download.

    Note: Many of the development (Devel ) and database (Database) tools that may be selected by default for download are not necessary to run the SSH daemon and can be skipped (de-selected) to reduce download time and installation space.

    Be sure to select each of the following packages for download and installation:

    • cygrunsrv from the Admin branch
    • cygwin-doc from the Doc branch
    • pdksh from the Shells branch
    • openssh and openssl from the Net branch
    • your choice of UNIX-style text editor from the Editors branch (for example: vim or emacs)

    Then click to download the files as prompted.
  10. Depending on your installation options, the Cygwin setup will download and install the selected packages. You may be prompted to choose to have a shortcut to the Cygwin terminal window added to the Desktop or Program Start menu. Click to continue and complete the installation.
  11. After the Cygwin setup is complete, open a Cygwin terminal window by clicking on the Cygwin desktop shortcut or Program Start menu item.

    Note: Depending on the user profile in the Windows system, the default directory that opens in the terminal window may not be within the root Cygwin installation tree. Use the pwd command to display the current directory. Typing in the command string cd / will normally change the directory to the Cygwin root which by default corresponds to the Windows C:\cygwin directory.

  12. Update the default Cygwin group file with the group names in use on the machine and in your network. Use the mkgroup utility to update the default Cygwin group file with the groups defined on the server and in your domain. Examples of the commands to use are as follows:

    Note: To have Cygwin recognize both domain and local group accounts, run the mkgroup utility twice, once for local users (-l option) and once for domain users (-d option). Remember to use >> syntax and not just > in order to append entries to the file.

    mkgroup -l >> ../etc/group

    mkgroup -d >> ../etc/group

    Note: If you use both the local and domain options, you must manually edit the /etc/group file (using the UNIX style text editor you downloaded) to remove any duplicate group entries. You may also want to remove group entries which are not needed for monitoring or should not have access to this machine.

  13. Update the default Cygwin user (passwd) file with the users defined on the local machine plus any individual domain users you want to grant access to Cygwin on this machine. Use the mkpasswd utility to update the default Cygwin user file . Examples of the commands to use are as follows:

    Note:By default, Cygwin is set to run the OpenSSH daemon as the local user called SYSTEM. To have Cygwin recognize both domain and local machine user accounts, run the mkpasswd using the -l option to add all local users and run it with the -d and -u options to add individual domain users. Remember to use >> syntax and not just > in order to append entries to the file.

    mkpasswd -l >> ..\etc\passwd

    mkpasswd -d -u username >> ..\etc\passwd (domain users)

    Note: If you use both the local and domain options, you must manually edit the /etc/passwd file (using the UNIX style text editor you downloaded) to remove any duplicate user entries. You may also change the default /home path and default shell for individual users. This may be necessary in order to install the RemoteNTSSH package in the /home/sitescopeaccount/ directory of the user account to be used by SiteScope.

  14. Change the active directory to the /bin directory by typing cd /bin.
  15. Create a symbolic link in the /bin directory that points to the Windows Command (CMD) shell by entering the following command line (be sure to include the trailing space and period):

    ln -s /cygdrive/c/winnt/system32/cmd.exe .

  16. It is recommended that you change permissions and ownership of several Cygwin files and directories. You also need to create a log file for the SSH daemon. Type the following command lines in the Cygwin terminal command line (Note: Exact syntax is required, including spaces). Press Enter after each command line entered:

    cd /
    chmod -R og-w .
    chmod og+w /tmp
    touch /var/log/sshd.log

    Note: Inconsistent and incorrectly assigned file and directory permissions can be one reason that the SSH daemon can not be started or a reason that SiteScope is unable to connect to and execute commands or scripts on the remote server.

  17. Configure the SSH daemon to run as a Windows service by entering the following command:
    ssh-host-config -y.
    When presented with the CYGWIN= prompt, enter ntsec tty to match the environment variable you set at the beginning of this procedure. Normally, this will configure the SSH daemon or service to restart automatically if the server needs to be restarted.
  18. Configure the encryption keys and files for the SSH daemon using the following command:
    ssh-user-config -y.
    You will be asked to enter passphrases for several keystore files. Enter appropriate passphrases when prompted. The program asks you to renter the passphrase to confirm the passphrase.
  19. You must change the ownership of several files and folders for use by the SSH daemon. The program will normally not run if the permissions on these files allows them to changed or executed by group or "world" level users. Enter the following command strings to restrict access to these files:

    chown SYSTEM:Users /var/log/sshd.log /var/empty /etc/ssh_h*
    chmod 755 /var/empty

  20. Check the installation by starting and then stopping the CYGWIN sshd service using the Programs -> Administrative Tools -> Services panel.

    Note: Cygwin includes a server utility to start the SSH daemon. However, there have been a number of situations where this method failed to start the server whereas using the Windows Services panel was able to start the server.

  21. Configure the default shell or command environment for the user account you will use for monitoring with SiteScope. The shell you select will effect what types of scripts or command can be run remotely using the SSH connection. Use the UNIX-style text editor and edit the /etc/passwd file. Find the entry for the SiteScope login account you intend to use and change the shell from /bin/bash to the shell you want to use as described below. This will normally be the last entry in the line for that account entry.
    • If you chose to have SiteScope interact with the remote server using the Windows Command shell, change the default shell entry to be /bin/cmd. Use this option when you plan to use Windows-style batch files and scripts You must also include the symbolic link to the Windows cmd.exe kernel in the /bin directory as described in a previous step of this procedure.
    • If you chose to have SiteScope interact with the remote Windows server using a Cygwin UNIX shell, change the default shell entry to be /bin/pdksh. The SiteScope SSH client may not accurately parse Cygwin's default bash shell. You must also configure a Remote UNIX server connection to this (Windows) server that connects to the Cygwin SSH daemon.

    Save the changes to the file.

  22. Edit the PATH and the default prompt commands in the /etc/profile file to ensure Cygwin can find certain files and that SiteScope can parse the output from the remote shell. Use the UNIX-style text editor and edit the /etc/profile file. Find the PATH definition entry near the top of the file. For example:

    PATH=/usr/local/bin:/usr/bin:/bin:$PATH

    Change this to include the following:

    PATH=.:/usr/local/bin:/usr/bin:/bin:$PATH

  23. To change the default prompt commands, edit the /etc/profile file and find the section similar to the following:

        ;;
    sh  | -sh   | */sh  |\
    sh.exe  | -sh.exe   | */sh.exe )
        #Set a simple prompt
        PS1='$ '
        ;;
    

    Immediately under this entry add the following:

        ;;
    pdksh  | -pdksh   | */pdksh  |\
    pdksh.exe  | -pdksh.exe   | */pdksh.exe )
        #Set a simple prompt
        PS1='> '
        ;;
    

    Save the changes to the file.
  24. Change the active directory to the home directory of the user you have created for SiteScope monitoring.

After making these changes and starting the SSH daemon, you should be able to connect to the server using an SSH client. See the section on Testing SSH connectivity with PuTTY utilities for information about testing SSH connectivity outside of the SiteScope application on Windows NT/2000 machines.

Note: Any time that you run the mkpasswd -l /etc/passwd command (for example, when adding a new user) you will need to edit the /etc/passwd file again to make sure the deafult shell for that user is set to the appropriate value for any account being used by SiteScope.

OpenSSH for Windows

The OpenSSH for Windows package is an alternative to the Cygwin SSH package and can be easier to install. Like most products, the Cygwin product and the Open SSH for Windows are subject to change. There are cases where some versions of the Cygwin SSH server have not returned the data needed for SiteScope monitoring. If the OpenSSH for Windows package can solve this problem and you should use this package in place of the Cygwin package.

To install and configure an OpenSSH for Windows server on Windows NT/2000 servers

  1. Download and install the OpenSSH for Windows package.
  2. Open a command prompt and change to the installation directory (C:\Program Files\OpenSSH is the default installation path).
  3. Change the active directory to the OpenSSH\bin directory.
  4. You must update the default group file with the group names in use on the machine and in your network. Use the mkgroup utility to update the default OpenSSH group file with the groups defined on the server and in your domain. Examples of the commands to use are as follows:

    Note: To have OpenSSH recognize both domain and local group accounts, run the mkgroup utility twice, once for local users (-l option) and once for domain users (-d option). Remember to use >> syntax and not just > in order to append entries to the file.

    mkgroup -l >> ..\etc\group

    mkgroup -d >> ..\etc\group

    Note: If you use both the local and domain options, you must manually edit the /etc/group file (using the UNIX style text editor you downloaded) to remove any duplicate group entries. You may also want to remove group entries which are not needed or should not have access to this machine.

  5. You must update the default OpenSSH user (passwd) file with the users defined on the local machine plus any domain user you want to grant access to the SSH server on this machine. Use the mkpasswd utility to update the default user file . Examples of the commands to use are as follows:

    Note: To have OpenSSH recognize both domain and local machine user accounts, run the mkpasswd using the -l option to add all local users and run it with the -d and -u options to add individual domain users. Remember to use >> syntax and not just > in order to append entries to the file.

    mkpasswd -l >> ..\etc\passwd

    mkpasswd -d -u username >> ..\etc\passwd (domain users)

    Note: If you use both the local and domain options, you must manually edit the /etc/passwd file (using the UNIX style text editor you downloaded) to remove any duplicate user entries. You may also change the default /home path and shell for individual users (see instructions below).

  6. Check the installation by starting the OpenSSH Server service using the Programs -> Administrative Tools -> Services panel.

2. Installation of SiteScope Remote NT SSH Files

SiteScope includes a set of files that must be installed on each remote Windows server in order to enable certain commonly used server monitoring. Use the following steps to install a set of files that SiteScope needs to enable certain server level monitoring via SSH on remote Windows Servers:

To install the SiteScope SSH Files on Cygwin installations

  1. Verify that a /sitescope_login_account_name directory exists within the install_drive:/cygwin/home directory on each machine that will be monitored by SiteScope using SSH. Replace sitescope_login_account_name with the user account name you will use to connect to the machine using the SSH server.
  2. One of the advantages of using SSH on Windows is that it allows SiteScope to execute scripts on the remote server running the SSH daemon. To be able to use the Script Monitor to run remote scripts, create a scripts subdirectory in the /home/sitescope_login_account_name directory. Scripts you create for execution by the SiteScope Script Monitor must be placed inside this directory.
  3. On the machine where SiteScope is installed, find the file called RemoteNTSSH.zip in the <SiteScope install path>\SiteScope\tools directory.
  4. Copy this file to the install_drive:\cygwin\home\sitescope_login_account_name directory on each of the remote Windows NT/2000 servers where you have installed the SSH server or daemon software.
  5. Unzip the RemoteNTSSH.zip file on the remote server. Place the contents of the zip file into the install_drive:\cygwin\home\sitescope_login_account_name directory. This should create a install_drive:\cygwin\home\sitescope_login_account_name\scripts subfolder. You use this subfolder to hold scripts that can be run by the SiteScope Script Monitor.
  6. Start the CYGWIN sshd service on the remote server.

To install the SiteScope SSH Files on OpenSSH for Windows installations

  1. On the machine where SiteScope is installed, find the file called RemoteNTSSH.zip in the <SiteScope install path>\SiteScope\tools directory.
  2. Copy this file to the install_drive:\WINNT directory on each of the remote Windows NT/2000 servers where you have installed the SSH server or daemon software.
  3. Unzip the RemoteNTSSH.zip file on the remote server. Extract the contents of the zip file into the install_drive:\WINNT directory. This should create a install_drive:\WINNT\scripts subfolder. You use this subfolder to hold scripts that can be run by the SiteScope Script Monitor.
  4. Start the OpenSSH server service on the remote server.

After you have completed the steps above, it is recommended that you test SSH connectivity from your SiteScope server by using plink.exe or PuTTY.exe as described in the section Testing SSH connectivity with PuTTY utilities. After confirming SSH connectivity between SiteScope and the remote server, you can set up Remote Windows configurations as described in the User Guide and select SSH as the connection method. You can then configure CPU, Disk, Memory Windows Performance Counter, and Script monitors to use the SSH connectivity.

Index

SiteScope SSH Client Connection Options

Once you have set up SSH servers or daemons on remote servers, you need to configure the SSH client that SiteScope will use to connect to the remote servers. As noted above, SiteScope includes two client options for SSH connectivity. The following presents an overview of the client options. More information about each option is included in the sections indicated.

  1. Configuring SiteScope to use the integrated Java SSH client

    As of version 7.8.1.1, SiteScope includes an integrated SSH client written in Java. This is the recommended option for SSH connectivity. One advantage of using this client option is that it uses fewer system resources than the external clients would use. Also, configuration of this client is simpler in some cases. To configure your remote using an external client see the section on Configuring SSH Using the Integrated Java Client.

  2. Configuring SiteScope to use an external SSH client

    SiteScope on Windows ships with an third party SSH client called plink. Plink is one part of a set of SSH tools called known as PuTTY. SiteScope on UNIX and Linux requires that an external SSH be installed on the machine where SiteScope is running. To configure your remote using an external client see the section on Configuring SSH Using an External Client.

Index