SSH signifie Secure SHell. C'est un protocole qui permet de faire des connexions sécurisées (i.e. cryptées) entre un serveur et un client SSH. Nous allons utiliser le programme OpenSSH, qui est la version libre du client et du serveur SSH.
Installer un serveur SSH permet aux utilisateurs d'accéder au système à distance, en rentrant leur login et leur mot de passe (ou avec un mécanisme de clés). Cela signifie aussi qu'un pirate peut essayer d'avoir un compte sur le système (pour accéder à des fichiers sur le système ou pour utiliser le système comme une passerelle pour attaquer d'autres systèmes) en essayant plein de mots de passes différents pour un même login (il peut le faire de manière automatique en s'aidant d'un dictionnaire électronique). On appelle ça une attaque en force brute.
Il y a donc trois contraintes majeures pour garder un système sécurisé après avoir installé un serveur SSH :
-
avoir un serveur SSH à jour au niveau de la sécurité, ce qui doit être le cas si vous faites consciencieusement les mises à jour de sécurité en suivant la procédure Debian, comme expliqué au chapitre Le réseau et la sécurité ;
-
que les mots de passes de TOUS les utilisateurs soient suffisamment complexes pour résister à une attaque en force brute ;
-
surveiller les connexions en lisant régulièrement le fichier de log
/var/log/auth.log.
Un mot de passe complexe est un mot de passe qui ne veut rien dire, qui n'est pas dans le dictionnaire et qui comporte au moins 8 caractères, de préférence avec un mélange de lettres minuscules, de lettres majuscules, de chiffres et de caractères de ponctuation.
Une bonne méthode pour obtenir un mot de passe complexe et facile à retenir consiste à choisir une phrase et à prendre la première lettre de chaque mot, avec quelques complications en plus.
Par exemple, la phrase "Linux, moi j'y comprends rien de rien !" donne le mot de passe L,mj'ycr2r!
Pour vérifier que les mots de passe des utilisateurs du système sont vraiment complexes, le root peut les soumettre à un cracker de mots de passe... et voir combien de temps ils résistent !
Les mots de passes des utilisateurs sont stockés dans le
fichier /etc/shadow. Seul l'utilisateur
root peut lire ce fichier. Pour tester la complexité des mots
de passes, le root peut donc installer le programme john et le lancer sur le
fichier /etc/shadow :
#apt-get install john#john /etc/shadow
Quand john a trouvé un mot de passe, il l'affiche avec le login associée.
Attention, john utilisera le processeur à 100 % ! Il est donc conseillé de lui donner un priorité faible (commande nice ou renice) si la machine doit être utilisée pendant ce temps. Plus le nombre d'utilisateurs est grand, plus il faudra laisser tourner john longtemps pour que le test soit significatif.
SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que la clé privée doit rester secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.
Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.
SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé secrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète. Toute autre personne en possession de la clé secrète peut décrypter le message.
La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie asymétrique... mais le gros problème est l'échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé par SSH et par les navigateurs Web, la cryptographie asymétrique est utilisée au début de la communication pour que A et B puissent s'échanger une clé secrète de manière sécurisée... puis la suite la communication est sécurisée grâce à la cryptographie symétrique en utilisant la clé secrète échangée.
Pour plus d'informations sur la cryptographie, je vous conseille la lecture du dossier consacré à ce sujet par le magazine pour la science dans son hors-série de Juillet-Octobre 2002.
Un serveur SSH dispose d'un couple de clés RSA
stocké dans le répertoire /etc/ssh/
et généré lors de l'installation du serveur. Le fichier
ssh_host_rsa_key contient la clé privée et a les
permissions 600. Le fichier ssh_host_rsa_key.pub
contient la clé publique et a les permissions 644.
Nous allons suivre par étapes l'établissement d'une connexion SSH :
-
Le serveur envoie sa clé publique au client.
-
Le client génère une clé secrète et l'envoie au serveur, en cryptant l'échange avec la clé publique du serveur (cryptographique asymétrique). Le serveur décrypte la clé secrète en utilisant sa clé privée, ce qui prouve qu'il est bien le vrai serveur.
-
Pour le prouver au client, il crypte un message standard avec la clé secrète et l'envoie au client. Si le client retrouve le message standard en utilisant la clé secrète, il a la preuve que le serveur est bien le vrai serveur.
-
Une fois la clé secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clé secrète commune (cryptographie symétrique).
-
Une fois que le canal sécurisé est en place, le client va pouvoir envoyer au serveur le login et le mot de passe de l'utilisateur pour vérification. La canal sécurisé reste en place jusqu'à ce que l'utilisateur se déloggue.
La seule contrainte est de s'assurer que la clé publique présentée par le serveur est bien sa clé publique... sinon le client risque de se connecter à un faux serveur qui aurait pris l'adresse IP du vrai serveur (ou toute autre magouille). Une bonne méthode est par exemple de demander à l'administrateur du serveur quelle est le fingerprint de la clé publique du serveur avant de s'y connecter pour la première fois. Le fingerprint d'une clé publique est une chaîne de 32 caractères hexadécimaux unique pour chaque clé ; il s'obtient grâce à la commande ssh-keygen -l.
Le client SSH est disponible dans le paquet openssh-client, qui est préinstallé.
Pour pouvoir vous connecter à distance, vous pouvez maintenant installer le serveur SSH :
#apt-get install openssh-server
L'installation comporte une étape de génération des clefs de cryptage. Finalement, le serveur SSH se lance.
Le fichier de configuration du serveur SSH est
/etc/ssh/sshd_config. À ne pas confondre avec le
fichier /etc/ssh/ssh_config, qui est le fichier de
configuration du client SSH.
Nous allons vous commenter les lignes les plus importantes de ce fichier de configuration :
-
Port 22
Signifie que le serveur SSH écoute sur le port 22, qui est le port par défaut de SSH. Vous pouvez le faire écouter sur un autre port en changeant cette ligne. Vous pouvez aussi le faire écouter sur plusieurs ports à la fois en rajoutant des lignes similaires.
-
PermitRootLogin yes
Signifie que vous pouvez vous logguer en root par SSH. Vous pouvez changer et mettre "no", ce qui signifie que pour vous connecter en root à distance, vous devrez d'abord vous connecter par SSH en tant que simple utilisateur, puis utiliser la commande su pour devenir root. Sans celà, un pirate n'aurait qu'à trouver le mot de passe du compte root, alors que là, il doit trouver votre login et votre mot de passe.
-
X11Forwarding yes
Signifie que vous allez pouvoir travailler en export display par SSH. Ce sera expliqué plus tard, dans le chapitre Faire de l'export display.
Si vous avez modifié le fichier de configuration du serveur, il faut lui dire de relire son fichier de configuration :
#/etc/init.d/ssh reloadReloading OpenBSD Secure Shell server's configuration.
C'est la méthode la plus simple. Depuis la machine cliente, tapez :
%ssh login@nom_DNS_du_serveur_SSH
-
Si c'est la première connexion SSH depuis ce client vers ce serveur, il vous demande si le fingerprint de la clé publique présentée par le serveur est bien le bon. Pour être sûr que vous vous connectez au bon serveur, vous devez connaître de façon certaine le fingerprint de sa clé publique et la comparer à celle qu'il vous affiche. Si les deux fingerprints sont identiques, répondez yes, et la clé publique du serveur est alors rajoutée au fichier
~/.ssh/known_hosts. -
Si vous vous êtes déjà connecté depuis ce client vers le serveur, sa clé publique est déjà dans le fichier
~/.ssh/known_hostset il ne vous demande donc rien.
Ensuite, entrez votre mot de passe... et vous verrez apparaître le prompt, comme si vous vous êtiez loggué en local sur la machine.
Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH.
Pour générer un couple de clés DSA, tapez :
%ssh-keygen -t dsa
Les clés générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.
Par défaut (il demande confirmation lors du processus
de création), la clé privée est stockée dans le fichier
~/.ssh/id_dsa avec les permissions
600 et la clé publique est stockée dans le fichier
~/.ssh/id_dsa.pub avec les permissions 644.
Lors de la création, il vous demande une pass phrase qui est un mot de passe pour protéger la clé privée. Cette pass phrase sert à crypter la clé privée. La pass phrase vous sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous logguerez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois... comme nous le verrons un peu plus loin dans ce chapitre.
Note
Vous pouvez à tout moment changer la pass phrase qui protège votre clé privée avec la commande ssh-keygen -p.
Pour cela, il suffit de copier votre clé publique dans le fichier
~/.ssh/authorized_keys de la machine sur laquelle
vous voulez vous logguer à distance. La commande suivante permet de
réaliser cette opération via SSH :
%ssh-copy-id -i ~/.ssh/id_dsa.pub login@nom_DNS_du_serveur
et entrez le mot de passe de votre compte sur le serveur.
Le transfert de fichiers par SSH est possible de deux façons :
-
avec scp (comme Ssh CoPy), qui s'utilise la même manière que la commande cp ;
-
avec lftp, dont je vous avais déjà parlé au chapitre Le Web et le FTP en console pour les transferts de fichiers par FTP.
Encore une fois, vous pouvez utiliser la méthode d'authentification par mot de passe ou par clés, l'utilisation est la même.
Pour illustrer la syntaxe, je vais donner quelques exemples :
-
pour transférer le fichier
test1.txtsitué dans le répertoire courant vers le home du compte toto de la machine ordi1.exemple.org sur laquelle tourne un serveur SSH :%scp test1.txt toto@ordi1.exemple.org: -
pour récupérer le fichier
test2.txtsitué le home de l'utilisateur toto de la machine ordi2.exemple.org et l'écrire dans le répertoire courant :%scp toto@ordi2.exemple.org:test2.txt . -
pour récupérer tous les fichiers ayant l'extension
.txtsitués dans le répertoire/usr/localde la machine ordi2.exemple.org et l'écrire dans le sous-répertoiretest-scpdu répertoire courant :%scp toto@ordi2.exemple.org:/usr/local/*.txt test-scp -
pour transférer l'intégralité du sous-répertoire
test-scpdu répertoire courant vers le sous répertoireincomingdu home de l'utilisateur toto de la machine ordi1.exemple.org :%scp -r test-scp toto@ordi1.exemple.org:incoming
Je vous avais déjà parlé d'utilisation de lftp comme client FTP dans la section Le FTP en console. Mais ce que je ne vous avais pas dit, c'est que lftp sait aussi transférer des fichiers par SSH !
Pour l'installation et la configuration de lftp, reportez-vous à la section Le FTP en console.
Pour se connecter par SSH en utilisateur toto sur le serveur ordi1.exemple.org :
%lftp sftp://toto@ordi1.exemple.org
Ensuite, les commandes sont exactement les mêmes que lors de l'utilisation de lftp comme client FTP !
Gnome permet de se connecter à un serveur SSH directement dans Nautilus. Comme pour FTP, cela permet d'accéder aux fichiers distants depuis toutes les applications Gnome.
Pour cela, allez dans le menu Raccourcis > Se connecter à un serveur, puis choisissez SSH, et réglez les paramètres de connexion.
Cette section s'adresse à ceux qui utilisent un couple de clés publiques / privées, et qui ont crypté leur clé privée avec une pass phrase (c'est la configuration la plus sûre). Par conséquent, le client SSH demande la pass phrase à chaque utilisation des clés pour s'authentifier.
Pour éviter d'avoir à taper systématiquement sa pass phrase, il faut utiliser ssh-agent : ce programme tourne en tâche de fond et garde la clef en mémoire. La commande ssh-add permet de donner sa clé à ssh-agent. Ensuite, quand vous utilisez le client SSH, il contacte ssh-agent pour qu'il lui donne la clé.
Dans une console, ouvrez un screen avec ssh-agent en tâche de fond :
%ssh-agent screen
Puis donnez votre clé à l'agent :
%ssh-add
Il vous demande alors votre pass phrase.
Maintenant que votre clé a été transmise à l'agent, vous pouvez vous
connecter sans entrer de mot de passe à toutes les machines
pour lesquelles vous avez mis votre clé publique dans le fichier
~/.ssh/authorized_keys.
Faire un tunnel SSH est un moyen simple de crypter n'importe quelle communication TCP entre votre machine et une machine sur laquelle vous avez un accès SSH.
Par exemple, pour établir un tunnel SSH pour une connexion HTTP vers la machine serveur.exemple.org :
%ssh -L 2012:serveur.exemple.org:80 toto@serveur.exemple.org
où 2012 est le port sur la machine cliente à partir duquel la connexion entre dans le tunnel SSH (le port doit être supérieur à 1024 si on ne veut pas avoir à lançer le tunnel en tant que root, et le pare-feu ne doit pas bloquer ce port).
Ensuite, il suffit de lançer un navigateur Web en lui demandant de se connecter en local sur ce port :
%w3m http://localhost:2012
Telnet, c'est comme SSH... mais en moins bien ! Telnet est un protocole qui permet d'accéder à distance à une machine, mais la connexion n'est pas sécurisée : le mot de passe et les données sont transférés en clair ! Telnet ne permet pas de faire des transferts de fichiers. Il est donc conseillé de ne pas utiliser Telnet mais uniquement SSH.
Le client Telnet se trouve dans le paquet telnet. Ce paquet est installé par défaut.
Le serveur Telnet se trouve dans le paquet telnetd. Il n'y a aucune configuration à faire.
Pour se connecter à un serveur Telnet, tapez :
%telnet nom_DNS_du_serveur_telnet
et ensuite rentrez votre login et votre mot de passe quand il vous le demande.