[16.0.0.4 and later]

Éviter les problèmes avec SSH dans une collectivité

Découvrez comment éviter les problèmes avec SSH dans une collectivité. Il est généralement question de problèmes de sécurité lorsqu'un utilisateur n'a pas accès à une ressource en raison d'une sécurité trop stricte. L'option de configuration SSH StrictModes protège les fichiers de clés publics et privés de la situation inverse, celle où la sécurité est trop permissive. SSH sécurise les communications entre systèmes sans authentification par mot de passe, mais elle ne fonctionne pas si les autorisations sur certains répertoires et fichiers ne sont pas suffisamment strictes.

Pourquoi et quand exécuter cette tâche

Le contrôleur de collectivité utilise SSH pour démarrer et arrêter les membres de la collectivité. Le centre d'administration se sert également de SSH lorsque vous l'utilisez pour visualiser et éditer des fichiers de configuration. Ces deux fonctions échouent si certaines autorisations sur les répertoires et les fichiers SSH sont trop permissives.

Pour le support de SSH sur z/OS, consultez IBM® Ported Tools for z/OS: OpenSSHUser's Guide dans la documentation OpenSSH.

Qu'est-ce que SSH ?
Les scripts 'collective' créent les fichiers que le contrôleur utilise pour s'authentifier auprès des services membres qui utilisent l'authentification par clés publiques et privées, méthode d'authentification SSH la plus sûre. Pour protéger les clés d'authentification publiques et privées, l'accès aux fichiers qui les contiennent doit être limité à l'utilisateur propriétaires de ces clés.

Les autorisations sur les répertoires ou fichiers qui contiennent des clés SSH ne doivent pas permettre un accès en écriture au groupe UNIX (g) ni aux autres utilisateurs (o). Par exemple, SSH ne fonctionne pas correctement si les autorisations sont 770, 775 ou 777.

StrictModes
OpenSSH active l'option StrictModes par défaut. StrictModes interdit l'usage de l'authentification par clés publiques et privées si les fichiers censés protéger les clés publiques ne sont pas eux-mêmes correctement protégés du fait d'une sécurité trop laxiste.
Dépannage de SSH
Lorsque vous tentez de remédier à un problème de sécurité affectant une collectivité dans laquelle le contrôleur ne peut pas démarrer ou arrêter un membre, ou lorsque vous ne pouvez pas voir ou éditer les fichiers de configuration en utilisant le Centre d'administration, si vous désactivez l'option StrictModes et que le problème disparaît, vous pouvez en déduire que les autorisations d'accès (propriétaire, groupe, autres utilisateurs) aux répertoires ou fichiers SSH en rapport avec l'authentification par clés publiques et privées sont incorrectes. Corrigez les autorisations d'accès et réactivez StrictModes.

Procédure

  1. Vérifiez le fichier de configuration du démon OpenSSH /etc/ssh/sshd_config.

    L'option StrictModes est activée si elle est réglée sur yes, mise en commentaire ou absente. Cette option peut déterminer que la sécurité est trop laxiste. Dans ce cas, le contrôleur de collectivité ne pourra pas démarrer un serveur membre en raison de l'échec de la connexion SSH à ce serveur.

  2. Les ID utilisateur associés aux serveurs contrôleur et membres d'une collectivité doivent être propriétaires des répertoires et fichiers suivants et avoir les autorisations indiquées :
    Répertoire ou fichier Autorisations
    Répertoire de base 700
    Sous-répertoire .ssh du répertoire de base 700
    Fichier /.ssh/authorized_keys 600
    Répertoire /<config_serveur>/resources/security/ssh/ 700
    Fichier /<config_serveur>/resources/security/ssh/id_rsa 600
    Fichier /<config_serveur>/resources/security/ssh/id_rsa.pub 600, par défaut. Vous pouvez faire passer les autorisations à 640 ou 644 pour permettre la lecture de la clé publique.

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : tagt_wlp_collective_zos_ssh.html