SSH policy settings details

The General policy settings contain the following sections:

• General
• Key Settings
• Source Restrictions
• Options
• Rotation

General

SSH Key policy folder settings - General group including fields and descriptions

Field Name	Description
Security Level	Choose how the ssh keys will be managed by Trust Protection Platform. Detect. Allow SSH key discovery, trust building, and analytics. Remediation. Features of 'Detect' security level, plus the ability to perform manual and automatic remediation of SSH keys (add, edit, remove, and rotate keys). If changes are made to the keys outside Trust Protection Platform, what happens will depend on the management type. For more information see Remote changes to SSH keys.
Allow Agentless Discovery and Remediation	When set to Yes, an agentless SSH connection will be allowed to discover and remediate SSH keys. NOTE  This setting can take up to 15 minutes to fully take effect.
Allow Adaptable Discovery	Adaptable SSH Key Discovery is a special type of agentless discovery that uses custom PowerShell scripts to access any device of any operating system in your network. Even though Adaptable SSH Key Discovery is a type of agentless discovery, this setting allows the adaptable type of agentless discovery to work, regardless of whether other agentless discoveries can also work. For more information about Adaptable SSH Key Discovery, see About Adaptable SSH Key Discovery NOTE  This setting can take up to 15 minutes to fully take effect.
Contacts	Allows you to select the identities (users or groups) that will be used as points of contact for SSH keys in this folder.
Allow Symbolic Links	When set to Yes, file operations are allowed to be performed on symbolic links (symlinks). Note: So-called "symbolic link attacks" are a significant risk factor so this option should be set to No unless you have the expertise and a special need to enable it. You can choose to flag or not to flag the use of symbolic links as a policy violation by using the option described in the Flagging items section.
Approver(s)	Allows you to select the identities that will be used to approve SSH key workflow actions for keys in this folder.
Encryption Key	Select the encryption key you want to use. Trust Protection Platform allows you to specify custom encryption keys for SSH keys that are stored in the system. By default, all keys are encrypted for storage using either the software encryption key, or a hardware key stored in an HSM. All new keys added to the folder will use the new encryption key. If you are storing certificates and SSH keys in the same policy folder, you can specify different encryption keys for SSH keys than you use for certificates.
Environment	Specifies the value used to validate that the keysets in this folder contain key instances under the same environment. This allows you to define environments for devices and folders, and if authorized keys and private keys are in separate environments, then a risk can be shown in SSH Protect.
Maximum Authorizations Allowed Per Keyset	When generating the SSH Authorized Clients report, having a large number of authorizations for a single keyset can reduce performance, and might not be useful for you. By default, Trust Protection Platform restricts the maximum number of authorizations displayed on the SSH Authorized Clients report to the value set here. Default is 50,000 authorizations.

Key Settings

The Key Settings section allows you to specify default information about the keys stored in the folder.

Specifying key algorithm, size, and format

You can specify any of the supported algorithms including:

• RSA
• DSA
• ECDSA P256
• ECDSA P384
• ECDSA P521
• ED25519 (Open SSH and PuTTY)

Flagging items

This section includes several options to flag items that are added to the folder even though those keys contain known security risks. These settings don't prevent keys from being added to the folder. These settings just determine whether these security risks should be flagged when keys with these risks are added to a folder.

Items flagged as policy violations display the violation status in the Risks column of the Device Inventory report.

Scenarios and suggested actions

• General example of flagging items. The SSHv1 protocol has several known security vulnerabilities. If you want SSHv1 keys to be flagged in your system when they are added, you would set this policy attribute to Yes. If you wanted to import these keys without a warning, you would set this policy attribute to No.

• Flag Invalid Permissions: Rotate Trust. Items flagged and reported as Invalid Permissions have overly permissive permissions and too open permissions. These keys are forever compromised and unsafe. You should either rotate (replace) or delete the key. Changing permissions does not fix the risk, and the policy violation remains since the key can no longer be trusted.

Source Restrictions

If you want to set a policy for controlling access to the items in this folder based on a specific IP address or host name, you can configure those settings here.

