SSH Reference Manual

As each alias has its own password it is possible to create a NonStop environment where different persons use different
aliases pointing to the same Guardian user identifier. In such an environment storing KEY, PASSWORD and
KNOWNHOST records under the same user id represents a security problem:
Assuming aliases a1 and a2 exist, both configured with underlying Guardian user identifier grp1.usr1. If alias a1 stored a
password for remote host h1 and remote user u1 in the client mode database (under grp1.usr1), then alias a2 can connect
to host h1 specifying remote user u1 using the stored password entry, i.e. alias a2 gets access to remote host h1 without
knowing the password of remote user u1.
In order to resolve this problem a new parameter CLIENTMODEOWNERPOLICY
was introduced in release 89
defining the policy how to set the owner of an entry. Defined values are LOGINNAME, GUARDIANNAME and
BOTH. The differences are explained in the following sections.
Guardian Users in the Context of SSH Access Policy Explained
In the SSH access policy context we used a variety of terms for users and access. The following text will explain the
definitions of these terms and its origin.
An example of a TACL STATUS DETAIL command shows for a process:
Userid: 255,255 (SUPER.SUPER)
Login name: root-ssh
Every process consists of a "Userid" and "Login name".
The value of "Userid" refers to Guardian user identifier or just guardian user id. The "Userid" is used to do SSH policy
access checks when the parameter option GUARDIANNAME is used. In the example above this is 255.255
The value of "Login name" can be a Guardian user id or an alias. The "Login name" is used to do SSH policy access
checks when the parameter option LOGINNAME is used. In the example above an alias of root-ssh was used.
In Safeguard an alias is just an alternate name for a user. But the customers sometimes use different alias names that are
all assigned to the same underlying Guardian user ID. This presented a huge security hole if an alias was not used as an
alternate name (i.e. a human owns both alias and underlying Guardian user) but as a unique user name with a different
human being behind each alias.
Please refer to the Safeguard reference manual on the features of the Safeguard security-management.
Client Mode Owner Policy LOGINNAME
The default owner is the login name, which can be a Guardian user identifier or an alias. An alias user cannot
add/read/manipulate entries for the Guardian user the alias is configured with; vice versa, a Guardian user also can not
add/read/manipulate entries for associated aliases. In other words, a Guardian or alias user can add/manipulate entries for
that Guardian or alias user only.
The value LOGINNAME is recommended if different people are using the various aliases configured with the same
Guardian user identifier.
Client Mode Owner Policy GUARDIANNAME
The default owner is the Guardian user identifier, independent if the logon name is an alias or a Guardian user. Entries
are read using the Guardian user ID only. This means that a Guardian user can add/read/manipulate entries for associated
alias users, and vice versa.
The assumption is that the same person uses the aliases of a Guardian user identifier and the Guardian user identifier
itself. This was the default before this enhancement was introduced (in release 89) and therefore value
GUARDIANNAME needs to be used if the client mode policy of previous releases should be kept.
Client Mode Owner Policy BOTH
The default owner is the login name but a guardian user can add or manipulate entries stored under an alias or a guardian
user identifier. Entries are read for both the login name and the guardian user in case these are different (entries of the
158 • SSHCOM Command Reference HP NonStop SSH Reference Manual