SSH Reference Manual

Enabling GSSAPI Authentication for a User Account
As any other authentication method, GSSAPI authentication can be enabled or disabled on a per user basis.
The following SSHCOM command illustrates how GSSAPI authentication can be added to the list of allowed
authentication methods for a user:
>RUN SSHCOM $SSH01
SSHCOM T0801H01_22JAN2014_ABK - 2014-01-24 14:42:45.368
OPEN $ssh01
% ALTER USER SUPER.OPERATOR, ALLOWED-AUTHENTICATIONS (gssapi-with-mic,password)
OK, user SUPER.OPERATOR altered.
%
Note: “gssapi-with-mic” is the standard name in RFC 4462 for GSSAPI-based user authentication. Including “gssapi-
with-mic” in the list of allowed authentications will also enable GSSAPI-based key exchange and the “gssapi-keyex”
user authentication method. “gssapi-keyex” is a variant of “gssapi-with-mic” that reuses the security context established
during GSSAPI key exchange.
GSSAPI authentication can be automatically enabled for newly added users, either by using the SSH2 ALLOWED-
AUTHENTICATIONS configuration parameter or by enabling gssapi-with-mic in the ALLOWED-
AUTHENTICATIONS attribute of a user that has been configured with the SSH2 AUTOADDSYSTEMUSERSLIKE
parameter.
Authorizing Kerberos Principals for Logon
For customers using a Kerberos solution, Kerberos authentication via GSSAPI allows the SSH2 daemon to securely
identify the user’s Kerberos principal name (such as the Microsoft Active Directory user ID). Using this unique Kerberos
identity, users can be authorized to access one or more NonStop user accounts.
The authorization can be controlled either implicitly or explicitly, as described in the following sections.
Implicit Authorization
Implicit authorization takes advantage of the Kerberos default authorization rule:
If host H is in the realm R, the Kerberos principal u@R is allowed access to the account u@H.
This rule means that a Kerberos principal can access an SSH user account, if the user name exactly matches the user
portion of the Kerberos principal name, and the local NonStop host is in the same realm. For example, if the NonStop
server is configured in a Microsoft Active Directory, an Active Directory user may access an SSH account with a
matching user name.
For example, if the NonStop host is configured as [e-mail], a user [e-mail]
can be implicitly authorized to logon as SUPER.OPERATOR as follows:
>RUN SSHCOM $SSH01
SSHCOM T0801H01_22JAN2014_ABK - 2014-01-24 14:42:45.368
OPEN $ssh01
% ADD USER JohnSmith, SYSTEM-USER SUPER.OPERATOR, ...
OK, user JohnSmith added.
%
Another implicit authorization method would be to create a Safeguard ALIAS:
>SAFECOM
SAFEGUARD COMMAND INTERPRETER - T9750H04 - (13AUG2008) SYSTEM \NONSTOP
= ADD ALIAS JohnSmith, SYSTEM-USER SUPER.OPERATOR, ...
OK, user JohnSmith added.
%
HP NonStop SSH Reference Manual Configuring and Running SSH2 • 131