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:
- The servers that you want to have monitored by
SiteScope using SSH need to have a SSH daemon (or server) installed and
active
- 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
- SSH server (Cygwin OpenSSH or OpenSSH for Windows)
- 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:
- 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.
- 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.
- 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.
- 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
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
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 |
|
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:
- Installation and Configuration of a SSH Server
- Installation of SiteScope Remote NT SSH Files
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.
- Create a new System Environment variable with the following definition:
CYGWIN = ntsec tty
- Add the string
;C:\cygwin\bin to your PATH
variable. Save the changes to the variables.
- 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.
- Run the downloaded setup program and choose the Install
from Internet option when prompted to Choose A Download Source.
Click Next to continue.
- 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.
- If prompted, select a temporary directory where the Cygwin installation
files should be stored. For example, C:\temp.
Click Next to continue.
- If prompted, Select an Internet Connection option. Normally,
Direct Connection can be used.
Click Next to continue.
- Select a suitable mirror site from which to retrieve the files
using the selection list when prompted.
Click Next to continue.
-
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.
- 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.
- 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.
- 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.
- 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.
- Change the active directory to the /bin directory by typing
cd /bin.
- 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 .
-
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.
- 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.
- 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.
-
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
- 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.
- 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.
- 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
- 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.
- 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
- Download and install the OpenSSH for Windows package.
- Open a command prompt and change to the installation directory
(C:\Program Files\OpenSSH is the default installation path).
- Change the active directory to the OpenSSH\bin directory.
- 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.
- 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).
- Check the installation by starting the
OpenSSH Server service using the Programs -> Administrative Tools -> Services
panel.
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
- 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.
- 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.
- On the machine where SiteScope is installed, find the file called
RemoteNTSSH.zip in the <SiteScope install path>\SiteScope\tools
directory.
- 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.
- 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.
- Start the CYGWIN sshd service on the remote server.
To install the SiteScope SSH Files on OpenSSH for Windows installations
- On the machine where SiteScope is installed, find the file called
RemoteNTSSH.zip in the <SiteScope install path>\SiteScope\tools
directory.
- 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.
- 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.
- 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
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.
- 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.
- 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
|