Keys

In USP, cryptographic keys underpin all SSH-based security. They are used not only to identify and authenticate systems, but also to enforce the session break principle by separating inbound and outbound authentication.

USP uses two types of cryptographic keys:

• Private Keys are confidential credentials used by the USP Server and USP Client to assert their identities during SSH handshakes.
• Public Keys are used by the peer to verify those identities, enabling client authentication and server trust validation.

info

For information on how to create these keys, refer to SSH Key Pair Generation Guide.

How USP Uses Keys

Keys are used in five different scenarios:

Scenario	Description	Context
Authentication Between USP Clients and Tunnels	USP Clients use private/public key authentication when establishing secure SSH tunnels with USP Servers.	System interconnection (between USP components)
USP Server Host Key Verification	The USP Server presents its host key to external SFTP clients, which validate it to establish trust.	SFTP (business file transfers)
Remote Host Key Verification in Outbound Nodes	The USP Server validates the host key of the remote SFTP server (outbound node) before establishing a connection.	SFTP (business file transfers)
Account-Based Authentication	Accounts can be configured with key pairs to authenticate inbound SFTP users connecting to the USP Server.	SFTP (business file transfers)
Private Key for Outbound Connection	A private key can be configured for outbound connections when the remote SFTP server requires key-based authentication.	SFTP (business file transfers)

Authentication Between USP Clients and Tunnels

This scenario applies to system interconnection between USP components. When a USP Client connects to a USP Server through a Tunnel, SSH public key authentication is used for the client to authenticate itself to the server. In parallel, the USP Client also performs host key verification to ensure that the USP Server it connects to is trusted. These two mechanisms establish a secure, mutually trusted SSH session using key pairs on both ends.

This process requires two key pairs:

• The USP Client uses its key pair to authenticate to the USP Server.
• The USP Server Tunnel uses its host key pair to present its identity to the USP Client.

Each key pair consists of a private key, used to assert the component's identity, and a public key, used by the peer to verify that identity. While only the USP Client is authenticated in SSH public key authentication, both sides validate each other's identity using their respective key pairs. This completes the SSH trust relationship before any communication is allowed to proceed.

info

Additionally, the name value defined in the USP Client's .hcl configuration must match the Name of the corresponding Proxy Client in the USP Server configuration. This is how the USP Server identifies which key to use for authentication.

USP Client Authentication

To authenticate itself to the USP Server Tunnel, the USP Client uses a private key, which is defined in the client's .hcl configuration file under the key parameter. During the SSH handshake, this key asserts the client's identity.

The USP Server verifies this identity using the corresponding Public Key, which must be added to the corresponding Proxy Client configuration. The Proxy Client represents the specific USP Client authorized to connect through the Tunnel, and its configuration includes the Public Key under the Public Key field.

This setup ensures the USP Server only accepts connections from trusted USP Clients whose keys are explicitly registered and matched.

USP Server Tunnel Authentication

The USP Server Tunnel must also authenticate itself to the USP Client. This is achieved using the Tunnel's Private Key field. During the SSH handshake, this key allows the server to assert its identity to the connecting client.

On the client side, the USP Client must be configured to verify the USP Server's identity using the corresponding public key. This public key is referenced in the USP Client's .hcl configuration file under the tunnel.host_key parameter. It enables the USP Client to validate that it communicates with a trusted USP Server before the connection is fully established.

Summary Table

Component	Private Key	Public Key
USP Client	Configured using the key parameter in the USP Client's .hcl configuration file.	Selected from the Public Key dropdown when creating the Proxy Client.
USP Server	Selected from the Private Key dropdown when creating the Tunnel.	Configured using the tunnel.host_key parameter in the USP Client's .hcl configuration file.

USP Server Host Key Verification

This scenario applies to SFTP protocol in business file transfer use cases, where an external client must confirm it is connecting to a trusted USP Server instance. During the SSH handshake, the USP Server presents its identity using a Private Key configured in the Inbound Node as the Host Private Key. This key allows the server to assert its identity to the client.

The external client must already possess and trust the corresponding public key, which is used to validate the authenticity of the server's identity. This trust relationship is essential: if the external client cannot match the USP Server's presented Private Key with a known, trusted public key, the connection is rejected.

Remote Host Key Verification in Outbound Nodes

This scenario applies to SFTP protocol in business file transfer use cases, where the USP Server must validate the identity of an internal target before forwarding a connection. When the USP Server initiates an SSH-based outbound connection to an internal target, it must ensure that it is connecting to the intended and trusted system. This is achieved through host key verification, configured in the Outbound Node via the Remote Host Key.

The Remote Host Key represents the expected public host key of the internal target system. During the SSH handshake, the internal target (which acts as an SSH server) uses its private key to sign handshake data. It then presents the corresponding public key to the USP Server.

The USP Server, acting as the SSH client, compares the presented public key against the configured Remote Host Key in the Outbound Node. If the keys match, the server's identity is verified and the connection proceeds. If the keys do not match, the connection is rejected to prevent potential impersonation.

This verification step is critical to protect against man-in-the-middle (MITM) attacks and to ensure that outbound connections are only established with explicitly trusted internal systems.

Account-Based Authentication

This scenario applies to SFTP protocol in business file transfer use cases, where external clients authenticate to the USP Server using keys stored in Accounts. This allows USP to authenticate external clients securely, using standard SSH public key authentication mechanisms.

More precisely, the Rule must have the following setup:

• Inbound Authentication Method set to Public Key, Password or Public Key, or Password and Public Key.
• Inbound Authentication Source set to Account Repository.

To match this setup, an Account may (or must) include a Public Key.

During the SSH handshake, the USP Server matches the connection to the corresponding Account (based on the provided Username) and verifies the identity using the Public Key stored in that Account.

In summary, to use this mechanism:

• The Rule associated with the Inbound Node must have its Inbound Authentication Method set to a mode that supports public key authentication.
• The Inbound Authentication Source must be set to Account Repository.
• The external incoming connection must present a private key corresponding to the Public Key configured in their Account.
• The Account's Username must match the SSH username used by the client during connection.

info

This form of authentication is commonly used in SFTP business file transfer scenarios with external partners, where key-based access is preferred over passwords for stronger security and easier automation.

Private Key for Outbound Connection

This scenario applies to SFTP protocol in business file transfer use cases, where the USP Server must authenticate itself to internal targets during outbound connections. Private Keys are configured within Rules for this purpose. When a Rule is configured with the Outbound Authentication Source set to Dedicated Credentials, the Rule can specify a Private Key for Outbound Connection.

The USP Server uses this key to authenticate to the internal target during the second leg of the session break process. Specifically, the USP Server acts as an SSH client when connecting to the internal target and uses this private key to identify itself. The internal system must have the corresponding public key registered and trusted in advance.

This mechanism enables secure, automated connections from the USP Server to internal systems without requiring passwords, and supports credential separation between inbound and outbound authentication.