3DES deprecation in SSH from Xanadu What is changing? Starting with Xanadu, we will be disabling support of 3DES (Triple Data Encryption Standard) cipher from MID Servers. This decision is in line with industry best practices and security standards and part of ServiceNow’s ongoing effort to keep the NOW Platform secure. This change impacts SSH communication between MID server and linux target machine in customer environment. This change is not applicable to KMF, Password2 or keys configured in agent_keystore.jks Why is this change necessary? Security: 3DES has been deprecated due to its vulnerabilities, including the Sweet32 attack (CVE-2016-2183). As a result, it is no longer considered secure. NIST Compliance: 3DES does not meet the current NIST (National Institute of Standards and Technology) guidelines for encryption algorithms. There are two usages of 3DES in SSH in MID server: it is used for decrypting passphrase protected private keys and SSH session encryption/decryption. 3DES passphrase protected private key While there is no change in Xanadu, we plan to remove 3DES passphrase protected private key in Yokohama. We recommend regenerating the private keys in AES-128-CBC passphrase protected, if the existing keys are in 3DES cipher algorithm. a. Which keys are impacted ? Only SSH Private Key configured in the discovery_credentials table is impacted. b. How will I know if private key is 3DES passphrase protected or not? 3DES was deprecated from OpenSSH 5.4 version which was released in 2010, so it is less likely the key configured in discovery_credentials table is passphrase protected with 3DES. To confirm please ask your linux admin to check if the private key is 3DES passphrase protected, and check for the presence of keyword "DES-EDE3-CBC" in the private key PEM file. If present, then it is 3DES passphrase protected. c. What to do next if keys are 3DES passphrase protected ? Please work with your Linux admin team to generate new AES-128-CBC passphrase protected key. Configure this key on instance and test the new credential in the sub-prod instance first. And check if it can be used to discover the Linux servers successfully. Kindly disable/remove your old credentials after you have successfully configured new keys. For configuration details refer https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/product/credentials/reference/r_SSHCredentialsForm.html d. How to generate private keys with AES passphrase protected ? By default ssh-keygen utility from OpenSSH 5.4 onwards generates passphrase protected private key in AES-128-CBC. That means most of the customers already might be using AES passphrase protected private key and will not be impacted. For more details you can check with your linux admin team. 3DES encryption during SSH session 3DES has been removed from the default cipher algorithm proposal list of SSH client (MID Server) from Xanadu. Which cipher algorithm is used for encryption is finalised during algorithm negotiation between SSH server and SSH client. MID Server acts as an SSH client and during negotiation 3DES will not be in the default algorithm proposal list. Note: If you have configured an SSH server to exclusively use 3DES then, from Xanadu onward, SSH user authentication will fail. a. Does this change impacts other SSH algorithms ? This change only impacts cipher algorithm. There is no change in Key Exchange algorithm, Host Key algorithm and MAC algorithm. b. How will I know if SSH servers are configured to use only 3DES ? Ask your Linux admin team to run command "sudo sshd -T | grep -i ciphers" on SSH server (not on MID server). If the command output is like "ciphers 3des-cbc", then it means server is configured to use only 3des. c. What errors will I get if SSH servers are configured to use only 3DES for encryption of SSH session ? Error message would look like the following in the MID Server logs or instance. SNCSSH Error :Cannot connect, status is SSH_CONNECTION_FAILURE. Could not agree on client-to-server symmetric cipher algorithm Client:[aes128-ctr, aes192-ctr, aes256-ctr, aes128-cbc, aes192-cbc, aes256-cbc, none] Server: [3des-cbc]Maverick Error :Failed to establish SSH connection to 10.xx.xx.xx. Failed to establish SSH connection to 10.xx.xx.xx. Failed to negotiate algorithms d. How do you fix failure due to 3DES deprecation ? Verify whether your infrastructure supports stronger ciphers. If so, consider updating your configurations to those ciphers. See the MID Server SSH cryptographic algorithms documentation for supported cipher algorithms. e. How many customers would be impacted by 3DES deprecation ? OpenSSH server deprecated 3DES encryption in 7.4 version which was released in year 2016. So it is less likely customer might be using older SSH server and configured it explicitly to use only 3DES.