Accès aux clusters de calcul

En bref

Êtes vous un utilisateur Windows ? Cliquez ici.

Mise en place de l’accès aux clusters

Suivez ces cinq étapes pour mettre en place votre accès aux clusters.

1 Compte PERSEUS

Obtenez un compte PERSEUS et rejoignez un projet actif. Attendez 24 heures après ces étapes pour que votre compte passe actif. Pendant ce temps vous pouvez préparer les étapes suivantes d’accès aux clusters.

2 Connexion initiale aux bastions

Effectuez une connexion ssh initiale aux deux bastions en utilisant votre login et votre mot de passe PERSEUS afin d’enregistrer leurs empreintes ssh.

ssh <your-perseus-login>@rotule.univ-grenoble-alpes.fr

ssh <your-perseus-login>@trinity.univ-grenoble-alpes.fr

Remplacez <your-perseus-login> avec le login de votre compte PERSEUS.

3 Connexion initiale aux clusters

Effectuez une connexion initiale depuis les deux bastions aux clusters que vous souhaitez utiliser, à nouveau pour enregistrer leurs empreintes ssh, mais cette fois dans vos comptes sur les bastions. Avant de pouvoir le faire, vous devez attendre 24 heures au maximum après avoir rejoint un projet actif.

ssh <cluster>

Remplacez <cluster> avec le nom des clusters que vous souhaitez utiliser tel que dahu, bigfoot, luke…

4 Configuration d’accès SSH transparente

Ajoutez les lignes suivantes dans votre .ssh/config.

Host *
  ServerAliveInterval 30

Host *.ciment
  User <perseus-login>
  ProxyCommand ssh -q <your-perseus-login>@access-gricad.univ-grenoble-alpes.fr "nc -w 60 `basename %h .ciment` %p"

ProxyCommand pourra être utilisée une fois que vous aurez configuré l’accès par clés ssh.

Le ServerAliveInterval est obligatoire et ne doit pas être défini à une valeur supérieure.

5 Accès par clés ssh

Créez une clé ssh que vous utiliserez pour accéder aux clusters. Copiez la clé publique sur les deux bastions :

ssh-copy-id -i </the/path/to/your/key> <your-perseus-login>@rotule.univ-grenoble-alpes.fr:

et :

ssh-copy-id -i </the/path/to/your/key> <your-perseus-login>@trinity.univ-grenoble-alpes.fr:

et aux clusters :

ssh-copy-id -i </the/path/to/your/key> <your-perseus-login>@<the-cluster-you-will-user>.ciment:

Répétez pour chaque cluster dont vous avez besoin. Ceci est nécessaire si vous souhaitez utiliser un accès transparent à travers les bastions.


Obtenir un compte

Avant d’accéder aux clusters vous devez obtenir un compte en vous enregistrant sur PERSEUS: PERsonal Space for cimEnt USers.

Authentification commune

PERSEUS est le service central de gestion des comptes et projets utilisé par de multiples services fournis par GRICAD.

Un login et un mot de passe sont associés à votre compte PERSEUS, soit ceux d’AGALAN si votre compte est interne, soit ceux que vous avez défini lors de la création de votre compte s’il est externe. Ils serviront pour vous donner accès, par ssh, aux clusters de calcul.

Pourquoi est-ce que l’accès aux clusters est filtré ?

L’accès aux clusters se fait normalement avec un client SSH. Cependant les serveurs SSH sont particulièrement vulnérables aux scans et attaques. Pour des raisons de sécurité il n’est pas possible de laisser les clusters en accès direct depuis Internet.

Nous fournissons deux bastions SSH dédiés. Leur niveau de sécurité est supérieur aux frontales des clusters. Ils fournissent aussi un point d’accès commun à tous les clusters.

La méthode d’accès classique est de se connecter en premier à un bastion SSH et, ensuite, de se connecter au cluster cible. Le défaut de cette méthode est qu’il vous demande de rentrer deux fois votre mot de passe. Nous verrons, dans les sections suivantes, comment rendre ce processus transparent et beaucoup moins pénible.

Schéma d’accès SSH aux clusters

graph LR; A[Votre poste] -->|ssh| B[Bastions SSH] B -->|ssh| C[Frontale Dahu] B -->|ssh| I[Frontale Bigfoot] B -->|ssh| D[Frontale Luke] B -->|ssh| E[Frontale Froggy] C -->|oar| F[Noeuds de calcul Dahu] I -->|oar| J[Noeuds de calcul Bigfoot] D -->|oar| G[Noeuds de calcul Luke] E -->|oar| H[Noeuds de calcul Froggy]

Bastions SSH

