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 Putty offre une interface graphique pour SSH, mais Microsoft fournit aussi le client ssh
en ligne de commande via WSL (Windows Subsystem for Linux).
Putty existe aussi pour Linux et MacOS X, mais il y est nettement moins souvent utilisé.
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 afin de faire transiter d'autres flux de communication par le même canal (x2go, Proxy web…).
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 :
ssh machine_cible
(é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
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:~$
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.
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:~$
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:
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.
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.
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:
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
Si tout est bon, il suffit de supprimer la ligne correspondante indiquée du fichier ~/.ssh/known_hosts
.
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.
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).
Pensez à sauvegarder vos fichiers de clés ssh1) 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
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 "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.
Sur son poste de travail, on génère un jeu de clés SSH avec la commande:
ssh-keygen -t rsa -b 4096
Il faut répondre aux questions:
~/.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.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 !
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.
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
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
ssh-rsa AAAAB3NzaC1yc… …Ufq3PeJXSIN4eDkP7hQ== bidule@plop
La clé_privée est aussi un fichier texte, content une représentation chiffrée de la clé.
~/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABCF6qDIcB udEpeWoB79ob2CAAAAEAAAAAEAAAIXAAAAB3NzaC1yc2EAAAADAQABAAACAQDjn4GXfstx … … uSRJHWq206wx/Bdl+mBaSc/1/pMm3G7JKj2zmKKI1r9jLvAh+U62wInoR6BsiefUwMNGY4 m6day8zfc+ZZW5p+hZ56yGVFs= -----END OPENSSH PRIVATE KEY-----
À la place de l'algorithme RSA, il est possible d'utiliser l'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"
.
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 :
ssh-copy-id -i ~/.ssh/id_rsa.pub machine_cible.lisn.upsaclay.fr
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:
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.
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.
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
.
On utilise ssh normalement :
ssh machine_cible.lisn.upsaclay.fr
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:
bidule@plop:~$ ssh machine_cible.lisn.upsaclay.fr Enter passphrase for key '/home/bidule/.ssh/id_rsa': … bidule@machine_cible:~$
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.
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:
ssh-add
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:
eval "$(ssh-agent)" ; ssh-add ~/.ssh/id_rsa
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
.
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.
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.
Il est possible de démarre un agent SSH comme service sous MacOS: 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 Technical Note TN2449).
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.
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
Un fichier de configuration ~/.ssh/config
2) 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.
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.
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.
… 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 …
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).
… 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'" …
Avec Match Host
, il faut séparer les différents noms de machines cibles par des virgules.
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).
Liste non exhaustive, 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
.
HostName 129.175.17.124
ServerAliveInterval 60
ServerAliveCountMax 2
ProxyJump pl-ssh.lisn.upsaclay.fr
Port 443
Avant l'existence de l'option ProxyJump, on utilisait l'option ProxyCommand
ProxyCommand ssh -W %h:%p via.lisn.upsaclay.fr
.
User monlogin
IdentityFile ~/.ssh/cle_specifique
IdentitiesOnly yes
ForwardAgent yes
PubkeyAuthentication no
KbdInteractiveAuthentication no
DISPLAY
sur la session distante.ForwardX11 yes
Include ~/nextCloudCirrus/configs/ssh_config
SendEnv GIT_*
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_*
À adapter avec VOS paramètres de configuration (login, passerelle, machines cibles, éventuellement fichiers de clés…).
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.
# 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
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).
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.
# 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
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
…).
Host lisn-perso User bidule IdentitiesOnly yes IdentityFile ~/.ssh/id_rsa Hostname machine_cible.lisn.upsaclay.fr ForwardX11 yes ProxyJump passerelle-labo
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
.
-F
de ssh permet de spécifier le fichier de configuration à utiliser.