![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
SSH, le shell sécurisé, cet outil constitue la pierre angulaire de l'accès à distance aux système informatiques. Dans l'esprit, cet outil hérite des remote commands connues sous les noms de rsh, rexec ou rlogin, mais ajoute une couche de chiffrement de bout en bout plus que nécessaire, en particulier pour une utilisation sur Internet. Les remote commands originelles, en tant que telles, devraient rester au XXème siècle.
Dans les faits, SSH est un protocole réseau permettant un échange chiffré entre deux machines. Typiquement, dans un sens, des commandes sont saisies par le client, et le serveur renvoie l'état de la session en ligne de commande effectuée à distance. Ce protocole peut également être utilisé pour transférer des fichiers entre plusieurs machines, au moyen du sous-système sftp, reléguant du même coup des outils comme ftp à la même place que les remote commands.
ATTENTION : et notez l'usage des capitales en plus des caractères gras. Avant de mettre à disposition un serveur SSH accessible sur Internet, il est impératif que tous les comptes accessibles sur la machine serveur aient des mots de passe solides, ou des accès par clés publiques uniquement. Par mot de passe solide, soyons d'accord, un mot de huit caractères en provenance du dictionnaire, c'est insuffisant. Les recommandations de l'ANSSI seront normalement plus à jour que cette page, quant à savoir comment produire un bon mot de passe.
SSH nécessite d'avoir un serveur sshd à disposition, ainsi qu'un client SSH quelconque. L'implémentation typique des serveurs SSH sous Unix ou Gnu est celle fournie par le projet OpenSSH. Ce projet fournit non seulement le serveur sshd, mais également le client ssh classique, utilisable en ligne de commande, et le client sftp, qui est dédié au transfert de fichiers. Sont également mis à disposition, toute une collection de commandes, dédiées pour l'essentiel au fonctionnement des connexions sans mot de passe.
Pour établir une connexion sur une machine distante, en partant du principe que vous y avez un utilisateur :
$ ssh utilisateur@nom-de-la-machine utilisateur@nom-de-la-machine's password: Message of the day: Welcome! utilisateur@nom-de-la-machine:~$ _
À chaque connexion, votre mot de passe est demandé, fort heureusement quelque part. Le nom d'utilisateur est facultatif, et peut être omis, si votre nom d'utilisateur local correspond à votre nom d'utilisateur distant :
utilisateur@client$ ssh serveur utilisateur@serveur's password: Message of the day: Welcome! utilisateur@serveur$ _
Le prompt vous permet de travailler sur la machine distante comme si elle était sous votre nez, ce qui est pratique pour accéder à une machine pendant que quelqu'un d'autre travaille dessus, ou quand cette machine est à l'autre bout du monde, ou enfermée dans une salle machine.
Jusqu'à présent, seuls les programmes en ligne de commande peuvent être exécutés dans cet environnement. Si vous travaillez sur une machine disposant d'un serveur graphique X, il est possible de faire du transfert d'écran, en passant les bonnes options lors de la connexion :
$ ssh -X machine
Ceci fait, le lancement de programmes graphiques depuis la ligne de commande à distance devient possible :
serveur$ xterm serveur$ xclock serveur$ xeyes
Pour vérifier rapidement que l'affichage a pu être mis en place, le contenu de la variable DISPLAY peut également être consulté :
$ echo $DISPLAY localhost:10.0
En local, le localhost est normalement omis. À distance, anciennement, c'est le nom de la machine locale qui était utilisé pour le transport d'écran. Cette dernière configuration ne sera pas vue plus en détail car appartenant au XXème siècle.
Un sous-système courant, fournit par sshd, est le service SFTP. Ce service peut être utilisé avec la commande sftp. Cette commande interactive est calquée sur le vénérable client ftp :
client$ sftp serveur Connected to serveur sftp> ls .ssh .ssh/authorized_keys .ssh/known_hosts .ssh/known_hosts.old sftp> put .ssh/id_ecdsa.pub Uploading .ssh/id_ecdsa.pub to /home/utilisateur/id_ecdsa.pub .ssh/id_ecdsa.pub 100% 272 89.7KB/s 00:00 sftp> exit
Beaucoup d'utilitaires ne faisant pas partie d'OpenSSH font usage de ce sous-sytème SFTP. L'outil tiers le plus notable est probablement rsync, dont le comportement par défaut est d'utiliser le protocole SSH pour les transferts de fichiers, en lieu et place de son propre protocole Rsync, qui peut être utilisé quand le temps de chiffrement lors des transferts devient un problème. Un autre exemple notable est Borg, pour effectuer des sauvegardes sur une machine distante.
À noter, la commande scp, qui permet également de transférer des fichiers, ne fait pas usage du sous-sytème SFTP. C'est important de le noter, car dans certaines situations, l'accès direct aux lignes de commandes peut être interdit par le serveur sshd, et seul le transfert de fichiers via SFTP est autorisé, ce qui a pour effet de casser scp. Dans ce cas là, pour automatiser les transferts, Rsync est à préférer.
Paradoxalement, l'utilisation des clés de chiffrement permet de renforcer la sécurité des connexions SSH, tout en... permettant de se connecter sans taper de mot de passe, et donc d'automatiser les opérations à distance. Il se trouve que, bien que la connexion vers le serveur SSH soit chiffrée, le mot de passe fourni lors de l'authentification est vu en clair par le serveur. Si ce dernier a pu être compromis, par un détournement de serveur DNS par exemple, alors le mot de passe est vu en clair par la machine vérolée sur laquelle la connexion a été effectuée.
En utilisant les clés de chiffrement asymétriques, le serveur ne voit pas plus passer de mot de passe en clair, que de clé privée en clair. En effet, la clé privée de l'utilisateur est combinée à la clé publique fournie par le serveur au moment de la connexion, et servant à valider, ou non, la connexion, par rapport aux clés publiques connues du serveur.
Les clés de chiffrement du serveur sont produites automatiquement à l'installation d'OpenSSH. Les clés de chiffrement de l'utilisateur ne sont produites que sur demande. La commande ssh-keygen permet de produire une paire de clés publique et privée par défaut au format RSA, mais les recommandations de l'ANSSI sont plutôt à l'usage des courbes elliptiques. Voici une manière de produire de telles clés, approuvée à ce jour par le gouvernement :
$ ssh-keygen -t ecdsa -b 521 Generating public/private ecdsa key pair. Enter file in which to save the key (/home/tokamak/.ssh/id_ecdsa): Created directory '/home/tokamak/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/tokamak/.ssh/id_ecdsa. Your public key has been saved in /home/tokamak/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:cxidCrjYkzzYjXi2Y4NksMJAmoCUqVlSVlZGwIhC53A tokamak@fusion-pwr The key's randomart image is: +---[ECDSA 521]---+ |=B=E+++ | |O=B..o . . | |B+ .. . . o | |=o B = . + | |o.* % . S . | |.o + + o | | . = | | . o | | | +----[SHA256]-----+
Si la passphrase est laissée vide, tout accès à la clé privée pourra être effectué automatiquement. Sinon, la clé privée sera chiffrée par la passphrase et il faudra la fournir à chaque tentative d'accès à la clé privée.
La commande a produit deux fichiers dans votre répertoire .ssh/ : un fichier id_ecdsa contenant la clé privée à ne pas laisser trainer n'importe où, et un fichier id_ecdsa.pub contenant la clé publique, à diffuser partout où elle sera nécessaire. Voici un exemple de clé publique, ça tient en une ligne :
client$ cat .ssh/id_ecdsa.pub ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAH2tqwr6JCdL/zHGr+/5XeKGHPg2vTmdTufFIoM9tcS/DVcQP+upPcbQfH94LSVvBtFwQlSVHhAz+FcKe3fu42xAgFN0AXmZQQODFq9FYEuNCtPvviV/+A7vSOCyGhLCkFEkmToBlZtSST9LqG+cFV8OpLFO7ZAY7z3nTFABR1UyNl0Tg== tokamak@fusion-pwr
Pour permettre la connexion SSH par clé asymétrique, la clé publique ainsi produite sur le client doit être récupérée et recopiée du côté du serveur, dans le fichier .ssh/authorized_keys. Ces quelques commandes permettent de procéder :
client$ scp .ssh/id_ecdsa.pub serveur: client$ ssh serveur serveur$ cat id_ecdsa.pub >> .ssh/authorized_keys
En terme général, la lecture du manuel de ssh, et ses commandes auxiliaires, est chaudement recommandée, mais quelques opérations courantes sont décrites ci-après :
$ man ssh $ man ssh-keygen $ man ssh-agent $ man ssh-add
Pour changer de passphrase, l'option -p est de rigueur, et attention à ne pas la saisir par erreur dans le champ de sélection du fichier stockant la clé privée :
$ ssh-keygen -p Enter file in which the key is (/home/tokamak/.ssh/id_rsa): Enter old passphrase: Key has comment '' Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.
Pour mémoriser une passphrase, un processus ssh-agent doit tourner, et votre environnement doit y être raccordé. Les variables correspondantes sont SSH_AGENT_PID, indiquant l'identifiant de l'agent SSH utilisé, et SSH_AUTH_SOCK indiquant dans quelle socket la communication avec l'agent s'établit. La plupart des environnements de bureau démarrent un agent SSH sans que l'utilisateur de la machine n'ait à s'en inquiéter. Si un agent doit être rattaché à un environnement particulier à une commande, ssh-agent peut être utilisé pour lancer cette commande et lui faire hériter du bon environnement, Par exemple pour une session graphique :
$ ssh-agent startx
Pour une session de multiplexeur de terminal tmux :
$ ssh-agent tmux
Une fois l'agent lancé et l'environnement de travail correct, pour charger un clé privée protégée par passphrase, la commande ssh-add peut, et depuis Debian 9 doit, être utilisée :
$ ssh-add Enter passphrase for /home/tokamak/.ssh/id_ecdsa:
À ce moment, les connexions SSH sans mot de passe, par clé publique protégée, peuvent enfin être effectuées :
$ ssh emlwks999.eu Linux fusion-pwr 4.19.8-fusion #4 SMP PREEMPT Sun Dec 9 18:18:14 CET 2018 x86_64 [...]
Un serveur SSH accessible sur Internet, c'est du pain béni pour les pirates informatiques. Le renforcement de la protection d'un serveur SSH accessible sur Internet est un impératif absolu. L'essentiel consiste à configurer correctement le serveur SSH, en éditant le fichier /etc/ssh/sshd_config, mais des solutions additionnelles devraient être mises en œuvre pour renforcer la sécurité contre les tentatives de connexions abusives, ou réduire la surface d'attaque.
Un point important est d'interdire complètement les connexions directes en tant qu'administrateur. L'option correspondante dans /etc/ssh/sshd_config est :
PermitRootLogin no
Un point supplémentaire est l'obligation de passer par les clés de chiffrement, ce qui est plus sûr que de passer un mot de passe en clair, et bien sûr d'interdire les tentatives de connexion par mot de passe :
PubkeyAuthentication yes PasswordAuthentication no
Enfin, redémarrez le service :
$ sudo invoke-rc.d ssh restart
L'assistance d'outils comme fail2ban contre les tentatives d'accès par force brute se révèlera appréciable. Mais gardez un œil constant sur toute activité suspecte ; au moindre souci, arrêtez tout, fermez l'entrée dans la table NAT du routeur. Ce n'est pas parce que la sécurité est renforcée que le système est invulnérable. Si l'accès à distance n'est plus nécessaire, alors le mieux est de le couper jusqu'à la prochaine utilisation.
Au risque de me répéter, jetez un œil aux recommandations de l'ANSSI avant mettre à disposition un tel service en ligne. Outre le fait de provoquer des dégâts sur votre infrastructure informatique, votre machine peut également participer à amplifier les dégâts sur d'autres équipements, en rejoignant un groupe d'ordinateurs zombis. Laisser une telle situation trainer n'a rien de responsable.
Dans certaines situations, les connexions par clé asymétriques sont refusées, alors même que les instructions ci-dessus sont suivies. C'est probablement dû aux droits Unix appliqués à l'un des répertoires menant jusqu'au .ssh/. En effet, si un seul de ces répertoires est world writable, autrement dit que n'importe quel processus, n'importe quel utilisateur peut écrire dedans, alors SSH empêche l'accès. Vos droits Unix devraient ressembler à quelque chose de ce genre :
$ ls -ld /home/tokamak/.ssh drwx------ 2 tokamak tokamak 4096 Dec 8 23:15 /home/tokamak/.ssh $ ls -ld /home/tokamak/ drwx--x--x 69 tokamak tokamak 4096 Dec 9 21:46 /home/tokamak/ $ ls -ld /home/ drwxr-xr-x 5 root root 4096 Nov 16 21:11 /home/ $ ls -ld / drwxr-xr-x 24 root root 4096 Dec 5 00:22 /
Attention : avoir l'un de ces répertoires avec ce genre de droits est à proscrire, et c'est ce contre quoi le serveur SSH essaiera de vous protéger :
$ ls -ld /home/tokamak/.ssh drwxrwxrwx 2 tokamak tokamak 4096 Dec 8 23:15 /home/tokamak/.ssh
Lors d'une tentative de transfert d'écran, le message d'erreur suivant peut apparaitre, et avoir plusieurs origines :
$ ssh -X machine X11 forwarding request failed on channel 0
En terme général, activer la verbosité de SSH devrait permettre de trouver l'origine du problème (attention, le client SSH devient dans ce cas très bruyant) :
$ ssh -vvv -X machine
Mais ce n'est pas toujours le cas. Un point à vérifier est la disponibilité de l'IPv6 sur le serveur cible. En effet, par défaut, sshd est configuré pour écouter, sur les interfaces réseau de la machine, en IPv4 et en IPv6 ; c'est la configuration AddressFamily any. Or, dans certaines situations, les interfaces réseau en IPv6 ne sont pas disponibles. Suite à une vulnérabilité de sécurité corrigée il y a peut-être une décennie, dans cette situation, le X11 forwarding ne se fait pas. Deux solutions sont possibles, soit configurer au moins l'interface réseau du loopback pour comprendre l'IPv6 :
serveur$ sudo ip address add ::1 dev lo
Soit le serveur sshd doit être configuré pour n'écouter les connexions que sur les interfaces réseau IPv4, en éditant le fichier /etc/ssh/sshd_config et en réglant la variable suivante :
AddressFamily inet
Un redémarrage du serveur SSH sera alors nécessaire :
$ sudo invoke-rc.d sshd reload
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - |
Cet article a été achevé de rédiger le 22 décembre 2018.
Divers ajustements, notamment un changement de nom de machine dans l'un des exemples de connexion, ont été effectués le 20 juin 2021.