Select Allow Connections Fromor Deny Connections From, and then type the IP addresses or host names in the correct field. If inserting multiple values, separate each value with a comma.

This protects your servers in the event that a user who is no longer authorized to access your servers attempts to use a corresponding private key from a computer with an unauthorized IP address or domain.

Options

The Options section gives you additional options you can set via policy.

• Forced Command. Using forced commands, you can limit user accounts, SSH access, and usage. Forced commands are used to enforce what is executed during an SSH connection and disallows arbitrary commands, e.g., a key pair to another system. In addition, forced commands are also discoverable during agent-based discovery.

• Other Options. The Other Options field allows you to specify additional authorized key connection options. For each of the options listed below, they can be added only one time, and accept no parameters, unless otherwise specified.

  List of keywords and corresponding vendor support

  Keyword	SSH vendor
  	Open SSH	Tectia
  no-user-rc	x
  no-X11-forwarding	x	x
  no-agent-forwarding	x	x
  no-pty	x	x
  no-port-forwarding	x	x
  permitopen="host:port"	x
  environment="NAME=value"	x	x
  cert-authority	x
  principals="principals"	x
  tunnel="n"	x
  idle-timeout="time"		x

  For more information about options, visit OpenSSH's web site and Tectia's web site.

Rotation

This feature allows you to specify the period of rotation for all client keysets in the current folder.

The Device Connection policy page contains the following fields:

SSH Policy folder settings - Device Connection sub tab. Lists fields and provides a description for each field found on the sub-tab.

Device connection settings - Lists fields and provides a description for each field on the form.

Field Name	Description
Credential	Specify a predefined private key or user name and password combination to access the device. For information on creating a new credential, see Creating a new user credential for SSH connections
SSH Port	Specify the port to be used to make the connection for agentless connections. By default, the SSH port is port 22.
Deny Multiple Authentication Failures	Prevents multiple authentication attempts when authentication was refused by the server. If the server refuses the connection and this option is set (either here, at the policy level, or on the device settings), no further attempts to connect will be made until one of the following happens: The credential is changed The state is reset. This can be done on the device details page. The term authentication failure does not apply if there was a network error that prevented the connection. It only applies when the credential was provided to the device, and the device refused to connect.
Privilege Elevation	Specify how the agentless account should elevate privileges. Supported options are: Sudo. Standard sudo Linux protocol for elevating privileges. Other. Use if you have a PAM (privileged access management) tool as a centralized sudo replacement. By default the following options are available: /opt/boksm/bin/suexec - For FoXT BoKS /usr/local/bin/pbrun - For BeyondTrust PowerBroker /usr/share/centrifydc/bin/dzdo - For Centrify Server Suite NOTE  If you need to change or add an item to this list, we recommend having your system administrator contact Venafi Customer Support for additional information. For additional information regarding configuring Privileged Access Management Integration, see the following Venafi Support KB article: Configuring Privileged Access Management Integration. NOTE  If the host advertises that it supports password and keyboard-interactive authentication, then password will always be chosen. If password is not advertised, but keyboard interactive is, then Trust Protection Platform falls back to the expected username and password prompts (unless otherwise configured.) A note about Centrify and Solaris SSHD authentication An issue has been reported with Centrify not working well with Solaris SSHD when password authentication is used. The work around is to enforce keyboard interactive authentication by changing Password Authentication to "no", and recycling SSHD. None. Do not allow the agentless account to elevate privileges. Use the Other option if you need to use a custom command to elevate privileges, then select the correct Elevation Command. If necessary, specify the Privileged Credential after clicking Advanced Options. Please refer to your vendor documentation for more information on properly configuring your PAM tool. For your reference, there is an article on the Venafi Customer Support article entitled "Info: Configuring Privileged Access Management Integration" that contains a list of the commands that are used by the agentless drivers. NOTE  This feature only supports SSH management. You cannot use it for discovering or managing certificates.
Enforce Host Key Checking	Specified whether the server's host key fingerprint is verified during the SSH connection. This is a SHA-256 fingerprint of the server host key. The preferred key algorithm is RSA, followed by ECDSA. IMPORTANT  If you specify Yes here, you will need to set fingerprints correctly on all devices affected by this policy.