HomeDocumentationAPI Reference
Log In
These docs are for v17. Click to read the latest docs for v33.

Documentation Conventions

Conventions

The following typographical conventions are used in SSH Communications Security documentation:

Table 1.1. Documentation conventions

ConventionUsageExample
Bold Menus, commands, GUI elements, strong emphasisClick Apply
Series of menu selectionsSelect File → Save
MonospaceFilenames, directories, URLs etc.Refer to readme.txt
Italics Placeholder values in examples, reference to other documents or products, emphasisSee the Tectia SSH Client User Manual
#See the Tectia SSH Client User Manual# rpm --install package.rpm
$In front of a command, $ indicates that the command is run as a non-privileged user.$ sshg3 user@host
OS#, OS$In front of a command, OS# or OS$ indicates that the command is specific for certain operating systems. Multiple operating systems are separated with a /.SUSE$ sudo zypper update

RedHat/CentOS# yum upgrade
\At the end of a line in a command, \ indicates that the command continues on the next line, but there was not enough space to show it on one line.$ ssh-keygen-g3 -t rsa \ -F -c mykey

📘

Note

A Note indicates neutral or positive information that emphasizes or supplements important points of the main text. A Note supplies information that may apply only in special cases (for example, memory limitations, equipment configurations, or specific versions of a program).

❗️

Caution

A Caution advises users that failure to take or to avoid a specified action could result in loss of data.

Terminology

The following terms are used throughout the documentation.

authorizer
Authorizer creates certificates with user’s roles as needed for users connecting to target hosts.

certificate
A certificate is a signed document that binds together the trusted issuer, and subject information such as public key, subject name, list of principals (role memberships), and information about access restrictions. Certificates on PrivX are short term, issued by the Authorizer, and verifiable using the Authorizer public key.

directory (in UI)
A directory in the PrivX UI refers to a source of user accounts, for example, an AD/LDAP directory.

host service
Services by which PrivX users establish connections: SSH servers, RDP servers, and Web-login pages.

host store
Host stores save host information, such as addresses, SSH/RDP services, and target-user-to-role mappings. Host stores also import hosts from existing directories.

known host
When the connection information of a host is stored in PrivX, that host is considered a known host. Known hosts enable PrivX features including passwordless and certificate-based connections.

local user directory
Local user directory provides an easy way to create local users for authentication and role mapping. Authentication is done via username or email, and a password.

native client
SSH and RDP clients supported by users' operating systems, such as OpenSSH client (ssh) or Remote Desktop client (mstsc).

OAuth2 service
OAuth2 service provides an authentication mechanism for a user to provide a username and password, and provides the given credentials against SSH PrivX Local User Store, and authentication providers, such as LDAP and AD.

principal
Principals are unique identities used in OpenSSH certificates, such as user names, or the UUIDs of PrivX roles.

PrivX deployment
PrivX servers using the same database. A PrivX deployment consists of one or more PrivX servers.

PrivX user
Any user account that is available via PrivX. Includes both PrivX local users, and users from AD/LDAP directories users that have been added to PrivX.

RDP target
An RDP server to which PrivX users can connect to.

See also target.

role
PrivX provides role-based access permissions: For a user to receive access permissions, they must be assigned to a role. Each role in the system has a unique principal (UUID) that represents the role in certificates and target host configurations.

role store
In PrivX, role store integrates against user directories and identity providers, for example, LDAP and AD. Role store contains rules which are evaluated to automatically map existing LDAP/AD user groups and roles into PrivX roles which are in turn used to access target hosts.

SSH target
An SSH server to which PrivX users can connect to.

See also target.

target
An identity and a host service that PrivX user(s) may connect to (for example, connecting to a host as root using SSH).

PrivX regards each unique idenity-service combination as a separate target. For example, connecting to a host as root using SSH is different from connecting to the host as root using RDP.

See also host service, target host and target user.

target host
Any destination host for a connection that has been authenticated/authorized using PrivX. In other words, any host to which access is granted using PrivX.

target user
The identity that PrivX users assume on target hosts.

web target
A website to which PrivX users can connect to.

See also target.