SSH

Supported User Authentication Methods

PrivX Authentication
Compatibility with OpenSSH Keys and Certificates

The following user authentication methods are supported in the Tectia client/server solution.

Table 5.1. User authentication methods supported by the Tectia client/server solution

Authentication method Tectia ServerTectia Client
UnixWindowsUnixWindowsmacOS
Password[a] x x x x x
Public-Key x x x x x
Public-Key-PrivX [b] x x x x x
Certificate x x x x x
Host-based x x x    
Keyboard-interactive x x x x x
PAM[c] x   x x x
RSA SecurID[c] x x x x x
RADIUS[c] x x x x x
GSSAPI/Kerberos x x x x  

[a] On SELinux enabled systems, password method uses Puggable Authentication Methods internally on the server-side.

[b] Requires a web browser GUI for OpenID Connect (OIDC) user authentication to PrivX on the client-side and publickey authentication with a PrivX OpenSSH CA key on the server-side.

[c] Through keyboard-interactive.


PrivX Authentication

The Tectia client/server solution can be seamlessly used with PrivX privileged-access-management (PAM) solution to use ephemeral certificate authentication enabled with OIDC (OpenID Connect) browser-based user authentication to PrivX.

PrivX authentication automates just-in-time public-key user authentication with OpenSSH certificates. It also enables Single Sign-On and supports external user identity providers, such as Microsoft Entra, via PrivX.

In brief, PrivX authentication works as follows:

  1. An ephemeral key is automatically generated for the user when Connection Broker starts.

  2. If the Secure Shell server offers publickey user authentication, and auth-publickey-privx authentication method is enabled on the client, the client opens a PrivX session and validates the PrivX Instance's TLS Server certificate.

  3. The client launches the operating system's default browser to handle PrivX user authentication (unless a valid PrivX user session already exists).

  4. The browser validates the PrivX Instance's TLS Server certificate independently.

  5. Once PrivX user authentication is successful, the client automatically uses its ephemeral key to obtain a single-use, short-lived OpenSSH certificate that contains the user's roles from PrivX.

  6. The client sends the OpenSSH certificate (which includes the user's ephemeral public key) to the server. The packet also contains data unique to the Secure Shell session and it is signed by the user's ephemeral ECDSA private key.

  7. The server uses the PrivX OpenSSH CA key to check that the user's OpenSSH certificate is valid.

  8. The server verifies that the user has a valid private key by checking the signature in the initial packet.

  9. The server matches the user certificate against the rules in the server configuration to decide whether login is allowed or not.

Compatibility with OpenSSH Keys and Certificates

By default, the Tectia client/server solution uses private and public keys stored in the IETF standard Secure Shell v2 format. However, Tectia Client and Server can also use keys and related files in the legacy OpenSSH format or OpenSSH certificates.

The following OpenSSH-format keys are supported:

  • server host key pair and host certificate pair

  • trusted server host public keys, which clients use to authenticate servers

  • user private keys (used by clients to authenticate to a server)

  • authorized user public keys (used by a server to authenticate users), including public-key options

  • OpenSSH user and host certificates

  • OpenSSH CA-keys (used by a server to authenticate certificate users, or client to authenticate servers with host certificates)