Il y a deux serveurs qui servent de bastions pour l’accès aux clusters de calcul GRICAD. Ils sont regroupés sous un même nom de serveur :

  • access-gricad.univ-grenoble-alpes.fr

Ceci permet de répartir la charge sur ces deux machines par un mécanisme de “round-robin” DNS. De plus, si l’un des serveurs venait à dysfonctionner, l’autre reste disponible. Dans cette situation, l’accès via l’adresse de round-robin échouera une fois sur deux mais vous pouvez alors vous connecter en utilisant le nom du serveur restant fonctionnel. Les serveurs sont :

  • rotule.univ-grenoble-alpes.fr
  • trinity.univ-grenoble-alpes.fr

Ce mécanisme de DNS round-robin offre une répartition de charge et, en cas de défaillance d’un des bastions, une nouvelle tentative d’accès vous amènera sur l’autre bastion à condition que personne d’autre n’ait fait une tentative d’accès similaire entre-temps. Le DNS round-roubin fonctionne en parcourant de manière cyclique la liste des entrées associées à l’enregistrement à chaque fois qu’une nouvelle requête est faite sans considération du client faisant la requête. De fait, si quelqu’un d’autre fait une requête sur access-gricad.univ-grenoble-alpes.fr immédiatement après vous, la requête suivante retombera sur le même hôte que celui que vous avez interrogé.

Authentification par mot de passe

L’authentification par mot de passe est la méthode la plus basique de connexion à un cluster. Elle est fonctionnelle mais ce n’est pas la méthode la plus efficace possible. Il faut cependant l’utiliser au moins une fois pour vous assurer que tout fonctionne :

monlogin@monpc:~$ ssh login-perseus@access-gricad.univ-grenoble-alpes.fr
The authenticity of host 'access-gricad.univ-grenoble-alpes.fr (129.88.196.128)' can't be established.
ECDSA key fingerprint is SHA256:fLweOXXtjaQ+Vr8PpmZTNlZIwb93oO/VmQh62qPPr34.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'access-gricad.univ-grenoble-alpes.fr,129.88.196.128' (ECDSA) to the list of known hosts.


******************************************************
                RESTRICTED ACCESS
      If you can't access, please, make sure 
            you've accepted the charter 
      https://perseus.univ-grenoble-alpes.fr/
******************************************************



login-perseus@access-gricad.univ-grenoble-alpes.fr's password: 
Linux rotule 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64

[...]

login-perseus@rotule:~$ 

Remplacez bien entendu login-perseus par votre login PERSEUS. Remarquez aussi que votre login PERSEUS login-perseus peut différer du login monlogin sur votre machine locale.

Quand vous vous connectez pour la première fois aux bastions SSH votre client SSH vous demandera si vous reconnaissez l’empreinte de la clé et si vous souhaitez continuer. La clé SSH vous permet de vous assurer que vous vous connectez bien sur la bonne machine et que vous n’êtes pas victime d’une attaque telle qu’un “man in the middle”. Les empreintes des clés SSH des bastions CIMENT sont données ci-dessous. Si l’empreinte qui vous est proposée correspond vous pouvez accepter et continuer de manière sécurisée.


Empreinte des clés SSH des bastions

  • RSA EDOYGE0LQIkZeyOO2CS8ZhR6/o3GthCGV7neNuqMgY4
  • ECDSA fLweOXXtjaQ+Vr8PpmZTNlZIwb93oO/VmQh62qPPr34
  • ED25519 7LNVN2unYEDLLVH4FZyeFJ66w5XBT4SsAAgBtn97pkE

Puisque vous avez utilisé le nom access-gricad.univ-grenoble-alpes.fr vous pouvez être connecté soit sur rotule soit sur trinity. Essayez ensuite de vous connecter à la frontale du cluster :

login-perseus@rotule:~$ ssh <ciment-cluster>
Password:  <entrez vote mot de passe>
Last login: Wed Aug 26 12:18:18 2009 from 129.88.34.220

[...]

[login-perseus@ciment-cluster ~]$

Remplacez ciment-cluster par le vrai nom du cluster auquel vous essayez de vous connecter.

Les mots de passe ne peuvent être changés sur les clusters. Il ne peut être changé que via l'interface web de gestion des comptes de PERSEUS si votre compte est externe (non AGALAN) ou sur l’interface de gestion de comptes AGALAN si votre compte PERSEUS est interne (lié à votre compte AGALAN).

