---[ Revisite de la configuration du client OpenSSH ]------------------------- This article is available in english at ssh_config.html.en . --[ 1. Introduction ]--------------------------------------------------------- Cet article traite de l'utilisation du fichier de configuration de ssh (~/.ssh/config et au niveau système /etc/ssh/ssh_config) et de comment il est possible de se simplifier la vie grâce à ce simple fichier et quelques astuces. Le fichier .ssh/config présent dans le répertoire de chaque utilisateur peut permettre de simplifier l'utilisation de ssh et de rendre certaines actions automatiques. --[ 2. Le fichier de configuration ]------------------------------------------ Dans le fichier de configuration, il est possible de choisir des options soit au niveau global, soit par machine. Par exemple, il est possible d'utiliser l'option Compression pour toutes les machines : Compression=yes ou de hasher les noms de machines avant leur stockage (dans le fichier know_hosts) : HashKnownHosts yes Il est d'ailleurs inutile d'activer cette option de façon non globale car le nom d'hôte apparaîtra dans le fichier configuration. La configuration par machine est réalisée en déclarant un Host suivi de toutes les options de configuration. Par exemple, il est possible de configurer les informations pour l'hôte www.hsc.fr : Host www.hsc.fr User user Selon la configuration DNS, il est intéressant de mettre sur la même ligne tous les noms correspondant à la même machine : Host www www.hsc.fr On voit ici une option très pratique permettant de spécifier le nom de l'utilisateur sur la machine distante, ainsi il ne sera plus nécessaire d'utiliser "ssh user@www.hsc.fr" ou "ssh www.hsc.fr -l user" mais uniquement "ssh www.hsc.fr" même si le nom d'utilisateur local diffère du nom d'utilisateur distant. D'autres options peuvent s'avérer pratiques, telles que : - BatchMode (défaut no) qui va obliger ssh à ne pas demander de mot de passe (si mis à yes), ce qui peut s'avérer très utile pour les scripts/batchs. - IdentityFile pour spécifier le fichier de stockage de l'identité pour cette machine (clé privée). - LocalCommand (uniquement si PermitLocalCommand a la valeur yes, la valeur par défaut est no) permet d'exécuter une commande sur la machine locale dés que l'on est connectée à la machine distante. - ProxyCommand pour spécifier la commande à éxecuter pour se connecter au serveur, par exemple nc, les wildcard %h et %p respectivement pour la machine et le port distant sont disponibles. --[ 3. Multiplexage du canal de communication ]------------------------------- Il arrive souvent d'être connecté plusieurs fois sur la même machine, l'utilisation de la fonction ControlMaster permet d'avoir un seul canal de communication et de ne pas avoir à se réauthentifier (mot de passe ou clé privée) à chaque nouvelle connexion, c'est une alternative intéressante à l'utilisation de ssh-agent. Pour cela, il suffit d'utiliser l'option ControlMaster : Host www.hsc.fr User user ControlMaster auto ControlPath ~/.ssh/ssh-%r@%h:%p Utiliser la valeur "auto" pour le paramètre "ControlMaster" indique à SSH qu'il doit crée un multiplexeur localement si aucun n'a été associé au triplet login/host/port. Si un multiplexeur est déjà créé, la connexion est effectuée vers le socket local. Comme nous pouvons le voir, il est possible d'utiliser des wildcards pour la gestion du nom du socket : - %h désigne la machine distante ; - %p le port distant ; - %r le nom d'utilisateur. Il est important de spécifier le %r dans la variable ControlPath si on se connecte avec plusieurs noms d'utilisateurs sur la même machine distante. L'utilisation de %h peut poser des "problèmes" dans le cas d'une machine ayant plusieurs noms DNS, en effet, si l'on se connecte à machine1 et à machine2 mais qu'il s'agit de la même machine, le socket aura un nom diffèrent à chaque fois. Ainsi chaque nouvelle connexion au serveur se fera automatiquement et dans le même canal de communication tant que la première connexion (connexion maître) reste active. Ce qui signifie une seule connexion TCP pour plusieurs utilisations du support SSH : shell, sftp, port forwarding ... Le socket utilisé par le client SSH pour multiplexer les connexions peut être stocké dans un répertoire privé (dans le répertoire utilisateur) ou dans un répertoire publique (ex: /tmp). OpenSSH prend soin d'affecter des permissions sécurisées au socket. --[ 4. "ControlMaster auto" vs. ssh-agent ]----------------------------------- D'un point de vue purement fonctionnel : - ControlMaster fournit une fonctionnalité de multiplexing de canaux que ssh-agent ne propose pas (et c'est normal). - ControlMaster permet l'authentification avec mot de passe ou avec des clés alors que ssh-agent ne propose qu'une authentification par clés. - Les connexions effectuées avec le multiplexeur sont plus rapides que les connexions impliquant ssh-agent pour la simple et bonne raison que l'authentification a déjà été effectuée dans le premier cas. - L'utilisation de ControlMaster n'implique pas d'avoir un processus permanent même si aucune connexion SSH n'est en cours. - ssh-agent permet de se connecter sur plusieurs hôtes avec la même clé sans avoir à se réauthentifier (si la clé est commune). L'utilisation de ControlMaster implique une authentification pour chaque connexion vers un nouveau triplet user/host/port. - Avec ControlMaster, si l'ordinateur est éteint brusquement, les clients SSH agissant comme multiplexeurs n'ont pas le temps de supprimer les sockets créées. Donc au prochain redémarrage, les tentatives de connexions SSH échoueront car le client essayera de se connecter à un socket mort. D'où l'intérêt de placer les sockets dans /tmp si les scripts de démarrage vident ce répertoire. ssh-agent ne présente pas ce problème car le nom du socket est dépendant du PID du processus et change donc à chaque redémarrage. Du point de vue sécurité du poste client (le client SSH), les deux méthodes ont leurs défauts. Dans tous les cas, ControlMaster ou ssh-agent, il est possible pour un pirate doté du même UID que la victime d'ouvrir des connexions à certains hôtes sans authentification : - Avec ControlMaster, le pirate pourra se connecter sans authentification à tous les hôtes pour lesquels il existe déjà un multiplexeur local. - Avec ssh-agent, le pirate pourra se connecter sans authentification à tous les hôtes associés aux clés privées enregistrées auprès de l'agent. Cependant l'utilisation de ssh-agent présente un risque supplémentaire. Les clés privées utilisées pour l'authentification sont déchiffrées et présentes en mémoire. Concrètement, un pirate profitera plus d'une configuration avec ssh-agent, que d'une configuration "ControlMaster auto". Non seulement il pourra se connecter sans authentification, mais il pourra également récupérer les clés privées utilisées, sans avoir besoin de connaître les mots de passe associés, si il obtient les droits root. De plus, avec ControlMaster, le multiplexeur est arrêté quand le dernier client se déconnecte, la fenêtre (temporelle) d'attaque est donc plus courte. Se connecter sans authentification avec ssh-agent est possible pendant toute la vie du processus, générallement valide du début à la fin d'une session utilisateur (ex: X11). Pour récupérer les clés privées stockées dans la mémoire d'un ssh-agent, il faut soit pouvoir lire /proc/pid/mem, soit avoir le droit d'utiliser ptrace(2) sur le processus. Normallement seul l'utilisateur root possède ce privilège. De toute manière, à partir du moment où le pirate est root, les carottes sont cuites !! --[ 5. Accélérer (un peu) l'authentification ]-------------------------------- Ou comment stopper le réchauffement de la planète et sauver quelques octets de trafic réseau :) Cette petite accélération peut être obtenue en spécifiant au client OpenSSH quelle méthode d'authentification doit être utilisée prioritairement. Le paramètre de configuration est "PreferredAuthentications". Pour la version 2 du protocole SSH, le choix comporte généralement : - publickey - keyboard-interactive - hostbased Le cas typique est la connexion à un serveur SSH où le client OpenSSH essaye de s'authentifier avec les clés RSA et DSA de l'utilisateur alors que celui-ci s'authentifie par mot de passe. On peut tracer le dialogue entre le client et le serveur en lançant ssh en mode debug (-vv) debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /home/admin/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering public key: /home/admin/.ssh/id_dsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: keyboard-interactive Pour se connecter plus rapidement avec un mot de passe : Host machine1 PreferredAuthentications keyboard-interactive Dans ce cas, le client n'essaye plus de s'authentifier avec les clés RSA et DSA valides mais non enregistrées côté serveur. debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: keyboard-interactive 2 requêtes SSH donc 4 messages TCP donc quelques octets et millisecondes viennent d'être sauvés. --[ 6. Redirection de ports ]------------------------------------------------- La redirection de ports est très souvent utile et utilisée, cependant, son utilisation reste assez laborieuse quand une machine distante sert de rebond vers plusieurs machines. Il est aussi possible d'automatiser cela et d'utiliser simplement la redirection. Par exemple, si l'on a 2 machines et qu'il faut se connecter à machine1 pour accéder à machine2 depuis le poste admin. ----- ----- ----- | | | | | | | | | | 22 | | | |=======| |-------| | | | | | | | |_____| |_____| |_____| admin machine1 machine2 Le fichier de configuration suivant permet d'automatiser cette tâche : Host machine1 User admin ControlMaster auto ControlPath ~/.ssh/socket1-%r@%h:%p LocalForward=2022 machine2:22 Host machine2 User admin Hostname=localhost Port=2022 ControlMaster auto ControlPath ~/.ssh/socket2-%r@%h:%p HostKeyAlias machine2 Ainsi lors de l'établissement de la connexion à machine1 la redirection de port vers machine2 sera automatiquement réalisée. L'option HostKeyAlias est très importante car elle permet de ne pas avoir plusieurs machines avec le même nom (localhost) dans le fichier ~/.ssh/know_hosts. Il est aussi possible de rediriger des ports distants à l'aide de option RemoteForward. --[ 7. Conclusion ]----------------------------------------------------------- Cette brève vous a présenté le fonctionnement du fichier de configuration d'openSSH et comment une simple configuration peut faire gagner un peu de temps. -- Nicolas Collignon -- -- Louis Nyffenegger -- --[ 8. Références ]----------------------------------------------------------- - Le site du projet OpenSSH : http://www.openssh.org - Brève de Franck Davy sur SSH et la redirection X11 : http://www.hsc.fr/ressources/breves/ssh-x11.html - Brève de Jean-Baptiste Marchand sur l'administration de Windows avec SSH : http://www.hsc.fr/ressources/breves/remote_windows_ssh.html - Brève de Thomas Seyrat sur l'installation d'OpenSSH sous Solaris : http://www.hsc.fr/ressources/breves/ssh-solaris.html - Brève de Denis Ducamp sur comment chrooter un compte avec OpenSSH : http://www.hsc.fr/ressources/breves/chroot-openssh.html