SSH

SSH Secure SHell

Principes

Le but de SSH est d'accéder à un shell sur une machine distance via une connexion sécurisée (chiffrée) et authentifiée.

La sécurisation des données

La sécurisation nécessite un algorithme de chiffrement (il y en a des myriades) et une clé pour la session. Les principes sont similaires à ce que vous utilisez sur des sites Internet sécurisés (https://). Les machines se mettent d'accord sur:

• un algorithme de chiffrement à utiliser
• puis, via un autre algorithme, sur une clé de chiffrement sans que cette clé ne soit envoyée sur le réseau.

La même clé est utilisée pour chiffrer et déchiffrer un message, on parle donc de chiffrement symétrique.

L'authentification

SSH peut authentifier un utilisateur avec un login/mot de passe. Cependant pour de nombreux cas d'usage, il est fastidieux de saisir ces informations à chaque connexion. SSH peut donc remplacer l'authentification classique par une authentification par clés.

Attention

Ce sont des clés d'authentification, pas des clés de chiffrement.

Authentification par clés

L'authentification par clés est utilisée par SSH mais aussi par de nombreux services web, en particulier GitLab et GitHub.

Attention

Il est très important de bien comprendre ce qui suit, car vous en aurez besoin assez souvent dans les années à venir.

Le principe de l'authentification par clé est de travailler avec une paire de clés dites privée et publique. Si on appelle K la fonction de chiffrement de la clé privée et P la fonction de chiffrement de la clé publique, le chiffrement par clé pour un message M garanti (résumé rapide):

• K(P(M)) = M
  • ceci rend possible le déchiffrement par tout possesseur de la clé publique du message chiffré par la clé privée
• P(K(M)) = M
  • ceci rend possible le déchiffrement du message chiffré par la clé publique uniquement par le possesseur de la clé privée
• Il n'existe aucune autre fonction F calculable telle que F(K(M)) = M, K(F(M)) = M, F(P(M)) = M ou P(F(M)) = M
  • ceci empêche un observateur ayant intercepté la clé publique de fabriquer un message chiffré valide pour la destination, et donc d'usurper l'identité de chiffrement de la source

On parle de chiffrement asymétrique

Info

Dans la pratique SSH, l'authentification est faite en échangeant des messages chiffrés avec ces clés dans les deux sens. Une fois l'authentification validée, la sécurisation (chiffrement) de la connexion utilise une autre clé (voir ci-dessus) pour des raisons d'efficacité, le chiffrement asymétrique étant plus coûteux en ressources que le chiffrement symétrique.

Par conséquent:

• La clé privée:
  • ne doit jamais être communiquée
  • doit rester en lecture seule pour l'utilisateur seulement et aucune permission pour groupe ou reste du monde (protection locale de la clé)
• La clé publique:
  • peut être communiquée au monde entier
  • doit être installée sur les machines où vous vous connectez depuis votre machine

Configuration

Résumé

Pour configurer une communication SSH, il va falloir :

• Créer une paire de clés, clé privée et clé publique
• Déposer la clé privée dans votre répertoire ~/.ssh avec les bonnes permissions
• Ajouter la clé publique dans le fichier ~/.ssh/authorized_keys sur toutes les machines où vous voulez vous connecter
  • alternativement, téléverser la clé publique via l'interface GitHub/GitLab/autre pour les services en ligne utilisant des clés
• Sur votre machine, faire ssh suivi de l’adresse de la machine cible

Test SSH sans clés

Pour se connecter à une machine, par exemple tp-1a201-01,

ssh login@tp-1a201-01

Le shell vous demandera de saisir le mot de passe de votre compte unix. Tant que vous n'aurez pas installé de clés (ce que nous allons voir ensuite), votre mot de passe sera demandé à chaque connexion.

À chaque connexion à une machine, votre ssh vérifie qu'il parle à la bonne machine et, pour cela, il vérifie que l'empreinte (fingerprint en anglais) de la machine correspond à l'empreinte qu'il connaît À chaque fois que vous vous connectez à une machine nouvelle, ssh affichera un message pour vous dire qu'il ne connaît pas encore cette machine et vous demandera de vérifier que c'est bien la bonne machine à laquelle vous vous connectez. Pour s'assurer de parler à la bonne machine, il faut vérifier que l'empreinte est la bonne lors de la première connexion. Si vous êtes sur le réseau de Télécom et que vous vous connectez à une machine de Télécom, vous pouvez accepter sans vérifier.

Quittez la connexion en tapant exit ou logout.

Info

Le nom des machines des salles de TP à l'école est de la forme tp-NOM_DE_LA_SALLE-xx. La liste des machines ainsi que leur disponibilité est consultable sur ce site.

Création des clés

Pour créer une pairs de clés publique/privée il faut utiliser la commande suivante :

ssh-keygen -a 100 -t ed25519 -C "login@telecom-paris.fr"

Danger

Ne pas utiliser putty qui génère des fichiers dans un autre format.

Dans cette commande :

• le paramètre -t ed25519 permet de spécifier l'algorithme utilisé pour générer la paire de clés. Ici, on choisit l'option ED25519 (pas DSA, pas RSA, pas ECDSA). La clé obtenue est courte mais très solide.
• le paramètre -a 100 permet de spécifier le niveau de protection du mot de passe qui protège la clé.
• le paramètre -C "login@telecom-paris.fr" permet de nommer votre clé.

Cette commande va aussi vous demander deux renseignements :

• tout d'abord elle va vous demander où stocker la clé avec une question de la forme Enter file in which to save the key (/home/login/.ssh/id_ed25519): si vous tapez entrée (sans rien renseigner) la clé sera stockée dans le répertoire par défaut (ici /home/login/.ssh/id_ed25519). Il est conseillé de laisser ce paramètre par défaut car tous les utilitaires (ssh, git, scp) vont essayer de chercher dans ce répertoire par défaut.
• ensuite on va vous demander un mot de passe qu'il faudra répéter. Il est possible de laisser le mot de passe vide mais il est très fortement conseillé de mettre un mot de passe. En effet, si votre machine est volée ou piratée ou que la clé privée est diffusée par erreur, une clé sans mot de passe permettra à quiconque l'ayant récupérée de se faire passer pour vous pour tous les services configurés avec cette clé.

La commande va générer deux fichiers, par défaut aux chemins suivants :

• la clé privée: ~/.ssh/id_ed25519
• la clé publique: ~/.ssh/id_ed25519.pub

La clé privée est, comme son nom l'indique, privée et ne doit être lisible que par son propriétaire. Si vous avez modifié les permissions, vous pouvez la remettre en mode lecture seule:

chmod 400 ~/.ssh/id_ed25519

Note

La commande que nous avons donnée, ajoute des options pour préciser entre autres l'algorithme et le commentaire. Ces paramètres sont optionnels et nous pouvons utiliser la commande ssh-keygen sans aucune option et ça fonctionnera. L'algorithme utilisé par défaut dépendra de la version de OpenSSH et le commentaire par défaut sera votrelogin@votremachine La clé générée sera ~/.ssh/id_NOM_DE_L_ALGORITHME.

Ajout de la clé publique

Vous devez mettre le contenu de la clé publique à la fin du fichier ~/.ssh/authorized_keys de la machine distante.

Le plus simple est de vous connecter à la machine en question et d'éditer le fichier et copier/coller le contenu de la clé publique:

ssh login@tp-1a201-01
nano ~/.ssh/authorized_keys
exit

Vous pouvez aussi copier la clé via l'utilitaire scp qui est une version sécurisée de cp via SSH:

scp ~/.ssh/id_ed25519.pub login@tp-1a201-01:~/
ssh login@tp-1a201-01
cat ./id_ed25519.pub >> ~/.ssh/authorized_keys
rm ./id_ed25519.pub
exit

Faites attention à copier/coller correctement le contenu de votre clé publique complète, sans éléments supplémentaires. Si le fichier ~/.ssh/authorized_keys n’est plus de la bonne forme, l'authentification par clé ne fonctionnera plus sur cette machine.

Pour éviter ce genre de problèmes, utilisez la commande ssh-copy-id (disponible avec les versions récentes de ssh) qui s'occupera de modifier correctement le fichier authorized_keys.

Par exemple:

# À partir de la machine locale
ssh-copy-id -i ~/.ssh/id_ed25519.pub  login@tp-1a201-01

Test de la connexion

Pour se connecter à une machine, par exemple tp-1a201-01,

ssh login@tp-1a201-01

Le shell vous demandera de saisir le mot de passe de la clé privée et non plus celui de votre compte école.

SSH Agent

ssh-agent est un programme qui gère l'authentification des clés pour vous, ne vous demandant le mot de passe qu'une seule fois pour une session donnée.

Selon les systèmes d'exploitation, ssh-agent démarre tout seul. Il peut être démarré manuellement comme suit:

ssh-agent -s

Pour éviter de taper le mot de passe de vos clés à chaque fois, ajoutez au fichier ~/.ssh/config:

Host *
  AddKeysToAgent yes

Une alternative est d'ajouter manuellement les clés:

ssh-add ~/.ssh/id_ed25519

Pour quitter une session SSH, tapez exit ou logout.

Utilisations de SSH

Copier des fichiers

SSH vient avec l'utilitaire scp qui vous permet de copier des fichiers vers une machine distance via SSH. C'est très utile pour des transferts de petits fichiers et répertoires. L'utilitaire est très similaire à cp, il faut juste ajouter login@machine: avant le nom du fichier ou répertoire cible.

Copie d'un fichier:

scp test/fichier.txt login@machine:~/temp/

Copie d'un répertoire:

scp -r test/res/ login@machine:~/temp/

Attention à ne pas oublier : dans le nom de machine:

scp -r test/res/ machine

Cette commande se comportera comme cp et copiera juste le répertoire..

La commande marche évidemment dans les deux sens:

scp -r  login@machine:~/temp/res/ .

scp  login@machine:~/temp/fichier.txt .

Note

Pour les plus avancés, vous pouvez utiliser l'utilitaire rsync qui sait transférer des fichiers en utilisant une connexion SSH. Il a pour avantage de ne pas transférer les fichiers qui existent à l'identique sur la machine distante. Il sait aussi reprendre un transfert interrompu en ne transférant que les parties manquantes. Pour démarrer avec rsync.

Démarrer un programme

Vous pouvez démarrer automatiquement un programme ou un script suite à la connexion SSH. Par défaut le répertoire à la connexion SSH est votre répertoire utilisateur sur la machine distante.

Lancer who pour voir qui est connecté à la machine:

ssh login@host who

Lancer un script

ssh login@host '~/project/run.sh'

Vous pouvez lancer plusieurs commandes comme vu dans le chapitre terminal

ssh login@host 'cmd1 ; cmd2 && cmd3'

Dans tous ces cas, la connexion SSH prendra fin une fois les commandes passées en paramètres exécutées.

Clés multiples

Il est possible d'avoir plus d'une paire de clé, par exemples des clés pour l'école, des clés un service externe tel que GitHub, etc...

Lors de la génération de clés, ajoutez l'option -f FICHIER pour indiquer le nom du fichier de clé à créer:

ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_new_key -C "you@telecom-paris.fr"

Ceci créera les clés ~/.ssh/id_new_key et ~/.ssh/id_new_key.pub.

Suivez les étapes que précédemment pour la copie de la clé publique sur les machines cibles.

Puis, lors de la connexion, passez -i cle à ssh:

ssh -i ~/.ssh/id_new_key login@tp-1a201-01

Comme il est fastidieux de se souvenir quelle clé correspond à quel service, vous pouvez configurer cette association dans le fichier ~/.ssh/config.

Voici un exemple d'un tel fichier

Host *
  AddKeysToAgent yes
  IdentitiesOnly yes

Host gitlab.enst.fr
  PreferredAuthentications publickey
  User git
  IdentityFile ~/.ssh/id_new_key

Ce fichier indique:

• d'ajouter les clés à l'agent SSH pour toutes les destinations possibles (Host *)
• utiliser la clé privée id_new_key pour GitLab (Host gitlab.enst.fr)
  • en s'identifiant comme l'utilisateur git

Transfert d'agent SSH

Lorsque vous vous connectez à une machine par SSH, votre répertoire personnel sur cette machine n'est vraisemblablement pas le même que le répertoire personnel sur votre machine, et vos informations de clés sont donc différentes. Si vous voulez pouvoir accéder depuis cette machine distante à un service nécessitant l'authentification par clé (autre machine via SSH, GitLab), vous n'aurez plus vos clés !

Attention

Une possibilité est de copier votre clé privée: à éviter impérativement. Moins vous avez de copies de vos clés privées, meilleure est la sécurité.

Par ailleurs, si vous partagez ce répertoire personnel avec d'autres utilisateurs, vous n'avez pas spécialement envie de communiquer votre clé privée à vos camarades !! Votre réflexe dans ce cas sera de créer une clé privée pour cet utilisateur commun pour accéder à GitLab par exemple.

Ceci est une mauvaise pratique en développement de code, car vous créez ainsi un utilisateur virtuel non identifiable et surtout utilisé par plusieurs personnes. Si une modification de code introduit un bug, vous ne pourrez plus identifier qui est à l'origine du changement et en discuter avec lui.

Fort heureusement, SSH vous permet de "transférer votre identifiants/clés" à travers une connexion sécurisée, de manière à pouvoir utiliser votre configuration SSH locale pour des authentifications par clés à partir de votre session distante. Toutes les demandes d'authentification faite dans la session SSH distantes seront validées par le programme ssh-agent s'exécutant sur la machine locale, sans que les clés quittent votre machine.

Pour cela, ajoutez l'option -A lors de votre connexion initiale:

ssh -A login@machine

Il est possible d'activer automatiquement le transfert d'agent en ajoutant dans le fichier ~/.ssh/config:

Host tp-1a201-01.enst.fr
     ForwardAgent yes

ForwardAgent yes indique qu'une connexion SSH depuis la machine identifiée par Host pourra utiliser les clés de l'agent de la machine locale.

Vous pouvez l'activer sur toutes les machines via Host * mais ce n'est pas recommandé, en particulier si vous ne connaissez pas le niveau de sécurité de la machine distante.

Attention

Le transfert d'agent SSH pour toutes les machines distantes n'est pas la solution la plus sécurisée. Il est recommandé d'utiliser des clés séparées, de n'exposer qu'un sous-ensemble de clés lors du transfert d'agent et de mettre des restrictions sur l'utilisation des clés via ssh-add -h.

Perte de clés

Si par accident/vol/erreur/etc vous perdez votre clé privée, enlevez immédiatement les clés publiques correspondantes de toutes les machines et services web l'utilisant.

Lorsque vous allez vouloir vous connecter en SSH à une machine, vos clés ne seront plus correctes et la connexion sera rejetée. SSH essayera une autre méthode d'authentification et vous demandera votre login et mot de passe.

Vous pouvez forcer SSH à ne pas utiliser l'authentification par clé en tapant:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no \
    login@tp-5d02-02 

Tunnel SSH

Le VPN connecté fait virtuellement migrer votre machine dans l’école, ce qui peut vous empêcher de vous servir de certains services normalement accessibles depuis chez vous, mais interdits par l’école.

En outre, par choix de sécurité, le VPN de l'école ne vous laissera pas forcément voir toutes les machines de l'école.

Si ce cas vous arrive, vous devez utiliser la passerelle ssh.enst.fr qui permet de voir toutes les machines.

Plutôt que de faire :

ssh login@ssh.enst.fr
#puis une fois connecté
ssh tp-1a201-01

Vous pouvez directement aller à la machine cible en indiquant de passer par ssh.enst.fr comme intermédiaire (on parlera de tunnel SSH).

ssh -J login@ssh.enst.fr login@tp-5d02-02 

Note

Le login n'est pas obligatoirement le même pour les deux machines, par exemple si la machine cible est une machine non administrée par la DSI.

Pour les plus avancés, si vous avez besoin d'un tunnel pour plusieurs connexions, vous pouvez utiliser l'outil sshuttle.