University of Illinois at Urbana-Champaign National Center for Supercomputing Applications
GSI-OpenSSH
Globus Toolkit
Downloading
Installing
Verification
User Guide
Admin Guide
Troubleshooting
Client
Server
Support
History
Valid XHTML 1.0!
Valid CSS!

Verifying GSI-Enabled OpenSSH Works Properly

  1. Prepare the testing environment
  2. Test the SSH client
  3. Test the SFTP client
  4. Test the SCP client
  5. Shutdown the test SSH server

The GSI-OpenSSH bundle is made up of many different components. Since the work going into the released packages focuses on adding GSI authentication support to the OpenSSH distribution, this document reflects this by helping you to verify that this authentication method works properly. We recommend you visit the OpenSSH website for testing the entire OpenSSH distribution.

Also, as we see it, the best way to test the SSH server that comes with GSI-OpenSSH is to start it, and test the accompanying client tools against it. If you see no problem with the client tools, it is safe to assume that GSI authentication works properly on the server side.

Step 1: Prepare the testing environment

  1. Choose a server machine on which to test the GSI-OpenSSH distribution. I will refer to this machine as <serverMachine>. If it is not already installed, install the GSI-OpenSSH distribution onto this machine following the standard installation instructions.

  2. Choose a separate client machine on which to test the GSI-OpenSSH distribution. I will refer to this machine as <alternateClientMachine>. If it is not already installed, install the GSI-OpenSSH distribution onto this machine following the standard installation instructions.

  3. Verify you have a valid certificate name-to-username mapping in the grid-mapfile on <serverMachine>.

    Please review the Globus grid-mapfile manual for information on how to properly configure <serverMachine>'s grid-mapfile.

  4. Edit the file $GLOBUS_LOCATION/sbin/SXXsshd so that the GSI-Enabled OpenSSH server starts up on an alternate port. I will refer to this port within this documentation as <alternateServerPort>.

    As a regular user, you will typically have to select a port above 1024 on most systems. Add the flags '-p <alternateServerPort>' within the SSHD_ARGS variable initialization section.

  5. On <serverMachine>, start the SSH server and verify that it is running by checking that it both shows up in a process listing and creates a file named $GLOBUS_LOCATION/var/sshd.pid.

    sh# $GLOBUS_LOCATION/sbin/SXXsshd start

  6. If you have not already done so, initialize your GSI credentials on both <serverMachine> and <alternateClientMachine>.

    sh# . $GLOBUS_LOCATION/etc/globus-user-env.sh
    sh# $GLOBUS_LOCATION/bin/grid-proxy-init

Step 2: Test the SSH client

This section focuses on testing whether a GSI-enabled SSH client can successfully connect to a GSI-enabled SSH server.

General Information

In each of the following tests, the SSH client is attempting to create a SSH connection with the test server. The GSI authentication process should be negotiated with the server first, and, if it succeeds, will immediately authenticate you properly.

Expected Output

On most systems, after each of the tests listed here, a login shell should be offered to the client by the SSH server. If you are presented with a 'password:' prompt by the SSH client, you have encountered an error with the GSI authentication process.

Obtaining Debugging Output

Adding the flags '-vvv' to the program's flags will have it output debugging information which can be useful to determine whether GSI authentication was attempted, and, if so, what caused its failure.

Tests

  1. From <serverMachine>, attempt to connect to the local server on the alternate port using the GSI authentication method.

    sh# $GLOBUS_LOCATION/bin/ssh -oPort=<alternateServerPort> localhost
    sh# $GLOBUS_LOCATION/bin/ssh -oPort=<alternateServerPort> <serverMachine>

  2. From <alternateClientMachine>, attempt to connect to the local server on the alternate port using the GSI authentication method.

    sh# $GLOBUS_LOCATION/bin/ssh -oPort=<alternateServerPort> <serverMachine>

Step 3: Test the SFTP client

This section focuses on testing whether a GSI-enabled SFTP client can successfully connect to a GSI-enabled SSH server.

General Information

In each of the following tests, the SFTP client is attempting to create a SSH/SFTP connection with the test server. The GSI authentication process should be negotiated with the server first, and, if it succeeds, will immediately authenticate you properly.

Expected Output

On most systems, after each of the tests listed here, a SFTP command line will be offered to you, where you can type standard SFTP commands (eg. 'ls', 'get', etc). If you are presented with a 'password:' prompt by the SSH client, you have encountered an error with the GSI authentication process. You must type 'exit' to complete each of these tests and close the connection to <serverMachine>.

Obtaining Debugging Output

Adding the flags '-vvv' to the program's flags will have it output debugging information which can be useful to determine whether GSI authentication was attempted, and, if so, what caused its failure.

Tests

  1. From <serverMachine>, attempt to connect to the local server on the alternate port using the GSI authentication method.

    sh# $GLOBUS_LOCATION/bin/sftp -oPort=<alternateServerPort> localhost
    sh# $GLOBUS_LOCATION/bin/sftp -oPort=<alternateServerPort> <serverMachine>

  2. From <alternateClientMachine>, attempt to connect to the local server on the alternate port using the GSI authentication method.

    sh# $GLOBUS_LOCATION/bin/sftp -oPort=<alternateServerPort> <serverMachine>

Step 4: Test the SCP client

This section focuses on testing whether a GSI-enabled SCP client can successfully connect to a GSI-enabled SSH server.

General Information

In each of the following tests, the SCP client is attempting to create a SSH/SCP connection with the test server. The GSI authentication process should be negotiated with the server first, and, if it succeeds, will immediately authenticate you properly.

For this test, we will be copying a file from the client to localhost/<serverMachine>. For our purposes, a small file should suffice (choose a large file if you wish to do further testing), and I will refer to the chosen file's basename as <testFile>. Make sure that <testFile> does not exist in /tmp and that the user you will be logging into the SSH server as has write access to the /tmp directory.

Expected Output

On most systems, after each of the tests listed here, output describing the file transfer SCP is performing will be output. If you are presented with a 'password:' prompt by the SCP tool, you have encountered an error with the GSI authentication process. If the file transfer occurred and no password prompt was output, compare <testFile> with /tmp/<testFile> on your local machine. The two files should be identical.

Obtaining Debugging Output

Adding the flags '-vvv' to the program's flags will have it output debugging information which can be useful to determine whether GSI authentication was attempted, and, if so, what caused its failure.

Tests

  1. From <serverMachine>, attempt to connect to the local server on the alternate port using the GSI authentication method.

    sh# $GLOBUS_LOCATION/bin/scp -oPort=<alternateServerPort> <testFile> localhost:/tmp/<testFile>
    sh# $GLOBUS_LOCATION/bin/scp -oPort=<alternateServerPort> <testFile> <serverMachine>:/tmp/<testFile>

  2. From <alternateClientMachine>, attempt to connect to the local server on the alternate port using the GSI authentication method.

    sh# $GLOBUS_LOCATION/bin/scp -oPort=<alternateServerPort> <testFile> <serverMachine>:/tmp/<testFile>

Step 5: Shutdown the test SSH server

  1. Stop the SSH server and reverse any changes you made that altered the port on which the server resided upon startup. After this step, running SXXsshd start should start the server on the default port (22).

    sh# $GLOBUS_LOCATION/sbin/SXXsshd stop
©2003-2007 Board of Trustees of the University of Illinois.