Note
|
The Grid Community Toolkit documentation was taken from the Globus Toolkit 6.0 documentation. As a result, there may be inaccuracies and outdated information. Please report any problems to the Grid Community Forums as GitHub issues. |
GCT → GSI-OpenSSH → GCT 6.0 GSI-OpenSSH: Developer’s Guide
This document provides information for GSI-OpenSSH developers. The changes to OpenSSH to add GSI support are limited, because we build on the existing GSSAPI support in OpenSSH for Kerberos. See the GSI-OpenSSH Internals page for more details.
Before you begin
Feature summary
Tested platforms
Tested Platforms for GSI-OpenSSH
-
Mac OS X 10.5
-
x86/x86_64 GNU/Linux
-
PPC AIX 5.3
-
Sun4u Solaris 5.10
Backward compatibility summary
GSI-OpenSSH is backward compatible.
Technology dependencies
GSI-OpenSSH depends on the following GCT components:
GSI-OpenSSH depends on the following 3rd party software:
GSI-OpenSSH Security Considerations
GSI-OpenSSH is a modified version of OpenSSH and includes full OpenSSH functionality. For more information on OpenSSH security, see the OpenSSH Security page.
Usage scenarios
The GSI-OpenSSH interface is through command-line tools only.
Tutorials
There are no tutorials available at this time
Architecture and design overview
See the GSI-OpenSSH Internals page.
GSI-OpenSSH Commands
Introduction
GSISSH(1)
NAME
gsissh - Secure remote login
SYNOPSIS
gsissh
Tool description
Use the gsissh command to securely login to a remote machine.
Command syntax
gsissh [-l login_name] hostname | user@hostname [command]
GSISCP(1)
NAME
gsiscp - Secure remote file copy
SYNOPSIS
gsiscp
Tool description
Use the gsiscp command to securely copy files to or from a remote machine.
Command syntax
gsiscp [-P port] [[user@]host1:]file1 […] [[user@]host2:]destfile
GSISFTP(1)
NAME
gsisftp - Secure file transfer
SYNOPSIS
gsisftp
Tool description
The gsisftp command provides an interactive interface for transferring files to and from remote machines.
Command syntax
gsisftp [[user@host[:dir[/]]] ]
Configuring
The GSI-enabled OpenSSH software is installed with a default set of
configuration files, described below. You may want to modify the
ssh_config
file before using the clients and the file before using
the clients and the sshd_config
file before using the server. file
before using the server.
If the GSI-enabled OpenSSH install script finds existing SSH key pairs, it will create symbolic links to them rather than generating new key pairs. The SSH key pairs are not required for GSI authentication. However, if you wish to support other SSH authentication methods, make sure the sshd (running as root) can read the key pair files (i.e., beware of NFS mounts with root_squash). If running multiple sshds on a system, we recommend configuring them so they all use the same key pairs (i.e., use symbolic links) to avoid client-side confusion.
-
$GLOBUS_LOCATION/etc/ssh/moduli
-
$GLOBUS_LOCATION/etc/ssh/ssh_config
-
$GLOBUS_LOCATION/etc/ssh/ssh_host_key[.pub]
-
$GLOBUS_LOCATION/etc/ssh/ssh_host_dsa[.pub]
-
$GLOBUS_LOCATION/etc/ssh/ssh_host_rsa[.pub]
-
$GLOBUS_LOCATION/etc/ssh/ssh_prng_cmds
-
$GLOBUS_LOCATION/etc/ssh/sshd_config
Environment variable interface
Environmental variables for GSI-OpenSSH
The GSI-enabled OpenSSHD needs to be able to find certain files and directories in order to properly function.
The items that OpenSSHD needs to be able to locate, their default location and the environment variable to override the default location are:
-
Host key
-
Host certificate
-
Grid map file
-
Certificate directory
Troubleshooting
Common GCT Errors
Errors
Error Code | Definition | Possible Solutions |
---|---|---|
|
This means that your proxy certificate has expired. |
Run |
|
Failing to run grid-proxy-init to create a user proxy with which to connect will result in the client notifying you that no local credentials exist. Any attempt to authenticate using GSI will fail in this case. |
Verify that your GSI proxy has been properly initialized via
|
|
The host key that the SSH server is using for GSI authentication must only be readable by the user which owns it. Any other permissions will cause this error. |
Make sure that the host key’s UNIX permissions are mode 400 (that is, it should only have mode readable for the user that owns the file, and no other mode bits should be set). |
|
If the server was passed an "implicit username" (i.e. requested to map the incoming connection to a username based on some contextual clues such as the certificate’s subject), and no entry exists in the grid-mapfile for the incoming connection’s certificate subject, the server should output a clue that states it is unable to set the username against which to authenticate. |
Add an entry for the user to the gridmap file. |
|
If the subject name given in the system’s grid-mapfile points to a non-existent user, the server will give an internal error which is best caught when it is running in debugging mode. |
Add a new account to the system matching the username pointed at by the user’s subject in the grid-mapfile. |
|
Should the user attempt to connect without first creating a proxy certificate, or if the user is connecting via a SSH client that does not support GSI authentication, the server will note that no GSSAPI data was sent to it. Verify that the client is able to connect through another GSI service (such as the gatekeeper) to make sure that the user’s proxy has been created correctly. |
Verify that you are using a GSI-enabled SSH client and that your GSI proxy
has been properly initialized via
|
Additional GSI-OpenSSH Troubleshooting
Please see the GSI-OpenSSH Troubleshooting Page at NCSA.
Related Documentation
Please see the GSI-OpenSSH Home Page at NCSA for more information.