Qu'est-ce que SSH ?
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é
- 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 Lmjycr2r!
Tester la complexité des mots de passe
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
L'exécution sera comme ceci :
$ john /etc/shadow
Quand john a trouvé un mot de passe, il l'affiche avec le login associée.
| 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. |
Le système de clés de SSH
La théorie de la cryptographie asymétrique
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.
La théorie de la cryptographie symétrique
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 un 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.
L'établissement d'une connexion SSH
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 :
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.
Installation et configuration de SSH
Installation du client et du serveur SSH
| NOTE Debian: | Le client et le serveur SSH sont dans le même package (nommé ssh) dans le cas d'une Debian Ce package est installé dès la première utilisation de dselect. Pour activer le serveur SSH, il faut supprimez le fichier /etc/ssh/sshd_not_to_be_run et lancer SSH :$ rm /etc/ssh/sshd_not_to_be_run $ /etc/init.d/ssh start Starting OpenBSD Secure Shell server: sshd. |
$ /etc/rc.d/init.d/sshd start
Configuration du serveur SSH
Le fichier de configuration du serveur SSH est /etc/ssh/sshd_configA 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. - Protocol 2
Signifie que votre serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Seuls certains vieux clients SSH ne savent faire que du SSH version 1. Si vous voulez que le serveur accepte les deux protocoles, changez la ligne en :
Protocol 2,1 - 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. C'est une sorte de double protection. - X11Forwarding yes
Signifie que vous allez pouvoir travailler en export display par SSH. Ceci est expliqué dans la partie export-display du site.
| $ /etc/init.d/ssh reload Reloading OpenBSD Secure Shell server's configuration. |
Se logguer par SSH
Authentification par mot de passe
C'est la méthode la plus simple. Depuis la machine cliente, tapez :
$ ssh login@nom_DNS_du_serveur_SSH
Ensuite, entrez votre mot de passe... et vous verrez apparaître le prompt, comme si vous vous êtiez loggué en local sur la machine.
Authentification par clé
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.
Générer ses clés
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'autentification. 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.
 | Vous pouvez à tout moment changer la pass phrase qui protège votre clé privée avec la commande ssh-keygen -p. |
Autoriser votre clé publique
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.
Se logguer
La commande est la même que pour une autentification par mot de passe.
Transfert de fichiers par SSH
En console
Le transfert de fichiers par SSH est possible de deux façons :
Utiliser SCP
Pour illustrer la syntaxe, je vais donner quelques exemples :
Utiliser yafc
yafc est un client ftp qui sait transférer des fichiers par SSH ! Pour se connecter par SSH en utilisateur toto sur le serveurordi1.exemple.org :
yafc ssh://toto@ordi1.exemple.org
Ensuite, les commandes sont exactement les mêmes que lors de l'utilisation de yafc comme client FTP !
En graphique
gFTP, peut faire office de client SFTP.
Lançez gFTP avec la commande gftp. Ensuite, allez dans le menu FTP / Options, sélectionnez l'onglet SSH, mettez le paramètreChemin sftp-server SSH2 à /usr/lib/ par exemple et cliquez sur Enregistrez.
Pour vous connecter, entrez le nom DNS du serveur ainsi que le login et le mot de passe, sélectionnez SSH2 à la place de FTP dans la liste déroulante et tapez Entrée.
Figure 44-1. gFTP en SFTP
Se logguer par SSH sans taper de mot de passe
Le principe
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'autentifier.
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é.
La pratique
en console
Dans une console, ouvrez un screen avec ssh-agent en tâche de fond :
$ 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
en mode graphique
Démarrez le serveur graphique avec la commande :
$ ssh-agent startx Puis ouvrez un xterm et tapez : ssh-addL'agent sera alors actif pour toutes les applications que vous utiliserez en mode graphique, et notamment tous les xterm ouverts ou que vous ouvrirez.
avec GDM
Si vous utilisez GDM, l'agent SSH a déjà été lançé par GDM. Vous n'avez donc plus qu'à exécuter ssh-add une fois que vous êtes loggué.
Faire des tunnels SSH
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 :
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).
Ensuite, il suffit de lançer un navigateur Web en lui demandant de se connecter en local sur ce port :
$ w3m http://localhost:2012 Figure 44-2. Exemple de tunnel SSH
Et le bon vieux Telnet... ?
Qu'est-ce que Telnet ?
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ées en clair ! Telnet ne permet pas de faire des transferts de fichiers. Il est donc conseillé de ne pas utiliser Telnet mais uniquement SSH.
Client et Serveur Telnet
Le client Telnet se trouve dans le package telnet. Ce package est installé par défaut.
Le serveur Telnet se trouve dans le package telnetd. Il n'y a aucune configuration à faire.
Pour se connecter à un serveur Telnet, tapez :Le serveur Telnet se trouve dans le package telnetd. Il n'y a aucune configuration à faire.
$ telnet nom_DNS_du_serveur_telnet et ensuite rentrez votre login et votre mot de passe quand il vous le demande.
Mot-clé : configuration de,linux server,server linux,windows home server,windows server,windows server 2003,proxy server,server,server windows,server 2008,web server,ssh from linux to linux,
