PowerProtect DP Series Appliances and IDPA report SHA1 deprecated setting for SSH (QID 38909)
摘要: Security scanners report Deprecated SSH Cryptographic Settings QID 38909 for PowerProtect Data Protection (DP) Series Appliances or Integration Data Protection Appliance (IDPA).
本文适用于
本文不适用于
本文并非针对某种特定的产品。
本文并非包含所有产品版本。
安全性文章类型
Security KB
CVE 标识符
Deprecated SSH Cryptographic Settings Qualys ID (QID) 38909
问题摘要
The ssh-rsa encryption algorithm used in Secure Shell (SSH) for authentication has been declared as deprecated by OpenSSH. The deprecation of ssh-rsa primarily stems from concerns about its security. As computing power has increased, it has become more feasible for attackers to crack RSA keys, particularly those generated with shorter key lengths. This makes it less reliable for securing SSH connections against modern threats.
Note: This article only targets PowerProtect Data Protection Series Appliances or IDPA version 2.7.6. For earlier versions of IDPA, upgrading to version 2.7.6 is recommended.
On IDPA version 2.7.6, the following components have the ssh-rsa encryption algorithm enabled in SSH by default:
- Appliance Configuration Manager (ACM)
- Protection Software (Avamar)
- Virtual Machine (VM) Proxy (Avamar Proxy)
- Protection Storage (Data Domain)
- Reporting and Analytics (DPA App and Datastore)
- Search
- Integrated Dell Remote Access Controller (iDRAC)
Use the following command to verify if the ssh-rsa vulnerability is affecting the system:
ssh -o "HostKeyAlgorithms ssh-rsa" localhostor the system IP address if a remote verification is required:
ssh -o "HostKeyAlgorithms ssh-rsa" <IP Address>
If the system is vulnerable to ssh-rsa, it responds with an RSA key. Here is an example output:
The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is SHA256:DvdSBsGADdtyhzc5wi+CCpSpelEhVXFWeWQ9pheDJ2g. Are you sure you want to continue connecting (yes/no)?
If the system disabled ssh-rsa, the negotiation would fail and report an error message similar to "no matching host key type found." Here is an example output:
Unable to negotiate with 127.0.0.1 port 22: no matching host key type found. Their offer: ecdsa-sha2-nistp256,ssh-ed25519
建议
The following workaround disables the ssh-rsa host key for IDPA-related components.
For ACM, Avamar, Avamar Proxy, DPA, and Search:
1. Log in to the VM as root. For Avamar and Avamar Proxy, log in as admin first then su to root.
2. Change the working directory to /etc/ssh.
cd /etc/ssh
3. Make a backup copy of the existing /etc/ssh/sshd_config.
cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
4. Modify the /etc/ssh/sshd_config and allow only "HostKey /etc/ssh/ssh_host_ecdsa_key" and "HostKey /etc/ssh/ssh_host_ed25519_key" in the configuration file for all the HostKey settings:
Note: The line starts with a hashtag (#) that does not take effect and the system considers it as comments only.
Figure 1: An example showing only "HostKey /etc/ssh/ssh_host_ecdsa_key" and "HostKey /etc/ssh/ssh_host_ed25519_key" are active.
5. Test the /etc/ssh/sshd_config file syntax, the below command must print "0." If it does not, correct any syntax errors in the file before continuing:
sshd -t |echo $? 0
6. Restart the sshd process:
systemctl restart sshd
7. If the host key ssh-rsa is disabled, then a "no matching host key type found" message responds when the ssh-rsa is used as the host key:
ssh -o "HostKeyAlgorithms ssh-rsa" localhost Unable to negotiate with 127.0.0.1 port 22: no matching host key type found. Their offer: ecdsa-sha2-nistp256,ssh-ed25519
For Data Domain:
There are two parts of the remediation in the Data Domain:
Part 1 - Customer can use the adminaccess command to update the SSH options:
1. Log in to the Data Domain as a "sysadmin" user and use the following command to verify the vulnerability in the Data Domain:
adminaccess ssh option show
The expected output would be similar to the following, unwanted MACS and key exchange algorithms are highlighted:
sysadmin@dd# adminaccess ssh option show Option Value ----------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ session-timeout default (infinite) server-port default (22) ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512 key-exchange-algorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 ----------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ sysadmin@dd#
2. Remove the vulnerable key-exchange-algorithms 'diffie-hellman-group14-sha1' from the configured list and keep the remaining list as it is:
adminaccess ssh option set key-exchange-algorithms '<new-list-here>'
In this example:
adminaccess ssh option set key-exchange-algorithms 'curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256'
3. Remove the vulnerable MACs 'umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com' from the configured list and keep the remaining list as it is.
adminaccess ssh option set macs ‘<new-list-here>’
In this example:
adminaccess ssh option set macs 'hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512'
4. Review the new SSH options:
adminaccess ssh option show
In this example, it would become:
sysadmin@dd# adminaccess ssh option show Option Value ----------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- session-timeout default (infinite) server-port default (22) ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com macs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 key-exchange-algorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256 ----------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- sysadmin@dd#
5. Test a new SSH connection from the ACM, Avamar, and the customer desktop again.
To rollback the setting to the default, use the following reset option:
adminaccess ssh option reset
[ciphers | macs | key-exchange-algorithms]
[server-port | session-timeout]
Resets the ssh options to their default
values
Part 2 - This part requires the help of the IDPA or Data Domain Support Team:
Note: The workaround requires IDPA or Data Domain Support because it requires accessing the DD OS BASH mode.
Note: Modifications made to the sshd_config file will not be saved after a reboot or upgrade. These changes must be reapplied until the new DD OS versions 8.0 or 7.10.1.40 are released, which provide a permanent resolution. Upgrade to IDPA version 2.7.8 or later.
For iDRAC:
1. Log in to the iDRAC RACADM command-line interface
2. Review the existing SSH crypto ciphers setting with the following command:
get idrac.sshcrypto.ciphers
3. Update the SSH crypto ciphers setting with the following command:
set idrac.sshcrypto.ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com
4. Verify the SSH crypto ciphers setting again:
get idrac.sshcrypto.ciphers
Here is an example of the expected output of the above commands:
racadm>>get idrac.sshcrypto.ciphers [Key=idrac.Embedded.1#SSHCrypto.1] Ciphers=chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com racadm>>set idrac.sshcrypto.ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com [Key=idrac.Embedded.1#SSHCrypto.1] Object value modified successfully racadm>>get idrac.sshcrypto.ciphers [Key=idrac.Embedded.1#SSHCrypto.1] Ciphers=aes128-gcm@openssh.com,aes256-gcm@openssh.com racadm>>
5. Verify that the ssh-rsa is disabled as the host key by SSH:
ssh -o "HostKeyAlgorithms ssh-rsa" <IDRAC IP Address> Unable to negotiate with <IDRAC IP Address> port 22: no matching cipher found. Their offer: aes128-gcm@openssh.com,aes256-gcm@openssh.com
其他信息
The previous known host key is not valid:
After disabling the ssh-rsa host key, the previously saved RSA host key in the SSH known_hosts file is no longer valid. An error could show up similar to:
Use the following command to update the SSH known_hosts file for a specific host:
An example would be similar to:
SSH to iDRAC with a "no matching cipher found" error:
After updating the iDRAC crypto ciphers, SSH from ACM or other VM to the iDRAC could receive the following error message. The iDRAC IP address is 10.60.9.156 in this example:
There are two options to resolve this issue.
Option 1:
Add the option "-c aes128-gcm@openssh.com" when SSH to the iDRAC.
For example:
Option 2:
Modify the /etc/ssh/ssh_config to include ciphers aes128-gcm@openssh.com and aes256-gcm@openssh.com.
1. Log in to the VM as root. For Avamar and Avamar Proxy, log in as admin first then su to root.
2. Change the working directory to /etc/ssh.
3. Make a backup copy of the existing /etc/ssh/ssh_config.
4. Modify the /etc/ssh/ssh_config to include ciphers aes128-gcm@openssh.com and aes256-gcm@openssh.com.
From:
Figure 2: The default cipher setting in /etc/ssh/ssh_config
To:
Figure 3: New cipher setting in /etc/ssh/ssh_config
The "no matching cipher found" issue should be resolved after updating the /etc/ssh/ssh_config to include ciphers aes128-gcm@openssh.com and aes256-gcm@openssh.com.
In case a Windows-based SSH client receives the "no matching cipher found" error:
Figure 4: The "no matching cipher found" error received in a Windows-based SSH client.
The PuTTY version 0.81 has been tested without the issue.
Figure 5: PuTTY 0.81 can be used to access the iDRAC from Windows.
After disabling the ssh-rsa host key, the previously saved RSA host key in the SSH known_hosts file is no longer valid. An error could show up similar to:
idpa-acm:~ # ssh 192.168.100.100 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:J4j0FrLvrWbFouXtTE8qMCkDrIQ9U0+RaPGIKXtprTo. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /root/.ssh/known_hosts:9 You can use following command to remove the offending key: ssh-keygen -R 192.168.100.100 -f /root/.ssh/known_hosts ECDSA host key for 192.168.100.100 has changed and you have requested strict checking. Host key verification failed. idpa-acm:~ #
Use the following command to update the SSH known_hosts file for a specific host:
ssh-keygen -R <IP Address> -f /root/.ssh/known_hosts
An example would be similar to:
/root/.ssh/known_hosts updated. Original contents retained as /root/.ssh/known_hosts.old idpa-acm:~ # ssh 192.168.100.100 The authenticity of host '192.168.100.100 (192.168.100.100)' can't be established. ECDSA key fingerprint is SHA256:J4j0FrLvrWbFouXtTE8qMCkDrIQ9U0+RaPGIKXtprTo. Are you sure you want to continue connecting (yes/no)?
SSH to iDRAC with a "no matching cipher found" error:
After updating the iDRAC crypto ciphers, SSH from ACM or other VM to the iDRAC could receive the following error message. The iDRAC IP address is 10.60.9.156 in this example:
idpa-acm:~ # ssh 10.60.9.156 Unable to negotiate with 10.60.9.156 port 22: no matching cipher found. Their offer: aes128-gcm@openssh.com,aes256-gcm@openssh.com idpa-acm:~ #
There are two options to resolve this issue.
Option 1:
Add the option "-c aes128-gcm@openssh.com" when SSH to the iDRAC.
For example:
idpa-acm:~ # ssh -c aes128-gcm@openssh.com 10.60.9.156 Password: racadm>>
Option 2:
Modify the /etc/ssh/ssh_config to include ciphers aes128-gcm@openssh.com and aes256-gcm@openssh.com.
1. Log in to the VM as root. For Avamar and Avamar Proxy, log in as admin first then su to root.
2. Change the working directory to /etc/ssh.
cd /etc/ssh
3. Make a backup copy of the existing /etc/ssh/ssh_config.
cp -p /etc/ssh/ssh_config /etc/ssh/ssh_config.backup
4. Modify the /etc/ssh/ssh_config to include ciphers aes128-gcm@openssh.com and aes256-gcm@openssh.com.
From:
Figure 2: The default cipher setting in /etc/ssh/ssh_config
To:
Figure 3: New cipher setting in /etc/ssh/ssh_config
The "no matching cipher found" issue should be resolved after updating the /etc/ssh/ssh_config to include ciphers aes128-gcm@openssh.com and aes256-gcm@openssh.com.
In case a Windows-based SSH client receives the "no matching cipher found" error:
Figure 4: The "no matching cipher found" error received in a Windows-based SSH client.
The PuTTY version 0.81 has been tested without the issue.
Figure 5: PuTTY 0.81 can be used to access the iDRAC from Windows.
法律免责声明
受影响的产品
PowerProtect Data Protection Appliance, PowerProtect DP4400, PowerProtect DP5300, PowerProtect DP5800, PowerProtect DP8300, PowerProtect DP8800, PowerProtect Data Protection Software, Integrated Data Protection Appliance Family
, Integrated Data Protection Appliance Software, PowerProtect DP5900, PowerProtect DP8400, PowerProtect DP8900
...
文章属性
文章编号: 000224873
文章类型: Security KB
上次修改时间: 18 8月 2025
版本: 4
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。