The following details a possible misconfiguration of SSH on Rundeck nodes. This misconfiguration only impacts Docker distributions for PagerDuty Process Automation On Prem and Rundeck versions 4.0 and earlier, not Debian, RPM or .WAR.

Overview

• CVE-2022-29186

Docker distributions for PagerDuty Process Automation On Prem and Rundeck versions 4.0 and earlier contain a hard-coded SSH key pair generated at packaging time. In Docker installations, new projects have a default path pointing to the exposed key. If no new key pair was generated, and a user copied the public key to the authorized_keys files on a remote host, anyone with the exposed private key would have access to the host with the same privileges as the PagerDuty Process Automation On Prem user.

There are two ways a user could have mistakenly copied the packaging key to a production instance:

1. The tutorial documentation for setting up a learning environment included instructions to copy a default key to the authorized_keys file on the remote SSH node. If a user searched the internet for “Rundeck SSH”, the tutorial documents are currently the top result, and a user following them to set up their Production environment could have copied the hard-coded packaging key since it exists in the same file path as the one noted in the documentation. This documentation is now updated with new instructions to avoid this misconfiguration.

2. The other way a user could have copied the key is if they followed the official SSH configuration documentation, logged into the container (‘client’ in the documentation) as the Rundeck user, or exec’d in, and then ran the ssh-keygen command there. If so, the packaging key would already have been in the file path where the new key was to be stored and the system would have prompted the user to confirm they wished to overwrite the existing key. If the user declined and continued following the official instructions to copy the key to their production nodes, they would have copied the exposed key.

Action Items

Due to the potential severity of this misconfiguration, your prompt action on this matter is important. The following steps are available to discover and remediate this key pair issue:

1. To determine whether your systems are affected, it is necessary to scan endpoints in your environment. Please use or adapt one of the options here.

2. If any of the exposed keys are found, delete them and follow the official SSH configuration instructions to replace them with secure, private key pairs. PagerDuty Process Automation On Prem version 4.1 and Rundeck version 4.1 will not contain a key pair, and we have replaced prior versions in the Downloads section of our website. Please note that upgrading to a newer version will not remove the vulnerability if one of the exposed keys has been copied to your hosts. Scanning for the exposed keys and rotating them are the only remediation.

3. If you would like to prevent the possibility of exposed key pairs being copied to your production nodes in the future, follow these steps to set up a key revocation file and populate it with the exposed keys.