De la même manière que vous avez dû vérifier l’empreinte des clés de la passerelle SSH lors de la première connexion et répondre que vous l’avez acceptée avant de continuer, vous devez vérifier l’empreinte des clés de la frontale du cluster lors de la première connexion. Il est important de le faire sur les deux bastions pour chaque cluster, sinon la connexion échouera car restera en elle attente de votre entrée. Vous devez donc faire au moins un ‘ssh ’ pour chaque cluster que vous utiliserez sur chaque bastion ssh. Les empreintes des clés SSH des frontales sont données ci-dessous afin de vous permettre de les vérifier pour vous assurer que vous êtes à l’abri d’une attaque de type man in the middle.

Empreinte des clés ssh de Dahu

  • 256 SHA256:LvTJwHNh6VYHa2WcHkiDJ7/5uMRurE4vPgryByHMSvE root@f-dahu (ECDSA)
  • 256 SHA256:frSjHEJyxO2XJO2RofBkhqLx9loPv4Ji4pEF60QewVk root@f-dahu (ED25519)
  • 2048 SHA256:++iF71wRwbYtE5zFx8uNY3Ahqv38gVHLlGxLjJJc5Bs root@f-dahu (RSA)

Empreinte des clés ssh de Bigfoot

  • 256 SHA256:Y85zqzkCu3dBEOyrDgTR5gnbU47r48VB9RSrTaueP40 root@bigfoot (ECDSA)
  • 256 SHA256:vHFGhKXTyD/64gkZWFO+uhCgwp5NQLqP2R9uI2fT2Lw root@bigfoot (ED25519)
  • 2048 SHA256:uUFMSzk2lpqHQEvVTD1NX7ESMwYSOnKWEfVKfJT17RQ root@bigfoot (RSA)

Empreinte des clés ssh de Luke

  • 1024 SHA256:neEKeikIL2064PpEfmDaO6qQzRcUiHl79cfoOh+MXNw root@luke (DSA)
  • 256 SHA256:aRuf2qZ6yHvc1tp0zP/kFS9RRdjdP2pf2pd79KqwE0k root@luke (ECDSA)
  • 2048 SHA256:2SEIkZ78qRUy9TU2l9HgYKSYqPfbFVqoUR1EeeljdmM root@luke (RSA)

Empreinte des clés ssh de Froggy

  • 1024 e1:d2:01:65:a5:2b:db:4e:c0:db:42:c1:a1:d4:d3:55 ssh_host_dsa_key.pub (DSA)
  • 2048 ef:4b:34:c0:21:0a:40:f4:c3:34:47:7f:1c:7f:7e:c7 (RSA1)
  • 2048 c5:3e:80:2e:ed:f8:43:d5:64:d2:06:71:59:30:8b:82 ssh_host_rsa_key.pub (RSA)

Se connecter aux bastions et clusters sans mot de passe

Des clés SSH peuvent être utilisées pour se connecter aux bastions et clusters. Ceci présente plusieurs avantages que nous verrons ultérieurement.

Il faut générer une paire de clés publique et privée et ensuite placer la clé publique sur le serveur cible.

La clé privée est cruciale et doit, à tout prix, toujours rester secrète. Elle doit être protégée par un mot de passe fort et ne doit jamais être partagée.

Genérer une paire de clés SSH

La génération d’une paire de clés SSH n’a besoin d’ête fait qu’une seule fois. Elle doit être faite sur votre ordinateur personnel.

Elle peut être faite en utilisant la commande ssh-keygen sur les systèmes UNIX/Linux.

monlogin@monpc:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/monlogin/.ssh/id_rsa): <enter>
Enter passphrase (empty for no passphrase): <entrez une phrase secrète ici>
Enter same passphrase again: <répétez la phrase secrète ici>
Your identification has been saved in /home/monlogin/.ssh/id_rsa.
Your public key has been saved in /home/monlogin/.ssh/id_rsa.pub.
The key fingerprint is:
21:f2:fe:d2:60:3e:26:e1:7b:a2:bd:48:6c:59:59:75 monlogin@monpc
The key's randomart image is:
+--[ RSA 2048]----+
|        . E      |
|       . .       |
|    . o .        |
|     = . .       |
|    o . S        |
| . o..o          |
|  =. +.o         |
| o o+ ...        |
|  o.+B o.        |
+-----------------+
monlogin@monpc:~$

Vous devez saisir une phrase secrète ou mot de passe robuste. Ceci est critique. N’hésitez pas à utiliser une phrase secrète complexe. Comme nous le verrons par la suite, vous n’aurez à donner cette phrase secrète qu’une seule fois au début de votre session. Votre clé restera chargée dans votre agent SSH jusqu’à ce que vous fermiez votre session.

Pour conclure, nous avons créé une paire de clés SSH, publique et privée, stockées dans le répertoire .ssh/ de votre ordinateur, avec une protection par phrase secrète forte pour la clé privée.

