SSH

SSH est un protocole réseau permettant d'établir une communication chiffrée entre deux machines. Il est notamment utilisé pour se connecter à distance à un serveur SSH, y exécuter des commandes ou transférer des fichiers de manière sécurisée.

Par défaut, le service sshd d'un serveur SSH écoute sur le port TCP 22. On utilise un client SSH pour établir une connexion avec ce serveur.

SSH permet de sécuriser différentes pratiques informatiques :

• Il remplace Telnet en permettant d'exécuter des commandes depuis un réseau local ou Internet.
• Il permet de partager de fichiers (voir SFTP), à la manière de SMB ou FTP, mais cette fois de manière suffisamment sécurisée pour être adaptée à Internet.
• Il sécurise n'importe quel protocole ou application réseau, en proposant d'encapsuler les communications dans un tunnel chiffré (voir proxy SSH). On peut donc sécuriser n'importe quel service grâce à SSH, dont des services domestiques tels que partage de fichiers (via d'autres protocoles moins sécurisés), service multimédia, bureau à distance, domotique, etc., ou déporter sa navigation Web à la manière d'un VPN.

Les usages de SSH sont entre autre :

• accéder à distance au terminal, ce qui permet d'effectuer la totalité des opérations courantes et/ou d'administration sur la machine distante
• déporter l'affichage graphique de la machine distante (bureau à distance)
• transferts de fichiers
• montage ponctuel de stockage distant, soit en ligne de commande, soit via GNOME Fichiers par exemple.
• montage automatique de stockage distant
• déporter et sécuriser de nombreux autres services ou protocoles (voir SSH Avancé).

OpenSSH est la solution la plus utilisée pour mettre en place une communication SSH. Il fournit un ensemble d'outils libres dont certains sont installés par défaut sur Ubuntu.
Comme son nom l'indique, OpenSSH est développé dans le cadre du projet OpenBSD.
C'est cette solution qui est traitée sur cette page.

