HP NonStop SSH Reference Manual Configuring and Running SSH2 • 117
T9000B03_02DEC2009_SSHCOM
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 nonstop@COMPANY.COM, a user JohnSmith@COMPANY.COM
can be implicitly authorized to logon as SUPER.OPERATOR as follows:
>RUN SSHCOM $SSH01
T9000B03_02DEC2009_SSHCOM
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.
%
If the SSH2 AUTOADDSYSTEMUSER option is disabled, the ALIAS must also be added to the NonStop SSH database
using the SSHCOM ADD USER command. Otherwise, if the SSH2 AUTOADDSYSTEMUSER option is TRUE and
gssapi-with-mic is enabled for automatically added users, then creating a Safeguard ALIAS for the Kerberos user
principal will be sufficient to grant SSO access.
To Next Page
Need help?
General