Utilisation de l’agent SSH

L’agent SSH vous permet de charger votre clé une fois et de la garder disponible pour toute nouvelle connexion aussi longtemps que votre session est ouverte et votre agent actif.

Sur la plupart des systèmes UNIX/Linux récents l’agent ssh-agent est démarré automatiquement à l’ouverture de votre session. Si ceci n’est pas le cas, vous devez le démarrer via la commande monlogin@monpc:~$ ssh-agent bash.

Vous pouvez maintenant charger votre clé privée dans l’agent. Si vous n’avez qu’une seule clé dans voter répertoire .ssh, vous pouvez le faire en exécutant monlogin@monpc:~$ ssh-add:

monlogin@monpc:~$ ssh-add
Enter passphrase for /home/monlogin/.ssh/id_rsa: <entrez votre phrase secrète>
Identity added: /home/monlogin/.ssh/id_rsa (/home/monlogin/.ssh/id_rsa)
monlogin@monpc:~$

Si vous avez plus d’une clé dans votre répertoire .ssh/ vous devez spécifier le chemin de la clé que vous souhaitez charger :

monlogin@monpc:~$ ssh-add .ssh/my_ssh_key
Enter passphrase for /home/monlogin/.ssh/my_ssh_key: <entrez votre phrase secrète>
Identity added: /home/monlogin/.ssh/my_ssh_key (/home/monlogin/.ssh/my_ssh_key)
monlogin@monpc:~$

La clé privée est maintenant décryptée et chargée en mémoire. Vous n’aurez plus à saisir votre phrase secrète à nouveau tant que vous n’aurez pas quitté le shell démarré avec l’agent ou quitté votre session.

Interfaces graphiques Gnome et KDE pour l’agent SSH

Sur certaines distributions Linux, si vous utilisez Gnome ou KDE, le gestionnaire de fenêtres sera probablement configuré afin d’ouvrir automatiquement une fenêtre vous demandant d’entrer la phrase secrète de votre clé SSH et vous n’aurez qu’une case à cocher pour qu’elle soit mémorisée tout le temps de la session. Si cela ne fonctionne pas de manière automatique, essayez d’ajouter la commande ssh-add à l’ouverture de votre session. Pour KDE vous pouvez le faire en exécutant simplement :

ln -s /usr/bin/ssh-add ~/.kde/Autostart/

Pour Gnome, allez au menu d’options System -> Preferences -> More Preferences -> Sessions -> Startup et ajoutez /usr/bin/ssh-add.

L’agent SSH en mode console

Vous pouvez ajouter le code ci-dessous à la fin du fichier .bash_profile dans votre répertoire personnel :

ssh-add
if [ $? -eq 2 ]
then
  echo lancement ssh-agent
  eval $(ssh-agent)
  ssh-add
fi

Ceci démarrera automatiquement un agent SSH si il n’est pas déjà chargé.

Téléverser la clé publique sur les bastions et les clusters

Vous devez maintenant téléverser votre clé publique sur les deux bastions en utilisant la commande ssh-copy-id. Avec cette opération ce sera la dernière fois que vous aurez à saisir votre mot de passe PERSEUS (à ne pas confondre avec la phrase secrète de votre clé) pour accéder aux bastions. Elle est réalisée de la manière suivante :

monlogin@monpc:~$ ssh-copy-id login-perseus@rotule.univ-grenoble-alpes.fr
login-perseus@rotule.univ-grenoble-alpes.fr's password: <saisissez voter mot de passe PERSEUS>>

Essayez maintenant de vous connecter sur le bastion, via ssh 'login-perseus@rotule.univ-grenoble-alpes.fr' et vérifiez dans le fichier .ssh/authorized_keys pour vous assurer que vous n’avez pas ajouté des clés publiques que vous ne souhaitez mettre.

Répétez l’opération sur l’autre bastion :

monlogin@monpc:~$ ssh-copy-id login-perseus@trinity.univ-grenoble-alpes.fr
login-perseus@trinity.univ-grenoble-alpes.fr's password: <saisissez voter mot de passe PERSEUS>>

Essayez maintenant de vous connecter sur le bastion, via ssh 'login-perseus@trinity.univ-grenoble-alpes.fr' et vérifiez dans le fichier .ssh/authorized_keys pour vous assurer que vous n’avez pas ajouté des clés publiques que vous ne souhaitez mettre.

Si la commande ssh-copy-id n’est pas disponible, vous pouvez utiliser la commande suivante : cat ~/.ssh/id_rsa.pub | ssh login-perseus@rotule.univ-grenoble-alpes.fr 'cat >> .ssh/authorized_keys'

