|
|
 | | |  | Revisite de la configuration du client OpenSSH |  |
par Nicolas Collignon et Louis Nyffenegger (21/08/07)
---[ 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 <Nicolas.Collignon@hsc.fr> --
-- Louis Nyffenegger <Louis.Nyffenegger@hsc.fr> --
--[ 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
|