Pour accéder à une machine à distance (ordinateur personnel, serveur distant qu'on administre, box, etc.), installer le paquet openssh-server sur cette machine. Elle sera le serveur SSH.

La fonctionnalité client est fournie par le paquet openssh-client, qui est installé par défaut sur Ubuntu. Elle permet d'utiliser le terminal local pour créer et accéder à une session distante.

On peut vérifier ce qui est déjà installé avec la commande :

ssh -V

qui devrait retourner une ligne du type OpenSSH_8.2p1 Ubuntu-4ubuntu0.12, OpenSSL 1.1.1f 31 Mar 2020.

La commande suivante permet de connaître la version de la bibliothèque TLS (anciennement SSL, le nom est resté) :

dpkg -l libssl*

Le serveur SSH fonctionne en tant que service lancé automatiquement au démarrage de la machine.

Il est notamment possible de :

• l'activer ou l'arrêter : pour par exemple désactiver momentanément le service
• le relancer : utile entre autre après une modification de la configuration.

Vous trouverez en fin de cette page plus d'information sur la configuration du serveur SSH, peu sécurisée par défaut.

Saisissez dans un terminal la commande suivante :

sudo systemctl status ssh

Saisissez dans un terminal la commande suivante :

sudo systemctl start ssh

sudo systemctl stop ssh

sudo systemctl restart ssh

Sur Ubuntu, le client OpenSSH est déjà installé par défaut. Dans le cas contraire, installer le paquet openssh-client, qui fournit la commande ssh.

Pour contrôler une machine distante depuis un poste équipé de Windows, on peut aussi installer et utiliser PuTTY, qui est publié sous licence MIT.

Le client (ainsi que le serveur) OpenSSH sont aussi disponibles nativement sur Windows.¹⁾

Il existe aussi des clients SSH pour Android (ConnectBot), iOS, et la pluaprt des systèmes d'exploitation.

Pour ouvrir une session distante en SSH (se connecter à un serveur) avec la commande ssh :

ssh nom_utilisateur@hôte -p numéro_de_port

où

• nom_utilisateur est le nom d'utilisateur à utiliser sur la machine distante
• hôte est le nom d'hôte de la machine distante, qui peut être un nom de domaine, une adresse IPv4, ou un nom mDNS ou NetBIOS en local
• numéro de port est le numéro du port sur lequel écoute le serveur.

Exemple :

ssh bernadette@example.com -p 12345

L'option -p numéro_de_port est facultative. Si rien n'est précisé, c'est le port 22 qui sera utilisé par défaut (avec le protocole TCP).

Pour se connecter avec SSH en IPv6 depuis un terminal :

ssh -6 nom_utilisateur@adresse_IPv6

où adresse_IPv6 est l'adresse IPv6 du serveur.

Exemple :

ssh -6 bernadette@2620:2d:4000:1::28

Pour se connecter en SSH avec la plupart des autres outils, on utilise une URL.

Celle-ci ressemble un peu à la commande ssh du chapitre précédent. Elle est de la forme :

ssh://nom_utilisateur@hôte:numéro_de_port

où

• nom_utilisateur est le nom d'utilisateur à utiliser sur la machine distante
• hôte est le nom d'hôte de la machine distante, qui peut être un nom de domaine, une adresse IP (IPv4 ou IPv6 cette fois), ou un nom mDNS ou NetBIOS en local
• numéro de port est le numéro du port sur lequel écoute le serveur.

• En plus d'afficher les bureaux à distance, Remmina est aussi un client SSH, et donne accès au terminal.

On trouve aussi de nombreuses applications Flatpak sur Flathub :

• SSH Pilot
• EasySSH
• SSH Studio
• Putty

Voir les clients SFTP.

X.org est déprécié au profit de Wayland. Ce chapitre n'est plus d'actualité !

La commande ssh offre une fonctionnalité intéressante : la possibilité d'exécuter des applications X-Window à distance, ce qui est bien pratique pour travailler à distance, partager une machine ou simplement effectuer des tâches d'administration.

Il suffit de passer l'option -X à ssh :

ssh -X nomtilisateur@Ipserver

Et on peut lancer :

nomUtilisateur@Ipserver$ xeyes

là, l’œil de Moscou vous regarde depuis votre écran local !

Pour copier un fichier à partir d'un ordinateur sur un autre avec SSH, on peut utiliser les commandes scp ou rcp :

scp <fichier> <username>@<ipaddressDistant>:<DestinationDirectory>

et en IPv6 :

scp -6 <élément> <nom>@[addresse ipv6]:<destination>

Pour un fichier :

scp fichier.txt hornbeck@192.168.1.103:/home/hornbeck

et en IPv6

scp -6 fichier.txt albertine@[2a01:e35:2431::2a34]:/home/albertine

Pour un répertoire :

scp -r répertoire hornbeck@192.168.1.103:/home/hornbeck/

et en IPv6

scp -6r répertoire/ albertine@[2a01:e35:2431::2a34]:/home/albertine

Vous pouvez aussi bien copier des fichiers à partir des ordinateurs à distance sur votre disque local :

scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt .

Ici, le point . à la fin de commande indique de copier le fichier dans le répertoire courant.

$ scp utilisateur@12.345.678.90:"le\ fichier" .
$ scp utilisateur@12.345.678.90:'"le fichier"' .  
# Notez les simples ' ET doubles " guillemets ' "

$ fichier="le fichier" #ou
$ fichier=le\ fichier
$ scp utilisateur@12.345.678.90:"'$fichier'" .
 
$ fichier="le\ fichier"
$ scp utilisateur@12.345.678.90:"$fichier" .

$ scp  le\ fichier utilisateur@12.345.678.90:
le fichier                          100%    0     0.0KB/s   00:00    
 
$ scp  "le fichier" utilisateur@12.345.678.90:
le fichier                          100%    0     0.0KB/s   00:00    

$ fichier="le fichier"  # ou
$ fichier=le\ fichier
$ scp  "$fichier" utilisateur@12.345.678.90:
le fichier                          100%    0     0.0KB/s   00:00    

Vous pouvez aussi le renommer en le copiant (« mon.txt ») sur le disque local (toujours dans le répertoire courant):

scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt ./mon.txt

Vous pouvez très bien copier un fichier d'un ordinateur vers un autre tout en étant sur un troisième ordinateur :

scp nom@ordi1:chemin/fichier nom@ordi2:chemin/fichier

Dans le cas où le port SSH du serveur ne serait pas le port par défaut (22), il faut indiquer le port distant à utiliser :

scp -P port fichier.txt hornbeck@192.168.1.103:/home/hornbeck

Vous pouvez sécuriser un répertoire en le dupliquant à travers le réseau en utilisant la commande rsync.

Exemple1 : Pour transférer le home d'un utilisateur a hébergé dans la machine b dont l'adresse IP est enregistrée dans le fichier /etc/hosts en excluant quelques fichiers avec un résultat à mettre dans le répertoire /MAISON qui sera automatiquement créé.

 sudo rsync -ahv --progress --stats --exclude={'.*','persistence.*'}  a@b:/home/a /MAISON 2>err.log 
cat err.log

SFTP est une autre méthode pour accéder à un support de stockage distant via SSH.

Il suffit de mettre en place une connexion SSH pour monter un serveur SFTP.

L'authentification par mot de passe (transmis chiffré) est le mode d'identification par défaut.

Autrefois tout le monde employait l'authentification typique par le principe identifiant - mot de passe. Cependant si quelqu'un connaît votre mot de passe ou le découvre au moyen d'une attaque la sécurité est compromise. De plus, utiliser un mot de passe différent pour chaque serveur et le saisir à chaque connexion peut s'avérer contraignant.

Pour se débarrasser des ces problèmes, SSH propose un système d'authentification par clé publique/privée au lieu des mots de passe simples.

Ceci peut permettre par exemple :

• à un administrateur de se connecter à des centaines de machines sans devoir connaître des centaines de mots de passe différents ;
• de ne pas avoir un mot de passe à saisir toutes les 2 minutes (en utilisant ssh-agent).

Ces clés restent des chaînes de caractères (en français courant : du texte), mais sont beaucoup plus longues et aléatoires que de simples mots de passe.

La clé privée est en principe unique : chaque utilisateur possède une clé privée qu'il peut copier sur les terminaux auxquels il accède physiquement et depuis lesquels il a besoin d'un accès SSH (via le client SSH). Cette clé se trouve généralement dans un fichier ~/.ssh/id_xxxx. C'est un document sensible très personnel, il faut y appliquer des droits très restrictifs : r-x --- --- (500) pour le répertoire .ssh et r-- --- --- (400) pour le fichier id_xxxx.
Pour un maximum de sécurité il est possible de protéger cette clé privée au moyen d'un mot de passe.

De son côté la clé publique est envoyée à tous les serveurs auxquels on veut accéder à distance afin qu'ils nous identifient avec certitude en vérifiant que le client possède bien la clé privée associée. Côté serveur cette clé publique sera stockée dans le fichier ~/.ssh/authorized_keys, avec éventuellement des options et les clés publiques d'autres utilisateurs à raison d'une par ligne.

Localement on peut stocker une clé publique par ex. dans un fichier id_xxxx.pub qui peut aussi se trouver dans le répertoire ~/.ssh, ou ailleurs (ce n'est pas un document sensible).

On peut générer une nouvelle clé publique depuis une clé privée mais pas l'inverse.

À moins que vous n'ayez déjà un couple de clés, vous devez d'abord en créer.
Exemple pour une clé utilisant l'algorithme de chiffrement ED25519, vous saisirez dans le terminal du client :

ssh-keygen -t ed25519 -C "email@example.com"

On peut également utiliser l'algorithme RSA, plus ancien, moins sûr, et générant des clés plus grosses :

ssh-keygen -t rsa -b 4096 -C "email@example.com"

Il vous sera alors demandé où enregistrer la clé privée (acceptez juste l'endroit par défaut : ~/.ssh, et ne changez pas le nom du fichier généré) puis de choisir une passphrase (phrase de reconnaissance).

ssh-keygen -y -f .ssh/id_ed25519 # qui va demander la passphrase et afficher la clé publique si la saisie est correcte

Votre clef publique a été créée avec la nouvelle clef privée. Elles sont habituellement localisées dans le répertoire caché ~/.ssh :

~/.ssh/id_ed25519.pub pour la clé publique et ~/.ssh/id_ed25519 pour la clé privée ou ~/.ssh/id_rsa.pub et ~/.ssh/id_rsa si vous avez utilisé l'algorithme RSA.

Pour que votre ssh-agent reconnaisse cette paire de clefs, il faut utiliser la commande ssh-add :

ssh-add
#ou plus directement 
ssh-add /chemin-complet/vers-la-cle/nom-cle

Vous pouvez également vérifier la liste des paires de clefs existantes avec l'option -l (-list) :

ssh-add -l

The agent has no identities.

Could not open a connection to your authentication agent.

eval "$(ssh-agent)"

ssh-add

Il faut maintenant envoyer au serveur votre clé publique pour qu'il puisse vous chiffrer des messages.

L'utilisateur distant doit avoir cette clé (c'est une ligne de caractères en code ASCII) dans son fichier de clés d'autorisation situé à ~/.ssh/authorized_keys sur le système distant. Employez la commande ssh-copy-id.

ssh-copy-id est un script qui utilise ssh pour se connecter à une machine à distance en utilisant le mot de passe de l'utilisateur. L'authentification par mot de passe doit donc être autorisée dans le fichier de configuration du serveur ssh (par défaut sur Ubuntu). Il change également les permissions des répertoires ~/.ssh et ~/.ssh/authorized_keys de l'hôte distant pour enlever l'accès en écriture du groupe (qui vous empêcherait de vous connecter si le serveur distant ssh a "StrictModes yes" dans son fichier de configuration, ce qui est le cas par défaut sur Ubuntu).

ssh-copy-id -i ~/.ssh/id_ed25519.pub <username>@<ipaddress>

ou si le port est différent du port standard 22 (notez les guillemets):

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p <num_port> "<username>@<ipaddress>"

Vous devrez alors donner le mot de passe utilisateur de cet ordinateur. Après l'ajout votre clé publique, vous devenez un hôte de confiance.

Si l'authentification par mot de passe est désactivée²⁾, alors vous aurez besoin de copier-coller votre clé suivant un autre moyen.
Voici une ligne à copier pour ajouter sa clé publique sur le serveur distant :

ssh login@serveur "echo $(cat ~/.ssh/id_id_ed25519.pub) >> .ssh/authorized_keys"

Lancez :

ssh <username>@<ipaddress> -p <num_port>

Dorénavant n'utilisez plus votre mot de passe mais votre passphrase pour vous connecter. Celle-ci sert à déchiffrer votre clé privée de votre système local.

Si ça ne marche pas, c'est-à-dire que le mot de passe vous est quand même demandé, essayez sur votre serveur la commande :

tail -f /var/log/auth.log

tandis que vous essayez de vous connecter. Si on vous parle de "vulnkey", c'est que par malchance ssh-keygen a généré une clé vulnérable. Recommencez alors la procédure depuis le début³⁾

Pour résumer, deux choses sont nécessaires pour obtenir un accès réellement sécurisant (et sécurisé ) par authentification à clé publique par rapport à l'authentification par mot de passe classique :

1. Votre clé privée, chiffrée ;
2. Votre passphrase, utilisée pour déchiffrer votre clé privée.

Si vous choisissez de ne pas avoir de mot de passe (ce qui est possible, voyez la prochaine section), vous aurez une sécurité moindre, ainsi que si vous utilisez une authentification uniquement par mot de passe, comparé à celle que vous pouvez avoir en combinant les deux.

Vous pouvez avoir avec SSH les deux modes d'authentifications actifs en même temps, par mot de passe et par clés.

Vous pouvez vouloir neutraliser l'authentification par mot de passe pour des raisons de sécurité, pour cela il faut modifier le fichier de configuration /etc/ssh/sshd_config de la manière suivante :

- A la ligne PasswordAuthentication mettre no

Au mois de mai 2008 a été découvert une faiblesse dans la génération des clés par OpenSSL des packages Debian et dérivés tels qu'Ubuntu. Pour résumer, si vous avez généré vos clés entre 2006 et mai 2008, il faut en créer de nouvelles après avoir mis à jour le système. Pensez alors à bien rediffuser vos clés.

Si, après avoir suivi ce tutoriel, un mot de passe est toujours demandé, il se peut que ce soit dû à un problème de droits sur votre Dossier Personnel.
Sur la machine distante regardez le fichier /var/log/auth.log pour y trouver des indications et notamment si la ligne suivante apparaît :

Authentication refused: bad ownership or modes for directory /home/votre_login

Alors faites :

chmod 755 $HOME

Et tout devrait rentrer dans l'ordre.

Si ce n'est toujours pas le cas, c'est que le serveur doit être configuré en mode de sécurité strict (c'est le cas par défaut sur Ubuntu).
Effectuez les opérations suivantes :

Sur le serveur :

• dans le fichier /etc/ssh/sshd_config, la ligne StrictModes yes indique que le serveur va être très pointilleux sur les droits du compte sur lequel on se connecte en ssh.
• saisissez ensuite les commandes suivantes

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

• Sur le client, dans /etc/ssh/ssh_config, ajoutez la ligne PreferredAuthentications publickey.

Parfois les clés de vos correspondants peuvent changer (réinstallation de machine par exemple), vous aurez alors droit à ce charmant message :

  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    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 the RSA host key has just been changed.
  The fingerprint for the RSA key sent by the remote host is
  xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
  Please contact your system administrator.
  Add correct host key in /home/<vous>/.ssh/known_hosts to get rid of this message.
  Offending key in /home/<vous>/.ssh/known_hosts:4
  RSA host key for <ip> has changed and you have requested strict checking.
  Host key verification failed.

Soit l'information est exacte et une machine a été corrompue, ou bien il s'agit juste d'un changement de clé (réinstallation par exemple) et dans ce cas il faut effacer les entrées dans le fichier .ssh/known_hosts de votre compte.
Avant la chose était relativement simple, la clé était directement associée au nom ou à l'IP de la machine cible. Ce n'est plus le cas à présent où elle est associée par UUID rendant quasiment impossible l'identification visuelle de la ligne concernée. Mais ssh étant sympathique, il vous indique quelle est la ligne du fichier concernée.
Pour reprendre l'exemple précédent on peut lire la ligne Offending key in /home/<vous>/.ssh/known_hosts:4 → la clé en erreur est donc située ligne 4 du fichier .ssh/known_hosts

Il existe cependant une méthode plus subtile en employant la commande suivante :

ssh-keygen -R <ip>

Vous pourrez ainsi effacer seulement l'adresse IP concernée et relancer un ssh.

Si vous souhaitez vous connecter par SSH avec une clef publique sur un compte dont le home est chiffré, il est important de faire attention à ce que sur le serveur le fichier/dossier .ssh/authorized_keys soit à la fois dans le home chiffré et déchiffré. En effet si le fichier authorized_keys est dans le home sous forme chiffré (.private), open_ssh ne pourra pas lire la clef publique attendue. Il faut donc créer un dossier .ssh et y mettre le fichier authorized_keys quand le home est démonté donc chiffré. Cependant, si vous ne le laissez pas aussi dans le home déchiffré et donc monté, la connexion SSH se fera avec la clef publique mais le home ne sera pas déchiffré automatiquement.

La meilleure solution est de créer des liens virtuels vers un dossier qui n'est pas soumis au chiffrement/déchiffrement comme expliqué ici

En principe chaque utilisateur possède une clé privée unique qui lui est propre, et envoie sa clé publique à autant de serveurs qu'il le souhaite. Cependant il est techniquement faisable de posséder plusieurs clés privées (mais c'est moins pratique et ça n'est pas plus sécurisé).

Lorsqu'on se connecte à plusieurs serveurs avec des clés privées différentes, il faut pouvoir indiquer à SSH quelle clé on veut utiliser pour la connexion, sinon, on rencontre par exemple l'erreur:

git@gitlab.com: Permission denied (publickey).

Pour indiquer au client SSH la clé qu'il doit utiliser pour chacun des serveurs on peut créer un fichier ~/.ssh/config (ou /etc/ssh/ssh_config pour tous les utilisateurs de la machine) dans lequel il faut spécifier pour chacun des serveurs la clé qui doit être utilisée :

Host adresse-serveur-sans-passphrase.com
User votreutilisateur
IdentityFile ~/.ssh/key-sans-passphrase
  
Host adresse-serveur-avec-passphrase.com
User votreutilisateur
IdentityFile ~/.ssh/key-avec-passphrase

Pour plus d'options, comme l'utilisateur ou le port à utiliser par défaut, voir le manuel de ssh_config, cf. aussi l'aide de gitlab (en)

Retrouver l'empreinte de notre clef SSH, pour la communiquer à une personne qui veut se connecter et va utiliser notre clef publique :

ssh-keygen -l

Ensuite la commande demande le fichier de la clef publique. Sur un serveur on spécifiera /etc/ssh/ssh_host_rsa_key.pub.

La configuration par défaut du serveur SSH sous Ubuntu est suffisante pour fonctionner correctement. Le fichier de configuration à éditer avec les droits d'administration est /etc/ssh/sshd_config.

Tableau des principales directives à modifier le cas échéant :

Pour plus d'informations consultez man sshd_config.

Le client peut aussi être configuré par et pour chaque utilisateur via un fichier ~/.ssh/config.

Ce fichier ne requiert pas de permission administrateur pour être créé ou édité (avec un gestionnaire de fichiers il suffit d'afficher les fichiers cachés).

• Il permet de grandement simplifier la ligne de commande.
• Il est pris en compte par GNOME Fichiers pour se connecter facilement en SFTP (et par d'autres outils système).
• Il est sauvegardé avec le reste de son répertoire personnel ($HOME) et ainsi très simple à conserver ou à migrer d'un système à un autre.

Il est possible de configurer le client de manière indépendante pour chaque serveur (ou chaque hôte), et au passage de créer facilement des "alias" pour ces hôtes avec ces configurations, en spécifiant un Host (nom d'hôte à passer à la commande ssh) différent du HostName (nom d'hôte réel).
Par exemple :

Host serveur-perso
	HostName			192.168.1.2
	User				root
	PreferredAuthentications	password

Host serveur-cloud
	HostName	example.com
	User		moi-même
	Port		2222
	IdentityFile	~/chemin/orginal/id_ed25519

Il peut notamment être intéressant d'ajouter

	ServerAliveInterval 240

Pour que le client envoie un rappel au serveur (ici toutes les 4 minutes) afin que ce dernier ne coupe pas la liaison, ce qui peut bloquer le terminal.

Pour les autres options, voir (en) ssh_config - OpenBSD manual page server.

Host db.infra
	ForwardAgent	yes
	User		moi-même

Host *.infra
	User		root

Il peut arriver que les ports des connexions entrantes sur un serveur SSH soient bloqués ⁴⁾. Cependant, il est rare que les ports sortants soient fermés. Dans ce cas, il est possible de faire appel à du Reverse-SSH tel qu'expliqué sur cette page.

• site officiel d'OpenSSH
• cssh : Cluster SSH
• note ministérielle du 17 août 2015 : Recommandations pour un usage sécurisé d'(Open)SSH
• Guide de Mozilla pour la configuration d'OpenSSH
• Tutoriels sur l'utilisation et la configuration avancée de SSH sur IT-Connect
• Guide de ssh-audit pour blinder la configuration
• ssh_avance Fixme !

Contributeurs : sx1, krodelabestiole, Zer00CooL, bruno.