Les appliances PowerProtect série DP et IDPA signalent un paramètre SHA1 obsolète pour SSH (QID 38909)
摘要: Rapport des scanners de sécurité Paramètres cryptographiques SSH QID 38909 obsolètes pour les appliances PowerProtect Data Protection Series ou Integration Data Protection Appliance (IDPA). ...
本文适用于
本文不适用于
本文并非针对某种特定的产品。
本文并非包含所有产品版本。
安全性文章类型
Security KB
CVE 标识符
Deprecated SSH Cryptographic Settings Qualys ID (QID) 38909
问题摘要
L’algorithme de chiffrement ssh-rsa utilisé dans Secure Shell (SSH) pour l’authentification a été déclaré obsolète par OpenSSH. La dépréciation de ssh-rsa découle principalement de préoccupations concernant sa sécurité. Avec l’augmentation de la puissance de calcul, il est devenu plus facile pour les attaquants de déchiffrer les clés RSA, en particulier celles générées avec des longueurs de clé plus courtes. Cela le rend moins fiable pour sécuriser les connexions SSH contre les menaces modernes.
Remarque : Cet article cible uniquement les appliances PowerProtect série Data Protection ou IDPA version 2.7.6. Pour les versions antérieures d’IDPA, la mise à niveau vers la version 2.7.6 est recommandée.
Sur IDPA version 2.7.6, l’algorithme de chiffrement ssh-rsa est activé par défaut dans SSH pour les composants suivants :
- Appliance Configuration Manager (ACM)
- Logiciel de protection (Avamar)
- Proxy de machine virtuelle (VM) (proxy Avamar)
- Stockage de protection (Data Domain)
- Création de rapports et analytique (application DPA et datastore)
- Permet d’effectuer une recherche
- Integrated Dell Remote Access Controller (iDRAC)
Utilisez la commande suivante pour vérifier si le système est affecté par la faille de sécurité ssh-rsa :
ssh -o "HostKeyAlgorithms ssh-rsa" localhostou l’adresse IP du système si une vérification à distance est requise :
ssh -o "HostKeyAlgorithms ssh-rsa" <IP Address>
Si le système est vulnérable à ssh-rsa, il répond avec une clé RSA. Voici un exemple de sortie :
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)?
Si le système désactive ssh-rsa, la négociation échoue et la communication est impossible. Voici un exemple de sortie :
Unable to negotiate with 127.0.0.1 port 22: no matching host key type found. Their offer: ecdsa-sha2-nistp256,ssh-ed25519
建议
La solution de contournement suivante désactive la clé d’hôte ssh-rsa pour les composants liés à IDPA.
Pour ACM, Avamar, Avamar Proxy, DPA et Search :
1. Connectez-vous à la machine virtuelle en tant qu’utilisateur root. Pour Avamar et le proxy Avamar, connectez-vous d’abord en tant qu’administrateur, puis à l’utilisateur root.
2. Remplacez le répertoire de travail par /etc/ssh
3. Effectuez une copie de sauvegarde du fichier /etc/ssh/sshd_config existant
4. Modifiez le fichier /etc/ssh/sshd_config et autorisez uniquement « HostKey /etc/ssh/ssh_host_ecdsa_key » et « HostKey /etc/ssh/ssh_host_ed25519_key » dans le fichier de configuration pour tous les paramètres HostKey :
Figure 1 : Exemple montrant uniquement « HostKey /etc/ssh/ssh_host_ecdsa_key » et « HostKey /etc/ssh/ssh_host_ed25519_key » sont actifs.
5. Testez la syntaxe du fichier /etc/ssh/sshd_config, la commande ci-dessous doit afficher « 0 ». Si ce n’est pas le cas, corrigez les erreurs de syntaxe dans le fichier avant de continuer :
6. Redémarrez le processus sshd :
7. Si la clé d’hôte ssh-rsa est désactivée, le message « no matching host key type found » répond lorsque ssh-rsa est utilisé comme clé d’hôte :
Pour Data Domain :
Pour iDRAC :
1. Connectez-vous à l’interface
de ligne de commande 2 de l’iDRAC RACADM. Vérifiez le paramètre de chiffrement cryptographique SSH existant à l’aide de la commande suivante :
3. Mettez à jour le paramètre de chiffrements SSH à l’aide de la commande suivante :
4. Vérifiez à nouveau le paramètre de chiffrement cryptographique SSH :
Voici un exemple de la sortie attendue des commandes ci-dessus :
5. Vérifiez que ssh-rsa est désactivé en tant que clé d’hôte par SSH :
Pour ACM, Avamar, Avamar Proxy, DPA et Search :
1. Connectez-vous à la machine virtuelle en tant qu’utilisateur root. Pour Avamar et le proxy Avamar, connectez-vous d’abord en tant qu’administrateur, puis à l’utilisateur root.
2. Remplacez le répertoire de travail par /etc/ssh
cd /etc/ssh
3. Effectuez une copie de sauvegarde du fichier /etc/ssh/sshd_config existant
cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
4. Modifiez le fichier /etc/ssh/sshd_config et autorisez uniquement « HostKey /etc/ssh/ssh_host_ecdsa_key » et « HostKey /etc/ssh/ssh_host_ed25519_key » dans le fichier de configuration pour tous les paramètres HostKey :
Remarque : La ligne commence par un hashtag (#) qui ne prend pas effet et que le système considère comme des commentaires uniquement.
Figure 1 : Exemple montrant uniquement « HostKey /etc/ssh/ssh_host_ecdsa_key » et « HostKey /etc/ssh/ssh_host_ed25519_key » sont actifs.
5. Testez la syntaxe du fichier /etc/ssh/sshd_config, la commande ci-dessous doit afficher « 0 ». Si ce n’est pas le cas, corrigez les erreurs de syntaxe dans le fichier avant de continuer :
sshd -t |echo $? 0
6. Redémarrez le processus sshd :
systemctl restart sshd
7. Si la clé d’hôte ssh-rsa est désactivée, le message « no matching host key type found » répond lorsque ssh-rsa est utilisé comme clé d’hôte :
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
Pour Data Domain :
Remarque : La solution de contournement nécessite la prise en charge d’IDPA ou de Data Domain, car elle nécessite l’accès au mode BASH DD OS.
Remarque : Les modifications apportées au fichier sshd_config ne seront pas enregistrées après un redémarrage ou une mise à niveau. Ces modifications doivent être réappliquées jusqu’à ce que les nouvelles versions 8.0 ou 7.10.1.40 de DD OS soient publiées, ce qui fournit une résolution permanente. Il n’y a pas d’estimation de délai pour l’intégration de ces versions de DD OS dans l’IDPA.
Pour iDRAC :
1. Connectez-vous à l’interface
de ligne de commande 2 de l’iDRAC RACADM. Vérifiez le paramètre de chiffrement cryptographique SSH existant à l’aide de la commande suivante :
get idrac.sshcrypto.ciphers
3. Mettez à jour le paramètre de chiffrements SSH à l’aide de la commande suivante :
set idrac.sshcrypto.ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com
4. Vérifiez à nouveau le paramètre de chiffrement cryptographique SSH :
get idrac.sshcrypto.ciphers
Voici un exemple de la sortie attendue des commandes ci-dessus :
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. Vérifiez que ssh-rsa est désactivé en tant que clé d’hôte par 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
其他信息
La précédente clé d’hôte connue n’est pas valide :
Après la désactivation de la clé d’hôte ssh-rsa, la clé d’hôte RSA précédemment enregistrée dans le fichier de known_hosts SSH n’est plus valide. Une erreur peut ressembler à :
Pour mettre à jour le fichier known_hosts SSH pour un hôte spécifique, vous pouvez utiliser la commande suivante :
Voici un exemple :
Établissez une connexion SSH à l’iDRAC avec une erreur « aucun chiffrement correspondant trouvé » :
Après la mise à jour des chiffrements cryptographiques de l’iDRAC, le SSH à partir de l’ACM ou d’une autre machine virtuelle vers l’iDRAC peut recevoir le message d’erreur suivant. L’adresse IP de l’iDRAC est 10.60.9.156 dans cet exemple :
Il existe deux options pour résoudre ce problème.
Option 1 :
ajoutez l’option « -c aes128-gcm@openssh.com » lorsque vous vous connectez en SSH à l’iDRAC.
Par exemple :
Option 2 :
modifiez le fichier /etc/ssh/ssh_config pour inclure les chiffrements aes128-gcm@openssh.com et aes256-gcm@openssh.com.
1. Connectez-vous à la machine virtuelle en tant qu’utilisateur root. Pour Avamar et le proxy Avamar, connectez-vous d’abord en tant qu’administrateur, puis à l’utilisateur root.
2. Remplacez le répertoire de travail par /etc/ssh.
3. Effectuez une copie de sauvegarde du fichier /etc/ssh/ssh_config existant.
4. Modifiez le fichier /etc/ssh/ssh_config pour inclure les chiffrements aes128-gcm@openssh.com et aes256-gcm@openssh.com.
À partir de :
Figure 2 : Le paramètre de chiffrement par défaut dans /etc/ssh/ssh_config
À :
Figure 3 : Nouveau paramètre de chiffrement dans /etc/ssh/ssh_config
Après la mise à jour de /etc/ssh/ssh_config pour inclure les chiffrements aes128-gcm@openssh.com et aes256-gcm@openssh.com, le problème « aucun chiffrement correspondant trouvé » doit être résolu.
Si un client SSH basé sur Windows reçoit l’erreur « no matching cipher found » :
Figure 4 : Erreur « aucun chiffrement correspondant trouvé » reçue dans un client
SSH basé sur Windows La version 0.81 de PuTTY a été testée sans ce problème.
Graphique 5 : PuTTY 0.81 peut être utilisé pour accéder à l’iDRAC à partir de Windows.
Après la désactivation de la clé d’hôte ssh-rsa, la clé d’hôte RSA précédemment enregistrée dans le fichier de known_hosts SSH n’est plus valide. Une erreur peut ressembler à :
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:~ #
Pour mettre à jour le fichier known_hosts SSH pour un hôte spécifique, vous pouvez utiliser la commande suivante :
ssh-keygen -R <IP Address> -f /root/.ssh/known_hosts
Voici un exemple :
/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)?
Établissez une connexion SSH à l’iDRAC avec une erreur « aucun chiffrement correspondant trouvé » :
Après la mise à jour des chiffrements cryptographiques de l’iDRAC, le SSH à partir de l’ACM ou d’une autre machine virtuelle vers l’iDRAC peut recevoir le message d’erreur suivant. L’adresse IP de l’iDRAC est 10.60.9.156 dans cet exemple :
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:~ #
Il existe deux options pour résoudre ce problème.
Option 1 :
ajoutez l’option « -c aes128-gcm@openssh.com » lorsque vous vous connectez en SSH à l’iDRAC.
Par exemple :
idpa-acm:~ # ssh -c aes128-gcm@openssh.com 10.60.9.156 Password: racadm>>
Option 2 :
modifiez le fichier /etc/ssh/ssh_config pour inclure les chiffrements aes128-gcm@openssh.com et aes256-gcm@openssh.com.
1. Connectez-vous à la machine virtuelle en tant qu’utilisateur root. Pour Avamar et le proxy Avamar, connectez-vous d’abord en tant qu’administrateur, puis à l’utilisateur root.
2. Remplacez le répertoire de travail par /etc/ssh.
cd /etc/ssh
3. Effectuez une copie de sauvegarde du fichier /etc/ssh/ssh_config existant.
cp -p /etc/ssh/ssh_config /etc/ssh/ssh_config.backup
4. Modifiez le fichier /etc/ssh/ssh_config pour inclure les chiffrements aes128-gcm@openssh.com et aes256-gcm@openssh.com.
À partir de :
Figure 2 : Le paramètre de chiffrement par défaut dans /etc/ssh/ssh_config
À :
Figure 3 : Nouveau paramètre de chiffrement dans /etc/ssh/ssh_config
Après la mise à jour de /etc/ssh/ssh_config pour inclure les chiffrements aes128-gcm@openssh.com et aes256-gcm@openssh.com, le problème « aucun chiffrement correspondant trouvé » doit être résolu.
Si un client SSH basé sur Windows reçoit l’erreur « no matching cipher found » :
Figure 4 : Erreur « aucun chiffrement correspondant trouvé » reçue dans un client
SSH basé sur Windows La version 0.81 de PuTTY a été testée sans ce problème.
Graphique 5 : PuTTY 0.81 peut être utilisé pour accéder à l’iDRAC à partir de 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
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。