Cette page vous donnera les clés pour avoir accès aux différentes infrastructures proposées.
Voici les grandes lignes de la procédure à suivre. Le détail de chaque étape ainsi que des explications plus complètes sont exposés dans les sections suivantes.
rotule et trinity en utilisant votre login et votre mot de passe PERSEUS afin d’enregistrer leurs empreintes SSH → Section : Connexion initiale aux bastions.ssh/config de votre répertoire personnel → Section : SSH transparentPERSEUS 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éfinis 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.
Avant d’accéder aux clusters, vous devez obtenir un compte en vous enregistrant sur PERSEUS: PERsonal Space for cimEnt USers et rejoindre 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.
Le client OpenSSH est un outil permettant d’utiliser le protocole SSH, un protocole de sécurité réseau, qui permet notamment l’authentification par paire de clés cryptographiques (une publique et une privée), bien plus sécurisée qu’un simple mot de passe.
Contrairement à Linux ou macOS, sous Windows, il est nécessaire de vérifier que le client OpenSSH est installé et activé pour pouvoir l’utiliser. Quelques étapes supplémentaires sont nécessaires afin de pouvoir utiliser les commandes d’accès aux clusters. Le protocole suivant a été testé sous Windows 10 et 11.
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 donc 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
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 :
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 :
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é.
Effectuez une connexion SSH initiale aux deux bastions en utilisant votre login et votre mot de passe PERSEUS afin d’enregistrer leurs empreintes SSH, avec :
ssh <your-perseus-login>@access-gricad.univ-grenoble-alpes.fr
ou
ssh <your-perseus-login>@rotule.univ-grenoble-alpes.fr
ssh <your-perseus-login>@trinity.univ-grenoble-alpes.fr
Remplacez bien entendu par votre login PERSEUS. Remarquez aussi que votre login PERSEUS peut différer du login monlogin sur votre machine locale.
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 <your-perseus-login>@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:~$
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.
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 minimum après avoir rejoint un projet actif.
ssh <cluster>
Remplacez <cluster> avec le nom des clusters que vous souhaitez utiliser tels que dahu, bigfoot, luke…
login-perseus@rotule:~$ ssh <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 ~]$
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 aux bastions 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 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”.
Les clés SSH permettent de se connecter de manière sécurisée à un serveur distant sans avoir à entrer de mot de passe à chaque fois.
La génération d’une paire de clés SSH n’a besoin d’être faite qu’une seule fois. Elle doit être faite sur votre ordinateur personnel. Puis 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.
Dans votre dossier local .ssh, soit la paire de clés SSH est déjà créée, soit il faut le faire.
Pour les générer, vous pouvez taper dans votre invite de commande (cmd) :
ssh-keygen -t rsa -b 4096 -C "email@exemple.com"
ou
ssh-keygen -t ed25519 -C "email@exemple.com"
Vous pouvez choisir un autre algorithme de chiffrage si vous le souhaitez.
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:~$
Lors de cette commande, il vous sera demandé :
Enter passphrase (empty for no passphrase): [TAPER PHRASE SECRETE]
Enter same passphrase again: [CONFIRMER PHRASE SECRETE]
NE LAISSEZ PAS CE CHAMP VIDE ! Une clé sans passphrase, c’est comme laisser votre mot de passe visible sur votre machine : elle n’est plus protégée du tout !
Vous devez saisir une phrase secrète ou un 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 venons de créér 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.
Maintenant que nous pouvons accéder aux infrastructures sans avoir à fournir notre mot de passe ou de phrase secrète, voici une configuration supplémentaire qui permettra de rendre les bastions complètement invisibles et l’accès aux clusters totalement transparent ! Insérez les lignes ci-dessous dans le fichier .ssh/config de votre répertoire personnel :
Host *
ServerAliveInterval 30
Host *.ciment
User <your-perseus-login>
ProxyCommand ssh -q <your-perseus-login>@access-gricad.univ-grenoble-alpes.fr "nc -w 60 `basename %h .ciment` %p"
Remplacez bien entendu par votre login PERSEUS.
Le nom .ciment est une convention libre, nous utilisons ce nom ici parce qu’il représente nos machines de calcul, mais vous pouvez utiliser n’importe quel nom à votre convenance.
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.
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, voire 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.
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
Vous devez maintenant téléverser votre clé publique sur les différentes infrastructures souhaitées. 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 y accéder. Il existe plusieurs manières d’y parvenir :
Essayez maintenant de vous connecter sur les bastions et les frontales des clusters, via :
ssh <your-perseus-login>s@rotule.univ-grenoble-alpes.fr'
ssh <your-perseus-login>@trinity.univ-grenoble-alpes.fr'
ssh <your-perseus-login>@<cluster>.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 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 rejettera 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é.
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 votre 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.
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.
Pour démarrer automatiquement un agent SSH s’il n’est pas déjà chargé, 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
Si la fonction de l’agent SSH n’est pas claire à 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écryptée avant chaque utilisation et qu’elle n’est pas chargée dans l’agent. Le rôle 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.
Si vous recevez des messages de broadcast, vous pouvez entrer la commande mesg n dans votre terminal pour les arrêter.
Vous pouvez rajouter la commande mesg n dans votre fichier .profile ou .bash_profile pour que ce soit systématique.
Si vous recevez de tels messages, n’hésitez pas à nous le signaler en écrivant à sos-calcul-gricad@univ-grenoble-alpes.fr ou en vous rendant sur notre gestionnaire de tickets. N’oubliez pas de préciser le message que vous recevez ainsi que la machine sur laquelle vous les avez constatés.