Service d'Administration des Moyens Informatiques

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Ssh - généralités ======

Secure Shell (SSH) est un protocole de connexion à distance sécurisé (authentification, chiffrement).

Le **client ''ssh''** est disponible de façon standard sur les systèmes //Linux// ou //MacOS X//. Pour //Windows// le logiciel [[https://www.chiark.greenend.org.uk/~sgtatham/putty/|Putty]] offre une interface graphique pour SSH, mais Microsoft fournit aussi le client ''ssh'' en ligne de commande via [[https://docs.microsoft.com/fr-fr/windows/wsl/install-win10|WSL (Windows Subsystem for Linux)]].

<wrap lo>Putty existe aussi pour Linux et MacOS X, mais il y est nettement moins souvent utilisé.</wrap>

Des //services supplémentaires// existent au-dessus de SSH, entre autre ''scp'' et ''sftp'' pour le transfert de fichiers. SSH permet de mettre en place des //[[#tunnels|tunnels]]// afin de faire transiter d'autres flux de communication par le même canal (x2go, Proxy web…). 

===== Connexion login/mot de passe =====

Le protocole SSH peut permettre de s'authentifier sur une machine distante simplement à l'aide de son **login** et **mot de passe** (c'est le cas de la plupart des machines internes au laboratoire lorsqu'on y accède d'une autre machine interne). On utilise simplement :

<code bash>ssh machine_cible</code>

//(éventuellement ''ssh autrelogin@machine_cible'' si on dispose sur cette machine d'un login différent)//

Le mot de passe est demandé au moment de la connexion.

**Exemple**

<code>
bidule@plop:~$ ssh machine_cible
bidule@machine_cible's password: XXXXXXXXX
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-52-generic x86_64)
…
bidule@machine_cible:~$ 
</code>

==== Première connexion / vérification machine cible ====

S'il s'agit de la **première connexion** à cette machine, ''ssh'' affiche le **“fingerprint”** correspondant à la machine et demande de le valider. Il va ensuite le mémoriser dans ''~/.ssh/known_hosts'' comme identifiant d'une machine connue.

<code>
bidule@plop:~$ ssh  machine_cible
The authenticity of host 'machine_cible (129.175.17.124)' can't be established.
ECDSA key fingerprint is SHA256:ffp+FmYkXoGXXB0pbZXjUKTYjEdMIBsrXhgoibx375Y.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'machine_cible,129.175.17.124' (ECDSA) to the list of known hosts.
bidule@machine_cible's password: XXXXXXXXX
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-52-generic x86_64)
…
bidule@machine_cible:~$ 
</code>

Au cas où un autre ordinateur essaierait d'usurper l'adresse de machine_cible (typiquement pour récupérer votre mot de passe), sa signature serait invalide, ssh afficherait un message d'erreur et refuserait la connexion:

<code>
bidule@plop:~$ ssh machine_cible
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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:niH36DM6CtVqxZpe3iEWtbQbWpJoh3MZYrnsWsIo9pM.
Please contact your system administrator.
Add correct host key in /home/bidule/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/bidule/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f "/home/bidule/.ssh/known_hosts" -R "machine_cible"
ECDSA host key for machine_cible has changed and you have requested strict checking.
Host key verification failed.
</code>

<WRAP center round important 80%>
En cas d'alerte **« WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! »**, si le service informatique ne vous a pas prévenu d'un tel changement, alors prenez contact afin de vérifier qu'il n'y a pas effectivement une machine usurpatrice. 
</WRAP>

Si le changement de fingerprint est normal, alors vous pouvez nettoyer l'ancien à l'aide de la commende indiquée dans le message d'alerte.

Il se peut aussi que la même machine soit connue sous un autre nom, ou ait changé d'adresse IP… vous pouvez dans ce cas avoir des messages comme:

<code>
Warning: the ECDSA host key for 'machine_cible' differs from the key for the IP address '129.175.17.124'
Offending key for IP in /home/bidule/.ssh/known_hosts:2
</code>

Si tout est bon, il suffit de supprimer la ligne correspondante indiquée du fichier  ''~/.ssh/known_hosts''.


===== Connexion avec des clés SSH =====

Les clés SSH permettent une sécurité plus forte que le login/mot de passe, grace à la passphrase plus solide. Elles permettent d'automatiser certaines connexions de façon transparente. 

