2.8.1. Procedure – Connecting to a server through PSM using SSH

Purpose: 

This procedure illustrates what happens when a client connects to a server through PSM and how the different configuration options and policies of PSM affect this process. Note that this procedure does not cover the scenarios when inband destination selection is used.

Steps: 

  1. Client-side connection: 

    The client tries to connect to the server. PSM receives the connection request and establishes the TCP connection with the client.

  2. PSM examines the connection request: it checks the IP address of the client and the IP address and port number of the intended destination server. If these parameters of the request match a connection policy configured on PSM, PSM inspects the connection in detail. Other connections are ignored by PSM, and simply forwarded on the packet level.

    The selected connection policy determines all settings and parameters of the connection.

    Note

    PSM compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. The first connection policy completely matching the connection request is applied to the connection.

    For details, see Procedure 7.1, Configuring connections.

  3. PSM selects the destination server based on the Target parameter of the connection policy. Network address translation of the target address can be performed at this step. For details, see Procedure 7.2, Modifying the destination address.

  4. PSM selects the source address used in the server-side connection based on the SNAT parameter of the connection policy. For details, see Procedure 7.4, Modifying the source address.

  5. The client authenticates itself using an authentication method permitted by the Authentication policy set in the Connection policy. Different connections can use different authentication policies, thus allow different authentication methods. The Authentication policy also restricts which users can connect to the server if public-key authentication is used. PSM can authenticate the user to a Local User Database, or to a remote LDAP (for example, Microsoft Active Directory) or RADIUS server. This is inband authentication, since it is performed in the same connection that the client originally established to communicate with the server.

    The username used in this authentication step is referred to as the Gateway username and is used to determine the Gateway group memberships of the user. For details, see Section 11.3, Authentication Policies.

    If an AA plugin is configured in PSM, the client may be prompted to provide additional information when authenticating to the server. For details on the AA plugin, see Section 18.5, Integrating external authentication and authorization systems. Note that if the plugin sets or overrides the username of the connection, a Usermapping policy needs to be configured and set in the Connection policy. For further information, see Procedure 18.1, Configuring usermapping policies.

  6. If the Gateway authentication option is set in the Connection policy, PSM pauses the connection until the user completes a gateway authentication on the PSM web interface. This is out-of-band authentication, since it is performed in an independent connection. For details, see Procedure 2.13, The gateway authentication process.

  7. If the Usermapping policy option is set in the Connection policy, PSM checks if the Usermapping policy permits the users of the gateway group to access the username used in the server-side connection (the remote username, for example, root). For details, see Procedure 18.1, Configuring usermapping policies.

  8. Before establishing the server-side connection, PSM can evaluate the channel policy to determine if the connection might be permitted at all, for example, it is not denied by a Time policy. PSM performs this check if the SSH Control > Settings > Enable pre channel check option is enabled. For details, see Procedure 11.5, Creating and editing protocol-level SSH settings.

    For the SSH protocol, PSM checks the From (client address), Gateway group, and Time policy restrictions set in the Channel policy of the Connection policy. For details, see Procedure 7.5, Creating and editing channel policies.

  9. Server-side connection: 

    PSM sets up the server-side connection and does the following:

    1. PSM establishes the TCP connection to the server.

    2. PSM negotiates the protocol parameters of the connection (for example, SSH encryption parameters) according to the SSH Control > Settings of the connection policy.

    3. PSM displays an SSH hostkey to the client. This hostkey is either generated on PSM, or it is the hostkey of the server (if it is available on PSM). The connection policy determines the hostkey shown to the client.

      Warning

      If the SSH Settings of the connection enable only RSA keys in the connection, the RSA key shown to the client must be set in the Connection policy. Similarly, if only DSA keys are permitted, the DSA key must be set.

    4. PSM verifies the hostkey or the certificate of the server according to the Server side hostkey setting option of the Connection policy (in general, you can manage the server hostkeys on the SSH Control > Server Host Keys page). If the server has not been contacted before, PSM can accept and store the hostkey of the server. Alternatively, the hostkey of the server can be manually uploaded to PSM. For details, see Section 11.4, Server host keys and certificates.

  10. PSM performs the authentication on the server, using the data received from:

  11. PSM authorizes the connection based on the Channel policy. It checks:

    • If the Channel policy includes a User List restriction for the Gateway group or Remote group, PSM checks if the user can access the server. If needed, PSM connects to the LDAP servers set in the LDAP Servers policy to resolve the group memberships of the user. For details, see Procedure 7.8, Creating and editing user lists.

    • PSM consults the Time policy assigned to the channel policy. Channels may be opened only within the allowed period.

      Tip

      Time policies are a good way to ensure that the server can be accessed only within the specified timeframe.

  12. Both the server- and the client-side connections have been established. From this step, the client can try to open any type and any number of channels in the connection.

  13. If 4-eyes authorization is set in the Channel policy, the SSH session of the client is paused until the authorizer permits the client to connect to the server. Who can authorize the session depends on the Access Control settings of the Connection policy. For details, see Procedure 2.14, Four-eyes authorization.

  14. The client starts to work on the server. Information about the connection is now available on the Search > Search page.

    If the user opens another channel within the same connection, PSM consults the Channel policy of the connection to see if the channel is permitted, and processes it accordingly.

  15. Post-processing the connection: 

    Once the connection has been closed, the following post-processing steps take place:

    1. After the client closes the connection, or it is terminated for some reason (for example, it times out, or a Content policy or a 4-eyes auditor terminates it), PSM indexes the contents of the audit trail (if the Audit option of the Channel policy, and the Enable indexing option of the Connection policy are enabled).

    2. PSM creates a backup of the data and the audit trail of the connection, and archives it to a remote server, if a Backup policy and an Archive policy is set in the Connection policy. For more information, see Section 4.7, Data and configuration backups and Section 4.8, Archiving and cleanup.

    3. When the Channel database cleanup period expires, PSM deletes all data about the connection from its database.