About SSH risks and how to resolve them

Understanding the risks identified for keys in your environment is the first step in mitigating those risks. Some risks, called high-risk violations, are those that pose the greatest threat to your environment. Root access orphans, for example, can literally open a back door to attacks on your most critical servers. Identifying orphans as they occur can help to significantly reduce the risk of unauthorized access.

This section details the following high-risk violations and provides steps to remediate them.

SSH risks and how to remediate them

Violation	Policy	Remediation Options
Root Access Orphan		Remove orphaned keys Locate SSH client machines and scan keys on them Add self-service key mapping to add external client contact
Client Access Orphan		Remove orphaned keys Locate SSH client machines and scan keys on them Add self-service key mapping to add external client contact
Root Access NOTE Shown only if not a Root Access Orphan.		Remove authorized key with root access Specify in Policy to Flag Root Access if that is required by business
Duplicate Client Private Key NOTE Shown only if not a Shared Private Key.		Remove excessive keys Enable the Flag Duplicate Private Keys option on a policy
Duplicate Host Private Key NOTE Shown only if not a Shared Private Key.		Remove excessive keys Enable the Flag Duplicate Private Keys option on a policy
Shared Private Key		Split keyset into several with different private keys Remove excessive keys
Key Length ≤ 768 NOTE Shown only if Key Smaller Than Required is not shown.		Rotate keys (Optional) Set a minimum key length using a policy
Key Smaller than Required		Rotate keys
Vulnerable Protocol		Remove RSA1 keys and create RSA/DSA keysets instead Enable the Flag SSHv1 keys Option on a policy if there are obsolete devices that cannot support the newer version
Environment Crossing		Make sure authorized keys and private keys are only available in a single environment for a keyset. Issue separate keysets for devices in different environments.
Invalid Permissions		Keys reported as Invalid Permissions have overly permissive permissions and too open key permissions that 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.
Key is Symbolic Link		Although NOT recommended because of security risks, you have the option to enable file operations on symbolic links. This is an advanced option that is available as an SSH policy setting. See SSH policy settings details.