SSH Reference Manual

>RUN SSHCOM $SSH01
SSHCOM T0801H01_22JAN2014_ABK - 2014-01-24 14:42:45.368
OPEN $ssh01
% ADD USER serviceuser, ALLOWED-AUTHENTICATION (none), &
% SYSTEM-USER *NONE*, CI-PROGRAM *MENU*, &
% ALLOW-SHELL NO, ALLOWED-SUBSYTEMS (), ALLOW-TCP-FORWARDING NO
OK, user serviceuser added.
%
In the above example, "serviceuser" does not require an individual SSH authentication. Hence, this user represents a
logical service that accesses the system via the STN service menu. This service can be shared by multiple individual
users. In this scenario, actual user authentication should be performed by STN services.
Again, additional attributes limit the access rights of the user to the STN service menu only.
Single Sign-on with GSSAPI Authentication
Overview
GSSAPI (Generic Security Service Application Programming Interface) is a standardized function interface that provides
security services for applications in a mechanism-independent way. In addition, GSSAPI GSSAPI is also a standardized,
RFC 4462-compliant way to establish a security context for user authentication and key exchange between an SSH client
and server. The prevalent security mechanism supported for use with GSSAPI is Kerberos.
SSH2 supports the RFC 4462 standard for GSSAPI user authentication with Kerberos as the security mechanism, both
in DAEMON and CLIENT mode. This approach can be used to implement Kerberos-based single sign-on for users
connecting with a GSSAPI/Kerberos-enabled SSH client. Since Microsoft Active Directory supports Kerberos, Windows
domain users can be enabled to log onto HP NonStop™ Servers without being prompted for a password. If credential
forwarding (also known as TGT forwarding) was selected for the session, subsequent SSH connections from the
NonStop host to other network resources participating in Kerberos single-sign on can also be accessed without additional
authentication.
SSH2 also supports the RFC 4462 standard for GSSAPI key exchange, with Kerberos as the security mechanism. This
includes the server authentication of the SSH2 daemon via GSSAPI/Kerberos – rather than using its public key, which
eliminates the need to manage SSH host public keys on the client side.
Prerequisites
For GSSAPI authentication to work, SSH2 requires a Kerberos package to be installed and properly configured on the
same NonStop server. The GSSAUTH
server process (which is part of the Kerberos installation) must be running to
allow SSH to interface with GSSAPI/Kerberos functionality.
On the remote side, an SSH client or daemon that supports Kerberos authentication via GSSAPI is required. Available
options include comForte’s MR-Win6530 or J6530 terminal emulator packages, CrystalPoint's OutsideView, Cail's CTT,
SSH Tectia, OpenSSH, or a Kerberos-compliant version of PuTTY.
Configuration of the GSSAPI Interface Process
To enable GSSAPI authentication, SSH2 must be configured to locate the GSSAPI authentication interface process
(GSSAUTH) of the Kerberos installation. This can be done by specifying the GSSAUTH
parameter in the SSH2 startup
configuration, for example:
RUN SSH2 /NAME $SSH01, ... / ALL; GSSAUTH $GSS; ...
Make sure that the GSSAUTH parameter specifies the same process name as that configured for the GSSAUTH process
in your Kerberos installation.
130 • Configuring and Running SSH2 HP NonStop SSH Reference Manual