SSH en détails, Partie 2
Note de l’éditeur: Dans la première partie de cette série d’articles rentrant dans les profondeurs de SSH avec Mac OS X, François Joseph de Kermadec nous a montré l’intérêt du serveur SSH intégré à Mac OS X. Dans cette deuxième partie, il nous initie à l’utilisation de ces outils.
Pour le paramétrage de notre serveur et de notre client SSH, nous partirons du principe que vous disposez d’un accès physique à chaque machine et qu’elles se trouvent l’une à côté de l’autre, afin de pouvoir taper au clavier sur l’une tout en lisant l’écran de l’autre. Bien qu’il soit possible de suivre les manipulations dans des conditions moins aisées, vous aurez alors besoin d’un bloc-note et d’un stylo pour vous aider. Assurez-vous également que personne ne regarde par dessus votre épaule pendant que vous travaillez sur les ordinateurs. Nous allons, dans les prochains chapitres, manipuler des mots de passe sensibles qui doivent être gardés secret, sous peine de ruiner tous vos efforts de confidentialité et de sécurité.
Dernière chose, avant que nous commencions, nous allons réaliser deux opérations sur la “machine serveur” — en d’autres mots, la machine que vous souhaitez administrer à distance. Même si cela n’a pas de sens pour vous dans l’immédiat, je vous promets que cela en aura dans quelques minutes et je mettrais bien en évidence leur importance lorsque nous en parlerons.
- Ouvrez l’utilitaire “Terminal”, situé dans le dossier “Utilitaires”.
- Saisissez la commande suivante et validez avec la touche Entrée: mkdir ~/.ssh Cela créera un nouveau dossier, invisible nommé “.ssh” dans votre dossier d’accueil.
Un serveur ne dort jamais
Le gros problème lorsque l’on utilise un Mac de bureau comme serveur, c’est que l’on a facilement tendance à oublier que, contrairement aux ordinateurs de bureau qui passent en veille lorsqu’ils ne sont pas utilisés, les serveurs ne doivent jamais s’éteindre. En fait, dans la plupart des cas, un serveur endormi ne peut pas être réveillé à distance et sa connexion est tout simplement morte, sans aucune chance de pouvoir la réactiver.
Bien sûr, Mac OS X offre une superbe option “Réactiver lors d’un accès administrateur via le réseau Ethernet”, disponible dans les préférences Economiseur d’énergie. Cependant, cette option ne fonctionne pas toujours dans les WANs et doit être évitée lorsque la disponibilitée est cruciale.
De ce fait, avant de penser à paramétrer votre serveur, vous devez vous rendre dans le panneau des Préférences Economiseur d’énergie afin de vous assurer des points suivants:
- Il ne dort jamais, pour les raisons vues précédemment.
- Son écran passe en veille rapidement, pour éviter l’impression de l’image dans l’écran (ce qui peut se produire même avec des écrans plats) et pour économiser l’énergie.
- Le disque dur passe en veille, quand cela est possible, afin d’éviter son usure trop prématurée. Bien sûr, cela ne doit pas être activé si votre serveur doit avoir des temps de réponse courts car le disque dur prendra quelques secondes à se réveiller — cela ne s’applique pas vraiment dans notre cas présent, car SSH n’est pas vraiment conçu pour des requêtes temps réel, urgentes.
- Le redémarrage automatique du Mac après une coupure de courant. Cette option redémarrera automatiquement votre Mac après tout arrêt brutal. Afin de profiter pleinement de cette option, vous devez vous assurer que vous avez bien la dernière version d’OpenFirmware disponible pour votre Mac.
- Le bouton d’allumage ne met pas le Mac en veille. Cela garantira tout incident lorsque votre personnel de maintenance ou les utilisateurs nettoient l’ordinateur — en gardant à l’esprit qu’un ordinateur qui contient des données sensibles de quelque nature que ce soit ne doit pas être physiquement accessible mais placé dans un boitier spécifiquement conçu pour.
Vous devriez également investir dans un onduleur pour votre Mac et le modem ou, au moins, une protection contre les surtensions afin d’éviter qu’ils soient endommagés en votre absence. Si vous utilisez un modem téléphonique, utilisez une protection contre les surtensions pour ligne téléphonique, aussi, car les fils téléphoniques conduisent facilement les surtensions directement dans votre carte modem (ou pire, la carte mère) et ont déja détruit plus d’un ordinateur.
Si vous avez besoin de redémarrer votre Mac à distance, c’est une bonne idée d’utiliser le panneau de préférences “Sécurité” et “Comptes” pour désactiver l’ouverture de session automatique. En fait, cela pourrait conduire votre Mac à se connecter à votre compte alors que vous n’êtes pas là simplement parce que vous l’avez redémarré à distance, donnant ainsi accès à vos fichiers à n’importe qui passant devant la machine — magnifique ! Fermer à distance une session graphique implique de tuer des processus ou de bidouiller le fichier de préférences de la fenêtre d’ouverture de session avant de redémarrer. Cela est faisable — Je l’ai fait — mais c’est franchement pas quelque chose que vous voudriez tenter.
Pour conclure, n’oubliez pas d’indiquer par un affichage adéquat ou des consignes à vos utilisateurs de seulement fermer la session et de ne jamais éteindre l’ordinateur ou de le mettre en veille sauf en cas d’urgence. Masquer le bouton “Eteindre” sur la fenêtre d’ouverture de session peut être d’une grande aide également. Les comptes avec un “Finder simplifié” n’ont pas de menu “Eteindre”, rendant la gestion à distance du Mac beaucoup plus facile, tout spécialement si vos utilisateurs sont des débutants qui auraient du mal à se faire à l’idée de ne pas éteindre le Mac.
Avertissements concernant la Sécurité
Malgré le fait que ce que nous allons voir aujourd’hui devrait être suffisant pour la plupart des utilisateurs à domicile ou les petites entreprises, les utilisateurs qui doivent manier des données sensibles peuvent avoir recours aux conseils de professionnels ou suivre des formations complémentaires. Si vous avez un administrateur réseau, parlez avec lui de SSH et de votre souhait de l’utiliser. Certaines restrictions ou règles peuvent s’appliquer à votre réseau.
SSH est un protocole puissant, complexe et fascinant. Nous allons voir ensemble comment l’utiliser dans votre travail au quotidien et le rendre plus sûr qu’il ne l’est dans sa configuration par défaut. Vous pouvez également vous reporter à des documents plus détaillés pour découvrir tout ce que SSH peut faire pour vous. Je vous recommande fortement SSH, le shell sécurisé - La référence par Daniel J. Barrett et Richard Silvermann.
Nous avons déja vu qu’aussi sûr que SSH puisse l’être, il ne vous protège pas contre les machines compromises. De ce fait, vous devez prêter attention à la sécurité des deux ordinateurs, le serveur (la machine que vous administrez à distance) et le client (votre machine d’administration).
Cela est spécialement important pour deux raisons. Du fait que vous allez créer une liaison entre deux ordinateurs, un attaquant expérimenté pourrait profiter de cela pour compromettre les deux ordinateurs aisément, s’il en a déja compromis un. En plus, comme vous serez loin de l’ordinateur distant, prévenir et détecter les problèmes de sécurité sera beaucoup plus difficile que si vous étiez sur place. Assurez-vous de suivre au moins les conseils décrits dans l’article Security Primer for Mac OS X — les deux machines ainsi que tous les utilisateurs qui utilisent ou surveillent le serveur doivent avoir un moyen de vous contacter facilement en cas de problèmes.
Première rencontre avec SSH
Maintenant que nous avons parlé de théorie, il est temps de remonter les manches et de rencontrer SSH en l’activant sur le serveur. Pour cela, il faut suivre les étapes suivantes.
- Ouvrir le programme des “Préférences Système”.
- Cliquez sur “Partage” pour ouvrir les préférences de Partage.
- Dans l’onglet des Services, mettre la coche en face de “Session à distance” et attendre quelques secondes la confirmation du démarrage effectif du service.
- Lisez la ligne d’aide qui apparait au bas de la fenêtre et assurez-vous de noter la commande SSH magique qui apparait sous la forme “ssh nomdutilisateur@adresseip”.
Si vous utilisez un pare-feu externe, assurez-vous qu’il autorise les connexions sur le port 22, le port par défaut pour le SSH. Si vous utilisez le pare-feu intégré de Panther, aucune inquiétude à avoir. Mac OS X est suffisamment intelligent pour arrêter le bloquage de ce port dès que vous activez l’option de Session à distance.
Gardez bien à l’esprit que, malgré le fait que SSH soit un protocole sécurisé et que le serveur SSH supporte des méthodes d’encryptage fortes, faire tourner un serveur (quel qu’il soit) sur un ordinateur (quel que soit la plateforme) réduit sa capacité à résister aux attaques. Vous devez vous assurer que votre réseau est totalement protégé par votre pare-feu, et que vous appliquez bien au fur et à mesure toutes les mises à jour de sécurité publiées par Apple. En fait, si une sérieuse faille de sécurité est découverte dans le serveur OpenSSH, seul la mise à jour adéquate peut vous protéger des attaques.
Si vous n’avez pas de pare-feu, et que votre Mac est directement connecté à Internet, je vous conseille fortement d’acheter un pare-feu matériel. Celui-ci vous apportera une sécurité inestimable et protègera votre ordinateur de nombreuses tentatives d’attaques.
Si vous avez déja un pare-feu, il est temps de vérifier qu’il est bien paramétré et que son firmware est bien à jour. En fait, les mini systèmes d’exploitation contenus dans les pare-feu doivent être mis à jour de temps en temps; le manquement à cette rêgle peut permettre à un attaquant de l’extérieur d’exploiter une faille connue dans le logiciel et de prendre le contrôle de votre routeur — une pensée gênante.
Pour plus de sécurité encore, vous pouvez utiliser les différents outils disponibles sur Internet mis à disposition par des sociétés de sécurité pour éprouver votre pare-feu. Vous pouvez utiliser les tests de Symantec et Sygate qui sont complémentaires et pratiques. Bien sûr, ces tests ne remplacent pas un vrai audit de sécurité.
Test du Serveur et Premiers Réglages du Client
Vous avez maintenant un serveur SSH pleinement opérationnel sur ce Mac. Pour le tester, connectez votre machine d’administration dans le même réseau et ouvrez une fenêtre de Terminal. Puis, saisissez la commande magique “ssh nomdutilisateur@adresseip” que vous avez précédemment notée. Cette commande démarre simplement le client SSH intégré à Mac OS X et lui demande de se connecter au serveur SSH que vous avez démarré, en demandant à être connecté avec le nom d’utilisateur indiqué.
J’aurais aimé que vous puissiez vous connecter directement mais, malheureusement, ce n’est pas ce qu’il se passe. Comme vous pouvez le voir, afin de rendre les connexions SSH sécurisées, le client et le serveur tente de prouver leurs identités respectives l’un à l’autre avant de commencer à dialoguer. Pour faire cela, ils commencent une discussion cryptée basée sur des clés qui sont préinstallées sur chaque machine.
Il s’agit d’un moyen pour empêcher quelqu’un se de faire passer pour votre serveur et de capturer vos données sensibles — un procédé connu comme l’attaque de “l’homme au milieu” qui implique de faire transiter les données entre un client n’ayant pas découvert la supercherie et le serveur qui pensent chacun qu’ils se parlent directement. Du fait que c’est la première fois que le client et le serveur se rencontrent, ils n’ont aucun moyen d’être sûr qu’ils sont qui ils prétendent être. Pour cette raison, SSH va vous demander de l’aide en affichant l’empreinte de la clé cryptographique utilisée par l’ordinateur qui prétend être votre serveur — appelée aussi “clé machine”.
Allez sur votre serveur et saisissez la commande suivante et validez avec la touche Entrée:
ssh-keygen -l -f /private/etc/ssh_host_rsa_key.pub
Cette commande obtient la clé RSA du serveur, qui est utilisée comme identifiant unique par SSH.
Comparez simplement les deux chaines de caractères. Si elles correspondent, vous êtes sûr que votre ordinateur est bien réellement en connexion avec votre serveur et pas un trouble-fête quelconque. Tapez “yes” pour confirmer la connexion et rassurer SSH. SSH poursuivra alors la procédure de connexion normale.
Vous ne devriez pas normalement revoir ce message car SSH conserve les clés qu’il vous a demandé d’approuver comme clé “sûre” pour les connexions futures. Si ce message réapparait, cela peut vouloir dire que quelqu’un se fait passer pour votre serveur. Vous devriez alors immédiatement déconnecter votre ordinateur, décrocher votre téléphone et appeler l’administrateur réseau.
SHH vous demandera alors le mot de passe du compte avec lequel vous essayez de vous connecter. Saisissez-le, validez par la touche Entrée, et vous serez alors connecté sous le nom d’utilisateur que vous avez indiqué (l’utilisateur “username” dans notre exemple). Toute action que vous réaliserez dans ce Terminal s’exécutera sur l’autre ordinateur. Par exemple, saisir une commande qui ouvre le tiroir du lecteur de CD se réalisera sur l’autre machine, pas sur la vôtre. Faites attention avec ce genre de commandes car il est facile de faire des erreurs et d’effrayer des utilisateurs à des centaines de kilomètres de là qui verront leur lecteur de CD se mettre en activité sans raison apparente.
Pour vous donner une indication sonore de ce que vous faites, essayez la commande suivante:
say J'adore être dans ce sympathique ordinateur
Cela vous permettra d’entendre la douce voix de Victoria via les haut-parleurs de l’ordinateur distant.
Pour finir, afin de terminer la session SSH et revenir sur l’interface en ligne de commande locale, tapez exit et validez par la touche Entrée.
Configuration non sécurisée
Nous disposons maintenant d’un Mac à l’écoute sur le réseau des requêtes SSH, prêt à donner des droits à toute personne devinant le mot d’un passe d’un compte qu’il contient. Il s’agit du comportement par défaut de la plupart des serveurs SSH et, si vous avez choisi de bons mots de passe, il y a peu de risques que quelqu’un les découvre. Cependant, ils existent et ne doivent pas être négligés.
Afin de corriger cette faiblesse, nous allons désactiver l’identification par mot de passe, et autoriser uniquement l’identification par clé publique, ce qui veut dire que le serveur SSH du Mac donnera l’accès uniquement à quelqu’un possédant une clé privée spécifique, même si la personne trouve le mot de passe d’un compte. Du fait que les clés privées ne quittent jamais votre ordinateur, les voler implique une intrusion dans la machine.
De plus, du fait que les clés privées stoquées sur votre Mac peuvent être cryptées en utilisant un mot de passe, deux points sont désormais indispensables pour pouvoir se connecter à votre serveur: quelque chose que vous avez (la clé) et quelque chose que vous connaissez (le mot de passe de la clé), rendant ce système d’identification particulièrement efficace.
Ne pas oublier cependant que cela est théorique. Si une faille est découverte dans le serveur OpenSSH, un attaquant à distance peut essayer de l’exploiter pour obtenir l’accès à votre ordinateur sans posséder la clé ou sans connaitre le mot de passe du compte. C’est pour cela qu’il est crucial de rester en permanence informé des annonces de sécurié lorsque l’on fait tourner des serveurs sur un ordinateur.
Bien sûr, il existe des fonctions intégrées à OpenSSH qui réduisent les risques d’exploitation d’une vulnérabilité — l’une d’entre elles est nommée “séparation des droits”. Vous ne devriez pas cependant compter là-dessus pour vous protéger de tout risque qui pourrait se présenter.
Génération des clés
Bien évidemment, avant de pouvoir penser utiliser des clés, nous devons en avoir. La bonne nouvelle est que — contrairement à des certificats pour courrier électronique — vous n’avez pas besoin de les demander à une authorité de certification. En fait, nous n’avons pas besoin de prouver notre identité au reste du monde et de ce fait nous pouvons tranquillement créer nos clés depuis notre Terminal.
Afin de générer les clés, nous allons utiliser un outil en ligne de commande nommé ssh-keygen sur l’ordinateur client — dans notre cas, l’ordinateur d’administration.
Comme d’habitude, ouvrez une fenêtre du Terminal et tapez la commande suivante, suivie de la touche Entrée:
ssh-keygen -b 1024 -t dsa
Cela va créer une clé DSA (DSA étant un des deux algorythmes utilisés par SSH2, l’autre étant RSA) d’une longueur de 1024. Si vous décidez que vous avez besoin d’utiliser le protocole SSH1, ne réutilisez pas votre clé RSA SSH2. Elles sont utilisées différemment, et cela aurait pour conséquence de divulguer des informations qui pourraient être utilisées pour compromettre votre clé privée. De ce fait, il est toujours préférable de générer une clé RSA SSH1 séparée (ssh-keygen -b 1024 -t rsa1).
Ssh-keygen vous demandera où stocker les clés générées. Validez simplement par Entrée pour les installer à l’endroit par défaut, où les différents éléments SSH s’attendent à les trouver.
Lorsque l’on vous demande la passphrase, saisissez un “bon mot de passe” — tel que défini dans notre précédent article sur la sécurité de Mac OS X — qui doit être d’une quinzaine de caractères. Rappelez-vous que ce mot de passe empêche un programme malveillant sur votre Mac ou un attaquant de voler la clé. Il est de ce fait extrêmement important et sensible. Bien sûr, assurez-vous de ne pas l’oublier.
Ssh-keygen vous rendra ensuite la main, en affichant à l’écran l’empreinte de la clé.
Copie de la clé publique sur le serveur SSH
Ssh-keygen a enregistré les deux clés qu’il a généré sur votre ordinateur. Cependant, pour que le serveur puisse les utiliser, vous devez y transférer la clé publique, dans un endroit où il sera capable de la trouver automatiquement et de l’utiliser.
Pour faire cela, nous allons utiliser scp, une commande qui utilise SSH. Malgré une syntaxe simple, cette commande est capable de faire des transferts de fichiers de façon sécurisée aisément. En fait, en utilisant juste la commande scp, vous ouvrirez une connexion sécurisée, ferez le transfert de fichiers par ce biais, et la fermerez, le tout en une seule fois.
Pour copier les fichiers, utilisez la commande suivante dans une fenêtre du Terminal:
scp ~/.ssh/id_dsa.pub nomdutilisateur@ipserveur:~/.ssh/authorized_keys
Comme vous pouvez le voir, cela copie (scp) la clé publique dsa que nous venons juste de créer (~/.ssh/id_dsa.pub) dans le dossier .ssh du dossier d’accueil de l’utilisateur distant et le renomme en authorized_keys.
A titre d’information, vous verrez peut-être parfois une référence à un fichier nommé authorized_keys2 — qui fonctionne avec la version actuelle d’OpenSSH, mais le nom générique doit lui être préféré. Ce fichier peut être utilisé à la fois par SSH1 et SSH2.
Au cas où vous vous demanderiez pourquoi je vous ai conseillé de créer manuellement le dossier .ssh sur votre serveur précédemment, c’est tout simplement parce que la commande scp en a besoin !
L’identification se fait de la même façon que précédemment lors de votre essai de connexion en SSH. Cependant, scp quitte par lui-même et vous n’avez pas besoin de taper une commande spéciale comme “exit”.
Ce n’est qu’une première étape
Maintenant que vous avez transféré votre clé publique sur le serveur, il est temps de tester si SSH la voit bien. Pour cela, connectez-vous depuis votre ordinateur d’administration. Au lieu du mot de passe du compte distant, le système devrait vous demander le mot de passe utilisé pour crypter la clé.
Cependant, vous remarquerez rapidement que le fait de fournir un mot de passe erroné à SSH ne coupe pas la connexion, comme cela devrait le faire. Au lieu de cela, il demandera le mot de passe du compte, qui est beaucoup moins sécurisé.
Voici une astuce de dépannage. Si le serveur SSH ne vous demande pas comme prévu le mot de passe, cela peut-être parce que votre dossier d’accueil, le dossier .ssh, et le fichier authorized_keys ont les droits d’écriture au groupe voire à tout le monde. Il s’agit d’une mesure de sécurité qui empêche le serveur de se fier à des clés faciles à compromettre. Si vous rencontrez encore des problèmes, assurez-vous que votre client (le Mac que vous utilisez pour les taches d’administration) est correctement paramétré, également, et que ses droits sont correctement réglés.
Pour cela, la prochaine étape va être d’éditer les fichiers de configuration du serveur SSH afin de désactiver toutes ces options d’identifications non sécurisées que nous ne voulons pas.
Dans ce prochain épisode, nous rentrerons dans l’édition des fichiers de configuration et je vous montrerais de bonnes astuces pour maintenir un bon niveau de sécurité pour vos communications SSH
Textes originaux en anglais sur O’Reilly : Inside SSH, Part 2 par François Joseph de Kermarec
Chargement
Commentaires récents