HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > Revisite de la configuration du client OpenSSH
Accéder au : Site HSC des formations
Télécharger le catalogue des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|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





Dernière modification le 27 septembre 2007 à 16:12:29 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants