Accédez au cluster via SSH
Suggérer des modifications
PDF
Vous pouvez envoyer des requêtes SSH à un cluster ONTAP pour effectuer des tâches d'administration. SSH est activé par défaut.
-
Vous devez disposer d'un compte utilisateur configuré pour l'utilisation
sshcomme méthode d'accès.Le
-applicationparamètre des[security logincommandes spécifie la méthode d'accès pour un compte utilisateur. En savoir plus sur la commandesecurity logindans la référence de commande ONTAP. -
Si vous utilisez un compte d'utilisateur de domaine Active Directory (AD) pour accéder au cluster, un tunnel d'authentification pour le cluster doit avoir été configuré via une VM de stockage compatible CIFS et votre compte d'utilisateur de domaine AD doit également avoir été ajouté au cluster avec
sshcomme méthode d'accès etdomaincomme méthode d'authentification.
-
Vous devez utiliser un client OpenSSH 5.7 ou version ultérieure.
-
Seul le protocole SSH v2 est pris en charge ; SSH v1 n'est pas pris en charge.
-
ONTAP prend en charge un maximum de 64 sessions SSH simultanées par nœud.
Si la LIF de cluster management réside sur le nœud, il partage cette limite avec la LIF de node management.
Si le taux de connexions entrantes est supérieur à 10 par seconde, le service est temporairement désactivé pendant 60 secondes.
-
ONTAP ne prend en charge que les algorithmes de cryptage AES et 3DES (également appelés chiffrements) pour SSH.
AES est pris en charge avec des clés de 128, 192 et 256 bits. 3DES a une longueur clé de 56 bits comme dans les DES d'origine, mais elle est répétée trois fois.
-
Lorsque le mode FIPS est activé, les clients SSH doivent négocier avec les algorithmes de clé publique ECDSA (Elliptic Curve Digital Signature Algorithm) pour que la connexion soit réussie.
-
Pour accéder à l'interface de ligne de commandes de ONTAP à partir d'un hôte Windows, vous pouvez faire appel à un utilitaire tiers tel que PuTTY.
-
Si vous utilisez un nom d'utilisateur Windows AD pour vous connecter à ONTAP, vous devez utiliser les mêmes lettres majuscules ou minuscules que celles qui ont été utilisées lorsque le nom d'utilisateur AD et le nom de domaine ont été créés dans ONTAP.
Les noms d'utilisateur ET de domaine AD ne sont pas sensibles à la casse. Toutefois, les noms d'utilisateur ONTAP sont sensibles à la casse. La non-concordance de cas entre le nom d'utilisateur créé dans ONTAP et le nom d'utilisateur créé dans AD entraîne un échec de connexion.
-
À partir de ONTAP 9.3, vous pouvez "Activez l'authentification multifacteur SSH" pour les comptes d'administrateur local.
Lorsque l'authentification multifacteur SSH est activée, les utilisateurs sont authentifiés à l'aide d'une clé publique et d'un mot de passe.
-
À partir de ONTAP 9.4, vous pouvez "Activez l'authentification multifacteur SSH" Pour les utilisateurs distants LDAP et NIS.
-
À partir de ONTAP 9.13.1, vous pouvez éventuellement ajouter la validation du certificat au processus d'authentification SSH afin d'améliorer la sécurité de la connexion. Pour ce faire, "Associer un certificat X.509 à la clé publique" qu'un compte utilise. Si vous vous connectez à l'aide de SSH avec une clé publique SSH et un certificat X.509, ONTAP vérifie la validité du certificat X.509 avant de vous authentifier à l'aide de la clé publique SSH. La connexion SSH est refusée si le certificat a expiré ou a été révoqué et si la clé publique SSH est automatiquement désactivée.
-
À partir de ONTAP 9.14.1, les administrateurs ONTAP peuvent "Ajoutez l'authentification à deux facteurs Cisco Duo au processus d'authentification SSH" pour améliorer la sécurité de connexion. Lors de la première connexion après avoir activé l'authentification Cisco Duo, les utilisateurs doivent inscrire un périphérique pour qu'il serve d'authentificateur pour les sessions SSH.
-
À partir de ONTAP 9.15.1, les administrateurs peuvent "Configurer l'autorisation dynamique" Fournir une authentification adaptative supplémentaire aux utilisateurs SSH en fonction du score de confiance de l'utilisateur.
-
Depuis un hôte disposant d'un accès au réseau du cluster ONTAP, entrez dans le champ
sshcommande dans l'un des formats suivants :-
ssh username@hostname_or_IP [command] -
ssh -l username hostname_or_IP [command]
-
Si vous utilisez un compte utilisateur de domaine AD, vous devez le préciser username au format de domainname\\AD_accountname (avec doubles barres obliques inverses après le nom de domaine) ou "domainname\AD_accountname" (entre guillemets doubles et avec une barre oblique inverse unique après le nom de domaine).
hostname_or_IP Est le nom d'hôte ou l'adresse IP de la LIF de cluster management ou une LIF de node management. Il est recommandé d'utiliser la LIF de cluster management. Vous pouvez utiliser une adresse IPv4 ou IPv6.
command N'est pas requis pour les sessions interactives SSH.
Les exemples suivants montrent comment le compte utilisateur nommé « joe » peut émettre une demande SSH pour accéder à un cluster dont la LIF de gestion du cluster est 10.72.137.28 :
$ ssh joe@10.72.137.28 Password: cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
$ ssh -l joe 10.72.137.28 cluster show Password: Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
Les exemples suivants montrent comment le compte utilisateur nommé « john » du domaine nommé « `DOMAIN1' » peut émettre une requête SSH pour accéder à un cluster dont la LIF de gestion de cluster est 10.72.137.28 :
$ ssh DOMAIN1\\john@10.72.137.28 Password: cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
$ ssh -l "DOMAIN1\john" 10.72.137.28 cluster show Password: Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
L'exemple suivant montre comment le compte utilisateur nommé « joe » peut émettre une demande SSH MFA pour accéder à un cluster dont la LIF de gestion du cluster est de 10.72.137.32 :
$ ssh joe@10.72.137.32 Authenticated with partial success. Password: cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.