Si vous avez de multiples clés ssh sur votre ordinateur, ssh-copy-id les copiera toutes sur l’hôte distant. Vous voudrez alors peut-être éditer le fichier .ssh/authorized_keys sur cet hôte pour retirer celles qui ne sont pas destinées à la connexion aux clusters. Il est cependant recommandé de sélectionner la clé que vous souhaitez utiliser pour cette connexion spécifique en utilisant l’option -i de ssh-copy-id pour spécifier le fichier d’identité à partir duquel sera copié votre clé publique. De plus, si vous avez trop de clés à copier, l’hôte rejetera votre opération à cause d’un nombre de tentatives de connexions échouées trop élevé avant même que ssh-copy-id ait pu copier une seule clé.

Si vous avez copié votre clé ssh aux bastions, vous pouvez alors la copier aux frontales des clusters afin de pouvoir y accéder sans utiliser de mot de passe. Cette opération est expliquée avec plus de détails dans la section pour rendre l’accès transparent.

Test de la configuration

Essayez de vous connecter au premier bastion :

monlogin@monpc:~$ ssh login-perseus@rotule.univ-grenoble-alpes.fr

[...]

login-perseus@rotule:~$

Essayez ensuite de vous connecter au second :

monlogin@monpc:~$ ssh login-perseus@trinity.univ-grenoble-alpes.fr

[...]

login-perseus@trinity:~$

Si vous n’avez pas eu à entrer la phrase secrète de votre clé SSH ou votre mot de passe PERSEUS c’est alors que votre configuration est correcte !

Vous pouvez maintenant essayer de vous connecter et déconnecter plusieurs fois d’affilée en utilisant ssh login-perseus@access-gricad.univ-grenoble-alpes.fr. Ceci devrait vous connecter de manière alternée à rotule et trinity sans avoir à fournir un mot de passe.

Si la fonction de l’agent SSH n’est pas clair à partir des étapes précédentes, quittez votre session en cours puis réessayez de vous connecter aux bastions après avoir ouvert une nouvelle session. Vous constaterez qu’il vous sera demandé de fournir une phrase secrète à chaque fois puisque votre clé privée doit être déryptée avant chaque utilisation et qu’elle n’est pas chargée dans l’agent. Le role de l’agent est de conserver votre clé sous forme décryptée le temps de votre session afin que vous n’ayez pas à saisir votre phrase secrète de manière répétée.

Rendre l’accès transparent en utilisant ProxyCommand

Maintenant que nous pouvons accéder à access-gricad.univ-grenoble-alpes.fr sans avoir à fournir de mot de passe ou de phrase secrète, voici une configuration supplémentaire qui permettra de rendre les bastions complètement inivisibles et l’accès aux clusters totalement transparent ! Insérez les trois lignes ci-dessous dans le fichier .ssh/config de votre répertoire personnel :

Host *.ciment
  User login-perseus
  ProxyCommand ssh -q login-perseus@access-gricad.univ-grenoble-alpes.fr "nc -w 60 `basename %h .ciment` %p"

Remplacez bien entendu login-perseus par vote login PERSEUS.

Le paramètre ‘-w 60’ dans la commande est utile pour maintenir la connexion active. Il est important de conserver cette valeur. La réduire peut entraîner des déconnexions intempestives voir une impossibilité de se connecter.

Vous pouvez désormais vous connecter à chaque cluster Ciment en utilisant le nom <nom-du-cluster.ciment>. Par exemple, vous pouvez vous connecter au cluster Dahu en utilisant :

monlogin@monpc:~$ ssh dahu.ciment

Les bastions connaissent les noms de domaine de tous les clusters. C’est pourquoi vous pouvez utiliser le nom court.

À ce stade, si vous n’avez pas aussi copié votre clé ssh sur la frontale du cluster, vous devez à nouveau donner un mot de passe car nous avons rendu l’accès aux bastions possible en utilisant votre clé SSH mais nous ne l’avons pas encore fait pour les clusters. Il suffit donc de répéter l’opération réalisée pour les bastions sur les différents clusters auxquels vous souhaitez accéder de la manière suivante :

monlogin@monpc:~$ ssh-copy-id dahu.ciment

Vous pouvez maintenant vous connecter sur tous les clusters Ciment en suffixant simplement leur nom avec .ciment. Vous pouvez même utiliser scp de la même manière pour effectuer des transferts de fichiers :

monlogin@monpc:~$ scp my_file f-dahu.ciment:

Ou même sftp :

monlogin@monpc:~$ sftp f-dahu.ciment