==== Création d'un jeu de clés ssh ====

Lors de la création d'un jeu de clés SSH, vous fabriquez en fait une **clé_publique** (la **serrure**) et une **clé_privée** correspondante. Ce jeu de clés permet de vous authentifier sur des machines (accès ssh) ou des services (par exemple github ou sourcesup).

  * La //clé_publique// (serrure) sera positionnée sur les machines (ou services) auxquelles vous désirez vous connecter.
  * La //clé_privée// doit être __protégée__, avec une passphrase forte — sinon c'est comme si vous donniez vos clés au monde entier pour entrer chez vous. Elle peut être recopiée sur vos différents postes de travail habituels, ou encore transférée lorsque vous changez de machine.

<WRAP center round important 80%>
Pensez à **sauvegarder vos fichiers de clés ssh**((la publique ET la privée ; en fichiers dans votre KeePass, ou bien sur votre MyCore du CNRS, ou encore sur votre Cirrus de l'Université)) au cas où vous les perdriez sur l'ordinateur sur lequel elles ont été créées, afin de ne pas avoir non seulement à les re-créer mais aussi à les remettre en place partout où elles sont utilisées  
</WRAP>

Lorsque vous désirez vous connecter à une machine sur laquelle vous avez positionné la //clé_publique//, ssh vous demande de déverrouiller la //clé_privée// et l'utilise dans le cadre d'un échange avec le serveur qui contrôle si elles correspondent.

Pour éviter d'avoir à saisir trop souvent votre passphrase, vous pouvez utiliser un "[[#utilisation_d_un_agent_ssh|agent ssh]]", programme qui fonctionne en tache de fond et qui se charge de conserver la //clé_privée// dans un trousseau déverrouillé en mémoire et de la rendre disponible à chaque fois que besoin.




=== Linux / MacOS / Windows WSL ===

Sur son poste de travail, on génère un jeu de clés SSH avec la commande:

<code bash>
ssh-keygen -t rsa -b 4096
</code>

Il faut répondre aux questions:

    * **Enter file in which to save the key** — pour choisir le nom des fichiers dans lesquels seront stockées la //clé_privée// et la //clé_publique//.  Le choix proposé par défaut est ''~/.ssh/id_rsa'', le plus simple est de le valider. Mais il est possible de spécifier un autre nom (avec le chemin) si on désire faire des tests ou avoir différents jeux de clés.
    * **Enter passphrase (empty for no passphrase)** — là il faut saisir une phrase “normale”, assez longue, et dont on se souvient facilement… et qu'un tiers ne pourra pas deviner facilement en se renseignant sur vous.

<WRAP center round important 80%>
**Il est obligatoire de mettre une passphrase**, solide, afin de sécuriser cette clé privée, sinon c'est comme si vous mettiez votre mot de passe en clair dans un fichier !
</WRAP>

S'il n'existe pas encore, le répertoire ''~/.ssh'' est créé, avec les droits ''rwx'' pour l'utilisateur seulement.

La //clé_privée// est stockée de façon chiffrée dans ''~/.ss/id_rsa'' avec les droits ''rw'' pour l'utilisateur seulement. Même chiffré, __ce fichier ne doit ni être transféré par email, ni être déposé dans des espaces de partage publics__.

La //clé_publique//  est stockée dans un fichier correspondant **.pub** ''~/.ss/id_rsa.pub'' avec les droits ''rw'' pour l'utilisateur et ''r'' pour tout le monde. 


== Exemple ==

<code>
bidule@plop:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/bidule/.ssh/id_rsa): 
Created directory '/home/bidule/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/bidule/.ssh/id_rsa
Your public key has been saved in /home/bidule/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:2VdyBiOfF2y7AxdVyEmSBnGtAVfJOdKPrjl0aurgYPE bidule@plop
The key's randomart image is:
+---[RSA 4096]----+
|          =+*X+*+|
|           ===#. |
|           .+==* |
|         o  o*+ .|
|      . S . .+ . |
|       o   .. =  |
|      o E  . = . |
|     . o .  *    |
|        ..oo .   |
+----[SHA256]-----+
bidule@plop:~$ ls -l .ssh
total 8
-rw------- 1 bidule bidule 3434 févr.  7 16:12 id_rsa
-rw-r--r-- 1 bidule bidule  737 févr.  7 16:12 id_rsa.pub
</code>

La //clé_publique// (serrure) est un fichier texte d'une ligne, contenant une indication sur le type de clé, la valeur de la clé, et un texte libre pour identifier celle-ci (texte que l'on peut modifier sans incidence):

**~/.ssh/id_rsa.pub**

<code>
ssh-rsa AAAAB3NzaC1yc… …Ufq3PeJXSIN4eDkP7hQ== bidule@plop
</code> 

La //clé_privée// est aussi un fichier texte, content une représentation chiffrée de la clé.

**~/.ssh/id_rsa**

<code>
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABCF6qDIcB
udEpeWoB79ob2CAAAAEAAAAAEAAAIXAAAAB3NzaC1yc2EAAAADAQABAAACAQDjn4GXfstx
… …
uSRJHWq206wx/Bdl+mBaSc/1/pMm3G7JKj2zmKKI1r9jLvAh+U62wInoR6BsiefUwMNGY4
m6day8zfc+ZZW5p+hZ56yGVFs=
-----END OPENSSH PRIVATE KEY-----
</code>

<wrap lo>À la place de l'algorithme RSA, il est possible d'utiliser l'[[https://blog.adminrezo.fr/2016/01/comment-choisir-sa-cle-ssh-rsa-dsa-ecdsa-ed25519/|algorithme ed25519]] avec la commande ''ssh-keygen -t ed25519 -a 100'' – dans ce cas les fichiers de clés créés sont ''id_ed25519'' et ''id_ed25519.pub''.  \\ On peut spécifier le commentaire informatif placé à la fin de la clé publique (par défaut ''loginlocal@nommachinelocale'') avec l'option ''-C "le texte que je veux" ''.</wrap>


==== Mise en place de la clé publique (serrure) ====

L'installation de la //clé_publique// sur une machine distante nécessite de s'authentifier au moins une fois sur celle-ci à l'aide de votre login et mot de passe. Et d'ajouter le contenu du fichier //clé_publique// au fichier ''~/.ssh/authorized_keys'' de la machine distante.

Le plus simple est d'utiliser la commande **ssh-copy-id** :

<code bash>
ssh-copy-id -i ~/.ssh/id_rsa.pub machine_cible.lisn.upsaclay.fr
</code>

La commande ''ssh-copy-id'' établit une connexion SSH (par mot de passe, avec gestion du fingerprint de la machine comme indiqué ci-dessus), se charge de la création de ''~/.ssh/'' et de ''authorized_keys'' sur la machine distante si besoin (avec les bons droits d'accès), et enfin installe votre //clé_publique// dans les clés autorisées sur la machine distante. 

**Exemple:**
 
<code>
bidule@plop:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub machine_cible.lisn.upsaclay.fr
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/bidule/.ssh/id_rsa.pub"
The authenticity of host 'machine_cible.lisn.upsaclay.fr (129.175.17.124)' can't be established.
ECDSA key fingerprint is SHA256:ffp+FmYkXoGXXB0pbZXjUKTYjEdMIBsrXhgoibx375Y.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
bidule@machine_cible.lisn.upsaclay.fr's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'machine_cible.lisn.upsaclay.fr'"
and check to make sure that only the key(s) you wanted were added.
</code>

Toutefois, si cette commande n'est pas disponible, il est possible de se connecter sur la machine cible avec son login/mot de passe et de réaliser l'opération à la main via la console et la ligne de commande.

<WRAP center round tip 80%>
Attention : pour que la clé soit prise en compte, vous seul (ni le groupe, ni other) devez avoir les accès en écriture sur les répertoires ''$HOME'' et ''$HOME/.ssh'' ainsi que sur le fichier ''$HOME/.ssh/authorized_keys''. 
</WRAP>

==== Utilisation de la clé privée ====

On utilise ssh normalement :

<code bash>
ssh machine_cible.lisn.upsaclay.fr
</code>

Comme il existe des fichiers de clés, au lieu de demander le mot de passe, c'est la passphrase de la //clé_privée// qui est demandée:

<code>
bidule@plop:~$ ssh machine_cible.lisn.upsaclay.fr
Enter passphrase for key '/home/bidule/.ssh/id_rsa': 
…
bidule@machine_cible:~$ 
</code>

<wrap lo>//Il est possible de forcer l'utilisation du login/mot de passe malgré la présence de clés, en utilisant l'option// ''-o PubkeyAuthentication=no'' //de ssh//.</wrap>

==== Utilisation d'un agent ssh ====

Pour éviter d'avoir à saisir sa passphrase à chaque connexion, il est possible de conserver sa //clé_privée// déverrouillée en mémoire le temps de la session courante. Si vous utilisez un environnement graphique, celui-ci fournit généralement un outil (//“wallet”//) pour gérer les trousseaux de clés ou mots de passe, dont les clés ssh, qui peuvent être déchiffrées à l'ouverture de votre session.

On peut aussi gérer l'agent en ligne de commande avec **ssh-add**:

<code bash>
ssh-add
</code>

Utilise directement la //clé_privée// ''~/.ssh/id_rsa'', mais on peut lui spécifier un fichier de clé privée en paramètre.

Si l'agent n'est pas démarré sur une machine, il est possible de l'activer dans une session console avec: 

<code bash>
eval "$(ssh-agent)" ; ssh-add ~/.ssh/id_rsa
</code>

<wrap lo>Pour connaître les clés privées actuellement déchiffrées en mémoire: ''ssh-add -L''. Pour supprimer les clés déchiffrées de la mémoire ''ssh-add -D''.</wrap>

==== Transmission d'un agent ssh ====

L'option ''-A'' de ssh (ou encore la présence de l'option ''ForwardAgent yes'' pour la connexion cible dans votre fichier de configuration), permet de transmettre l'accès à votre agent ssh local pour la session ssh distante que vous ouvrez. Ceci autorise l'utilisation de votre //clé_privée// dans cette session distante sans avoir à installer le fichier ni à la dé-verrouiller.

<WRAP center round important 80%>
Quand **ne pas transmettre son agent ssh**… si cette option est pratique, elle ouvre un accès à l'ensemble des clés déverrouillées au niveau de votre agent ssh à toute personne qui a un accès à votre compte sur la machine cible (root, cracker) – cette personne peut alors se faire passer pour vous sur toutes les machines où vos //clés_publiques// ont été installées.

Cette option est donc à utiliser avec parcimonie, uniquement lorsque besoin et pour des connexions à des machines de confiance. 
</WRAP>
 
==== Agent ssh sous MacOS ====

Il est possible de démarre un agent SSH comme service sous MacOS: [[https://usercomp.com/news/1044072/using-ssh-agent-on-mac|How to Use ssh-agent as a System Service on Mac]].

Il est aussi possible d'utiliser le portefeuille de mots de passe associé au compte en spécifiant l'option ''UseKeychain yes'', et de laisser les clés débloquées avec l'option ''AddKeysToAgent yes'' dans la configuration ssh. Cf. Apple [[https://developer.apple.com/library/archive/technotes/tn2449/_index.html|Technical Note TN2449]]). 


===== Passerelles =====

Il est courant qu'un site protège les accès SSH en obligeant le passage par une machine relai qui assure que le service de connexion est bien à jour au niveau sécurité, et que seules les personnes autorisées peuvent se connecter aux machines du site.

SSH permet ainsi de rebondir (jump) de machine en machine pour rejoindre une machine cible.

Lors de l'utilisation des machines pour "rebondir" vers d'autres machines, il est possible de transférer un accès au trousseau de clés de votre agent ssh.


===== Tunnels =====


===== Sécurité =====


  * Il est conseillé de conserver une sauvegarde des fichiers correspondant à vos jeux de clés — une //clé_publique// ou une //clé_privée// perdue l'est définitivement.

  * La //clé_privée//, protégée par une passphrase, ne devrait jamais être transmise par des moyens de communication non sûrs (par exemple on ne l'envoie pas en utilisant un système email hors institutions).

  * Sur les machines dont vous avez la gestion (par exemple une machine personnelle), il est primordial d'effectuer très régulièrement les mises à jour afin de corriger les failles de sécurité lorsqu'elles apparaissent (ce n'est d'ailleurs pas particulier à SSH).

  * Par défaut la conservation d'une //clé_privée// en mémoire par l'agent SSH dure tant que l'agent fonctionne, mais on peut spécifier une limite de temps.

  * Le transfert de l'accès à votre trousseau de clés SSH (Agent Forwarding) ne doit se faire que sur des machines auxquelles vous pouvez faire entièrement confiance. Une personne malintentionnée avec un accès d'administration sur ces machines pourrait en effet utiliser le transfert de votre trousseau pour se faire passer pour vous.

  * Lorsqu'on dépose un //clé_publique// pour autoriser un accès SSH, il est possible de spécifier des règles de sécurité à appliquer (restrictions sur la commande possible à lancer, sur les adresses des machines d'où on peut se connecter…).

  * On ne place jamais la //clé_publique// d'un utilisateur tiers sur son compte, car celui-ci pourra alors se connecter en usurpant votre identité. S'il y a des informations à partager ce n'est pas le bon moyen.

  * Le logiciel d'accès distant serveur SSH est sensible aux droits d'accès donnés sur les répertoire ~/.ssh et les fichiers qu'il contient. Typiquement vous seul devez y avoir accès (chmod 700 ~/.ssh et chmod 600 ~/.ssh/*).

  * Il est possible d'avoir plusieurs jeux de clés, par exemple utilisés dans des contextes de sécurité différents. Attention toutefois à ne pas les multiplier, et à la complexification des procédures de connexion.

==== Changement de passphrase ====

Au cas où vous auriez malencontreusement oublié de mettre une passphrase sur votre clé privée, ou bien si vous trouvez celle-ci trop légère… elle peut être changée :

  ssh-keygen -f ~/.ssh/id_rsa -p


===== Configuration =====

Un fichier de configuration ''~/.ssh/config''((L'option ''-F'' de ssh permet de spécifier le fichier de configuration à utiliser.)) permet de définir des options à appliquer suivant les machines sur lesquelles on doit se connecter.

Ce fichier enchaîne, du début à la fin, l'identification de modèles et l'application des options qui suivent. Pour chaque connexion, l'ensemble du fichier est parcouru (plusieurs modèles peuvent être reconnus et leurs options appliquées). S'il y a une connexion relai par une passerelle, il est aussi parcouru //séparément// pour celle-ci. Les options positionnées avant le premier modèle sont systématiquement appliquées.

<WRAP center round important 80%>
Si une option a déjà été fixée, sa valeur ne peut pas être redéfinie. **Les modèles les plus génériques doivent donc être positionnés à la fin du fichier.** 
</WRAP>


L'identification de base des modèles, avec le mot clé  **Host**, repose sur une reconnaissance de la machine cible de la connexion ssh (généralement par son nom DNS). Il est possible d'utiliser ''*'' pour spécifier différentes machines, et d'indiquer plusieurs chaînes de reconnaissance séparées par des espaces. Il est possible d'utiliser des noms à notre choix et de spécifier la machine cible avec l'option //HostName// ; les noms seront utilisés par la complétion ssh sous Unix.

<code>
…
Host m123.lisn.upsaclay.fr m167.lisn.upsaclay.fr m54.lisn.upsaclay.fr berlioz.lisn.upsaclay.fr
…
Host *.lisn.upsaclay.fr
…
Host via
…
Host via-inside
…
Host via-outside
…
</code>

L'identification avancée, avec le mot clé  **Match**, permet de __combiner logiquement différentes expressions__ pouvant être de la reconnaissance de machine cible (encore avec Host) ou le résultat d'exécution de programmes/scripts externes (avec **Exec** ou **!Exec**).

<code>
…
Match Host *.lisn.upsaclay.fr Exec "/usr/bin/test -f %d/.ssh/usegw/use_vialisn"
…
Match Host subversion.renater.fr,git.renater.fr !Exec %d/bin/inside_lisn.sh
…
Match Exec "nslookup %h | grep 'pl-ssh.lisn.upsaclay.fr'"
…

</code>

<WRAP center round tip 80%>
Avec ''Match Host'', il faut séparer les différents noms de machines cibles par des virgules.
</WRAP>

<WRAP center round tip 80%>
Avec ''Match Exec'', l'expression est considérée valide si le programme/script sort avec un code ''0'' et invalide s'il sort avec un code ''≠0'' (≈erreur).
</WRAP>


==== Options ssh ====

Liste non exhaustive, [[https://linux.die.net/man/5/ssh_config|se référer à la documentation]] pour la liste complète. Ces options peuvent être surchargées lorsd de l'appel à ''ssh'' avec des arguments ''-o Option=Valeur''.

=== Accès à la machine distante ===

  * **HostName** indique le nom DNS ou bien l'adresse IP du serveur distant à contacter (défaut fourni par la ligne de commande). La possibilité de spécifier ici la machine cible permet de se créer de multiples entrées dans la configuration du client ssh et d'utiliser la complétion basée sur les modèles //Host// avec des noms de machine arbitraires de son choix.\\ ''HostName 129.175.17.124''
  * **ServerAliveInterval**  délai pour le renvoi d'un message en cas d'inactivité afin de maintenir la connexion ouverte (défaut 0, pas de message renvoyé).\\ ''ServerAliveInterval 60''
  * **ServerAliveCountMax** nombre maximum de messages envoyés au cas où le serveur ne répond pas (défaut 3).\\  ''ServerAliveCountMax 2'' 
  * **ProxyJump** indique une machine par laquelle rebondir. À noter que le fichier de configuration ssh est à nouveau utilisé pour cette connexion de rebond (ie. la configuration pour accéder à la machine de rebond est utilisée).\\ ''ProxyJump pl-ssh.lisn.upsaclay.fr'' 
  * **Port** permet de faire une connexion ssh vers un port non standard (défaut 22).\\ ''Port 443''

<WRAP center round info 80%>
Avant l'existence de l'option ProxyJump, on utilisait l'option **ProxyCommand**\\ ''ProxyCommand ssh -W %h:%p via.lisn.upsaclay.fr''.
</WRAP>

=== Authentification ===


  * **User**  permet de spécifier le login par défaut à utiliser (défaut login local actuel).\\ ''User monlogin''
  * **IdentityFile** indique le fichier de clé à utiliser pour l'authentification.\\ '' IdentityFile ~/.ssh/cle_specifique''
  * **IdentitiesOnly** indique de n'utiliser que les clés fournies par IdentityFile((Peut être utile si on a de nombreuses clés ssh déverrouillées dans l'agent ssh, pour ne pas dépasser le nombre d'essais avant que la bonne clé ne soit testée.)) (défaut no).\\ ''IdentitiesOnly yes''
  * **ForwardAgent** indique de transmettre une connexion vers l'agent ssh actuel (celui utilisé pour cette connexion) vers la machine distante afin de pouvoir utiliser ces mêmes clés (défaut no). Comme déjà indiqué, pour des raisons de sécurité <wrap hi>cette option ne doit être activée qu'avec des machines de confiance</wrap> et ne surtout pas être mise par défaut pour toutes les machines.\\ ''ForwardAgent yes''
  * **PubkeyAuthentication** permet de désactiver/activer l'utilisation des clés pour la connexion (défaut yes).\\ ''PubkeyAuthentication no''
  * **KbdInteractiveAuthentication** évite une possible demande de passphrase ou de mot de passe (défaut yes).\\ ''KbdInteractiveAuthentication no''

=== Tunnels ===

  * **ForwardX11** ouvre un tunnel spécifique pour l'acheminement des requêtes d'affichage X11 vers la machine locale (défaut no). Cette option positionne la variable ''DISPLAY'' sur la session distante.\\ ''ForwardX11 yes''

=== Inclusion ===

  * **Include** <sup>(client OpenSSH≥7.3)</sup> permet de prendre en compte des éléments de configuration définis dans un autre fichier. Cela permet par exemple d'avoir votre configuration ssh sur un espace synchronisé entre différents ordinateurs.\\ ''Include ~/nextCloudCirrus/configs/ssh_config''

=== Environnement ===

  * **SendEnv** spécifie les variables d'environnement (ou ensemble de variables avec un pattern) qui doivent être transmises de la session sur la machine locale vers la session sur la machine distante.\\ ''SendEnv GIT_*''

<WRAP center round important 80%>
Il faut aussi que le serveur ssh de la machine distante ait été configuré pour accepter les variables d'environnement, par exemple dans ''/etc/ssh/sshd_config'' :

    AcceptEnv LANG LC_* GIT_*
</WRAP>



==== Exemples configuration ssh ====

<WRAP center round tip 80%>
À adapter avec **VOS paramètres de configuration** (login, passerelle, machines cibles, éventuellement fichiers de clés…).
</WRAP>

Rappel, la configuration va __du particulier au général__, une option fixée avec un modèle ne peut pas être modifiée avec un modèle postérieur.

=== Exemple simple ===

<file ~/.ssh/config>
# File: ~/.ssh/config
Host passerelle-labo
    HostName 129.175.8.242
    User bidule
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Host machine_cible machine_cible.lisn.upsaclay.fr
    ForwardAgent yes
    ForwardX11 yes
    IdentitiesOnly yes

Host machine_cible *.lisn.upsaclay.fr
    User bidule
    IdentityFile ~/.ssh/id_rsa

Host *.lisn.upsaclay.fr
    ProxyJump passerelle-labo
</file>

**[[fr:ssh-params#configuration_ssh_config|Exemple intermédiaire]]**

=== Exemple avancé ===

Plus complet, avec un test si vous êtes dans ou hors du laboratoire (besoin de passer par la passerelle ou non) en utilisant un script externe. Et avec un exemple d'accès à Lab-IA avec un ou deux rebonds (rebond par une machine autorisée vers Lab-IA, avec rebond par la passerelle si nécessaire).

<WRAP center round important 80%>
**Attention:** l'utilisation d'un script externe avec ''Exec'' peut compliquer la recherche lors de problèmes de connexion ssh. C'est une fonctionnalité pour utilisateur averti (et capable de se débrouiller…). \\
En alternative il vaut mieux utiliser une configuration un peu plus longue basée sur la reconnaissance de la machine saisie sur la ligne de commande (par exemple avec/sans le nom de domaine) pour sélectionner les options à utiliser.
</WRAP>


<file ~/.ssh/config>
# File: ~/.ssh/config
Host passerelle-labo
    HostName 129.175.8.242
    User bidule
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Match Host machine_cible.lisn.upsaclay.fr
    ForwardAgent yes
    ForwardX11 yes
    IdentitiesOnly yes
    
Match Host machine_cible.lisn.upsaclay.fr !Exec ~/nextCloudCirrus/bin/inside_lisn.sh
    ProxyJump passerelle-labo

Host *.lisn.upsaclay.fr
    User bidule
    IdentityFile ~/.ssh/id_rsa

Match Host *.lisn.upsaclay.fr !Exec ~/nextCloudCirrus/bin/inside_lisn.sh
    ProxyJump passerelle-labo

Host slurm slurm.lab-ia.fr
    User bidulealt
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes
    # Là la passerelle dépend si vous êtes côté belvédère ou plaine.
    ProxyJump verslabia.lisn.upsaclay.fr
</file>

===== Configuration avec putty =====

==== Création d'un profil de connexion à via.lisn.upsaclay.fr ====

{{::putty-via.png?400|1}}{{::putty-via2.png?400|2}}{{:putty-via3.png?400|3}}

  * Cette connexion sera utilisée pour le rebond à l'intérieur du labo.
  * remplacer lisn-login par votre login
  * attention au format de la clé, propre à putty

==== Création d'une connexion vers une machine interne en utilisant via ====

{{::putty-serveurparvia1.png?400|1}} {{::putty-serveurparvia2.png?400|2}}

  * utilisez ce profil pour rebondir sur une machine interne
  * remplacer 'unserveur.lisn.upsaclay.fr' par le serveur sur lequel vous voulez aboutir 

===== Trucs & astuces =====

==== Raccourcis avec complétion ====

Il est possible de définir, dans le fichier de config ''.ssh/config'', des **Host avec les noms que l'on veut**. En ligne de commande il y a une complétion sur ''ssh'' qui utilise ces définitions de Hosts, on peut donc avoir des //raccourcis// pour les machines couramment utilisées, pour lesquelles on fournit tous les paramètres de connexion, et qui sont facilement activables (raccourcis utilisables aussi avec ''scp''…).

<code>
Host lisn-perso
    User bidule
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_rsa
    Hostname machine_cible.lisn.upsaclay.fr
    ForwardX11 yes
    ProxyJump passerelle-labo
</code>

En saisissant ''ssh lisn''//<tab>// tous les hosts définis en //lisn// dans le fichier de config vont s'afficher et s'il y en a un seul qui est sélectionnable il sera directement complété, par exemple ''ssh lisn-perso''.

{{tag>acces_distant}}