12.07.2007 version 1.5
OPEN-SSH
1.PRESENTATION
2.HISTORIQUE
3.GUI
4.PORTABILITE
5.SECURITE
6.VPN
7.PARTAGE DE FICHIERS
8.TIPS & TRICKS
9.OPTIONS DE CONFIGURATION
10.SEQUENCE D’EVENEMENTS D’UNE CONNEXION SSH
11.COUCHE TRANSPORT DE SSH
12.AUTHENTIFICATION
13.CANAUX
14.OPEN SSH SANS MOT DE PASSE
15.RSYNC
16.RECOMMANDATIONS
17.REMERCIEMENTS
Synthèse réalisée par
Gilles QUENOT
Administrateur système et réseau.
1 Présentation:
Je vais vous présenter OpenSSH. C’est un outil de référence incontournable mondial pour les administrateurs système ou réseau, les utilisateurs avertis, ainsi que les intrus mal intentionnés (black hat et la technique du man in the middle) puisqu’il permet sous unix-likes d’avoir un accès shell (CLI Command Line Interface) distant sur serveur hôte à travers des types de réseaux hétérogènes en WAN comme en LAN.
OpenSSH est une implémentation libre de SSH, sous licence BSD.
La licence BSD est l’une des moins restrictives dans le monde informatique et s’approche de la notion de »domaine public »
http://fr.wikipedia.org/wiki/Licence_BSD
OpenSSH est développé par le projet OpenBSD. C’est à la fois une application informatique et un protocole de communication sécurisé avec une architecture client/serveur.
Le protocole SSH a été conçu avec l’objectif de remplacer les différents programmes rlogin, telnet et rsh.
Les principales fonctionnalités d’OpenSSH sont les suivantes :
Projet Open Source
Licence Libre
chiffrement Fort à l’aide des algorithmes 3DES, Blowfish, AES, Arcfour
chiffrement du trafic X Window (X11 Forwarding)
Création de canaux chiffrés pour les protocoles courants (Port Forwarding)
Authentification forte à l’aide de clef publique, de mot de passe à usage unique et de Kerberos
Agent Forwarding (Single-Sign-On)
Interopérabilité grâce à la conformité aux standards des protocoles SSH 1.3, 1.5, et 2.0
Support client et serveur SFTP pour les protocoles SSH1 et SSH2
Transmission des Tickets Kerberos et AFS
Compression des Données
La structure générale de SSH2 est composé de trois couches :
La couche transport fournit la négotiation d’algorithmes et l’échange de clés. L’échange de clés inclut l’authentification du serveur et aboutit à une connexion sécurisée cryptographiquement : elle fournit l’intégrité, la confidentialité, et la compression optionnelle.
La couche d’authentification utilisateur utilise la connexion établie et se repose sur les services fournis par la couche transport. Elle fournit plusieurs mécanismes pour l’authentification utilisateur. Cela inclut la traditionnelle authentification par mot de passe ainsi que des mécanismes d’authentification à clé publique ou basée sur l’hôte.
La couche de connexion multiplexe différents canaux simultanés à travers la connexion d’authentification et permet de tunneliser les sessions de login et de faire suivre les connexions TCP. Elle fournit aussi un service de vérification de flux pour ces canaux. Additionnellement, plusieurs options spécifiques à chaque canal peuvent être négociées.
2 Historique:
Il existe deux versions incompatibles majeures, SSH1 et SSH2. La première étant obsolète à cause de ses failles de sécurité bien connues qui permettent à un agresseur d’insérer des données dans le flux de communication.
La version 2 qui était à l’état d’ébauche jusqu’en janvier 2006 est aujourd’hui largement utilisée à travers le monde. Cette version est beaucoup plus sûre cryptographiquement, et possède en plus un protocole de transfert de fichiers complet : SCP.
OpenSSH2 a été inventé de façon à éviter les problèmes de brevet avec RSA (problèmes qui ne sont plus d’actualité depuis que le brevet a expiré). Il corrige également le problème de contrôle d’intégrité CRC du protocole 1 en utilisant les algorithmes asymétriques DSA et DH, le protocole SSH 2 ne repose sur aucun brevet. Le problème du CRC est résolu en utilisant un véritable algorithme HMAC. Le protocole SSH 2 supporte aussi un grand nombre d’algorithmes symétriques et de nouvelles fonctionnalités. La version d’OpenSSH supportant les protocoles SSH 1.3 et 1.5 a été mise à disposition le 1er décembre 1999. La première version de SSH (SSH-1) a été conçue par Tatu Ylönen, à Espoo, en Finlande en 1995. Il a créé la première application utilisant ce protocole et a ensuite ouvert une société, SSH Communications Security pour exploiter cette innovation. Cette première version utilisait certains logiciels libres comme la bibliothèque Gnu libgmp, mais au fil du temps ces logiciels ont été remplacés par des logiciels propriétaires. SSH Communications Security a vendu sa licence SSH à F-Secure (anciennement connue sous le nom de Data Fellows). La version suivante a été nommée SSH-2. le groupe de recherche de l’IETF a finalisé le standard SSH-2, que l’on retrouve actuellement dans la plupart des implémentations. Pour la plupart de ses fonctionnalités cryptographiques, OpenSSH s’appuie sur la bibliothèque non GPL OpenSSL.
3 GUI (Graphic User Interface):
Il est possible via OpenSSH de faire du X-forwarding (ouvrir des applications graphiques transitant via ssh) il suffit alors de l’activer dans /etc/ssh/sshd_conf et d’avoir un serveur X installé en local.
Pour ce faire,
ssh -X user@hote
il suffit une fois loggé, d’invoquer le nom de l’application graphique pour la voir s’afficher localement sur son serveur X comme si vous étiez devant la machine distante, à la manière des applications VNC (sauf que là on n’ouvre QUE ce que ce dont on a besoin). SSH s’occupe alors de synchroniser l’entrée et la sortie standard (stdin, stdout) du client et du serveur de façon transparente pour l’utilisateur final. Cela peut être utile par exemple pour un navigateur, un MUA (mail user agent) comme thunderbird, kmail, sylpheed ou pour voir des pdf, des photos…
Ceci est quand même assez lent même avec une bonne connexion.
(VNC est lent lui aussi…)
4 Portabilité:
Il n’est pas nécessaire d’avoir le même système d’exploitation sur le client et le serveur. Il suffit que le démon sshd soit installé et configuré sur le serveur et que ssh le soit sur le client.
Sous Windows, OpenSSH est assez peu utilisé nativement mais on peut néanmoins s’en servir via
PuTTY qui est aussi un très bon client libre et facile d’utilisation. Il consiste en un unique exécutable il n’y a donc pas besoin de l’installer. Sous Mac OS X il est possible d’utiliser openSSH via la console de type Unix (noyau darwin proche de freeBSD). Bien sur, pour tous types d’unix-likes, OpenSSH est LE choix qui s’impose naturellement pour les connexions à distance.
5 Sécurité:
Comme toutes les trames sont chiffrées, il devient donc impossible d’utiliser un sniffer comme ethereal, wireshark ou snort pour voir ce que fait l’utilisateur.
Par défaut, le protocole OpenSSH utilise le port 22.
On peut garder ce port et déployer l’application fail2ban pour éviter les attaques par brute-force.
Il travaille avec le filtreur de paquets du noyau Linux : Netfilter/iptables sous Linux.
Il s’occupe de black-lister les IP d’assaillant(s) au bout d’un nombre défini de tentatives infructueuses.
Une autre méthode (l’une n’empêche pas l’autre), c’est de changer le port par défaut, pour mettre un port au delà de 1023.
Dans la pratique, en laissant le port par défaut, il est fréquent de constater des attaques par brute force dans ses logs, technique visant à essayer de casser le mot de passe en essayant toutes les combinaisons possibles en se basant dans un premier temps sur la comparaison avec les dictionnaires, via des outils software dédiés. Ce genre d’attaque est souvent lancée par des scripts-kiddies. Ceci est fréquemment testé sur le compte root, puisque ce compte est par tradition celui qui aura la plus forte probabilité d’exister sur un système de type Unix-Linux que l’on ne connais pas encore.
6 VPN:
SSH peut également être utilisé pour recopier des ports TCP d’une machine UNIX vers une autre,
créant ainsi un tunnel. C’est donc une solution viable pour faire du VPN. Cette méthode est couramment utilisée afin de sécuriser une connexion qui ne l’est pas (par exemple le protocole email POP3 ou le FTP) en la faisant transférer par le biais du tunnel crypté SSH.
Note : rien n’empêche de faire plusieurs sauts entre consoles OpenSSH, c’est-à-dire ouvrir une console sur un serveur, puis, de là, en ouvrir une autre sur un autre serveur.
7 Partage de fichiers:
OpenSSH est une alternative sécurisée à NFS pour le partage de fichier. Le projet FUSE+SSHFS va en ce sens. Sinon pour un partage temporaire voir prochain paragraphe.
8 Tips & tricks:
il est très facile d’utiliser un navigateur comme konqueror (KDE), où il suffit de taper fish://user@serveur/chemin dans la barre d’adresse pour avoir un accès aux fichiers partagés. Pour les adeptes de gnome, on tape ssh://user@serveur/chemin/ dans la barre d’adresse de nautilus.
Par commodité, il est possible de créer des alias dans son répertoire home/.ssh simplifiant grandement la saisie pour une utilisation fréquente et avancée.
ex: ssh A
Où A est en fait un alias d’un login@ip (donc beaucoup plus court)
Il est également possible de faire de la complétion en configurant le fichier de configuration du client et mettre cette valeur :
HashKnownHosts no
pour que les interpréteurs de commandes comme bash complètent automatiquement le nom du serveur en appuyant sur la touche tabulation.
De plus, si l’authentification pas clef sans mot de passe est activée, on peux compléter les chemins distants sur l’hôte cible à distance tab.
9 Options de configuration:
Il existe beaucoup d’options à ssh dans /etc/ssh/sshd_config notamment :
désactivation du login sur root
authentification ou non par passphrasse
authentification ou non par mot de passe
authentification ou non par clef de chiffrement
nombre d’authentifications maximum en cas d’erreur
10 Séquence d’évènements d’une connexion SSH:
Pour aider à protéger l’intégrité d’une communication SSH entre deux ordinateurs hôtes, la série suivante d’évènements doit être utilisée.
Une liaison cryptographique est établie afin de permettre au client de vérifier qu’il est bien en communication avec le serveur souhaité.
La couche de transport de la connexion entre le client et tout hôte distant est cryptée au moyen d’un chiffrement symétrique.
Le client s’authentifie auprès du serveur.
Le client distant peut interagir avec l’hôte distant au moyen d’une connexion cryptée.
11 Couche transport de SSH:
Le rôle principal de la couche de transport est de faciliter une communication sécurisée entre deux hôtes non seulement au moment de l’authentification, mais également lors de la communication ayant lieu. Pour ce faire, la couche de transport traite le cryptage et décryptage de données et offre une certaine protection quant à l’intégrité des paquets de données lors de leur envoi et de leur réception. De plus, la couche de transport effectue la compression des données permettant d’accélérer la vitesse de transfert des informations.
Lorsqu’un client communique avec un serveur au moyen d’un protocole SSH, de nombreux éléments importants sont échangés afin que les deux systèmes puissent créer correctement la couche de transport. Lors de cet échange, les opérations suivantes ont lieu :
Des clés sont échangées.
L’algorithme de cryptage de clés publiques est déterminé.
L’algorithme de cryptage symétrique est déterminé.
L’algorithme d’authentification de message est déterminé.
L’algorithme de hachage est déterminé.
Lors de l’échange des clés, le serveur s’identifie au client au moyen d’une clé d’hôte unique. Si le client communique pour la première fois avec ce serveur, la clé du serveur n’est pas connue du client et la connexion ne peut pas être établie. OpenSSH contourne ce problème en acceptant la clé d’hôte du serveur après notification de l’utilisateur et vérifie l’acceptation de la nouvelle clé d’hôte. Lors des connexions suivantes, la clé d’hôte du serveur est vérifiée en la comparant avec une version enregistrée sur le client, permettant ainsi au client de s’assurer qu’il communique bien avec le serveur désiré. Si, à l’avenir, la clé d’hôte ne correspond plus à la version enregistrée sur le client, l’utilisateur doit supprimer cette dernière avant qu’une nouvelle connexion puisse avoir lieu.
Attention:
Il est tout à fait possible pour un intrus de se faire passer pour le serveur SSH lors de la première connexion car le système local ne détecte aucune différence entre le serveur désiré et le faux serveur créé par le pirate. Afin d’éviter une telle situation, contrôlez l’intégrité d’un nouveau serveur SSH en contactant l’administrateur du serveur avant d’établir la première connexion ou dans le cas où une clé d’hôte ne correspond pas à celle stockée sur le serveur.
Le protocole SSH est conçu pour fonctionner avec presque tout type d’algorithme de clé publique ou tout format de codage. Après que l’échange initial des clés crée une valeur de hachage utilisée pour les échanges et une valeur secrète partagée, les deux systèmes commencent immédiatement à calculer de nouveaux algorithmes et de nouvelles clés pour protéger l’authentification et les futures données envoyées via la connexion.
Après la transmission d’une certaine quantité de données au moyen d’une clé et d’un algorithme précis (la quantité exacte dépend de l’implémentation du protocole SSH), un nouvel échange de clés s’effectue ; cette opération engendre la création d’un autre ensemble de valeurs de hachage et d’une autre valeur secrète partagée. De cette façon, même si un intrus réussit à déterminer les valeurs de hachage et la valeur secrète partagée, ces informations ne lui seront utiles que pour une durée limitée.
12 Authentification:
Une fois que la couche de transport a crée un tunnel sécurisé pour envoyer les informations entre les deux systèmes, le serveur indique au client les différentes méthodes d’authentification prises en charge, telles que l’utilisation d’une signature dotée d’une clé codée ou la saisie d’un mot de passe. Le client doit ensuite essayer de s’authentifier auprès du serveur au moyen d’une des méthodes spécifiées.
Les serveurs et clients SSH pouvant être configurés de façon à permettre différents types d’authentification, donnant à chacune des deux parties un niveau de contrôle optimal. Le serveur peut décider des méthodes de cryptage qu’il prend en charge en fonction de son modèle de sécurité et le client lui peut choisir l’ordre des méthodes d’authentification à utiliser parmi les options disponibles. Grâce à la nature sécurisée de la couche de transport SSH, même les méthodes d’authentification qui au premier abord semblent non-sécurisées (telles que l’authentification basée sur l’hôte et le mot de passe) peuvent être utilisées en toute sécurité.
13 Canaux:
Après avoir effectué avec succès l’authentification au moyen de la couche transport SSH, des canaux multiples sont ouverts au moyen d’une technique appelée multiplexage. Chacun de ces canaux peut traiter la communication pour des sessions de terminal différentes et pour des sessions de retransmission X11. Le client et le serveur peuvent créer un nouveau canal. Chaque canal reçoit ensuite un numéro différent à chaque extrémité de la connexion. Lorsque le client essaie d’ouvrir un nouveau canal, il envoie le numéro du canal accompagné de la requête. Ces informations sont stockées par le serveur et utilisées pour diriger la communication vers ce canal. Cette procédure est utilisée afin que des types différents de session ne créent pas de nuisances mutuelles et de sorte qu’à la fin d’une session donnée, son canal puisse être fermé sans que la connexion SSH primaire ne soit interrompue.
Les canaux prennent aussi en charge le contrôle du flux de données, ce qui leur permet d’envoyer et de recevoir des données de façon ordonnée. Ce faisant, aucune donnée n’est envoyée sur le canal tant que l’hôte n’a pas reçu un message lui indiquant que le canal est ouvert.
Le client et le serveur négocient automatiquement la configuration de chaque canal, en fonction du type de service demandé par le client et de la manière selon laquelle l’utilisateur est connecté au réseau. Ainsi, le traitement des différents types de connexions distantes est non seulement extrêmement flexible, mais il ne nécessite même pas d’apporter des modifications à la structure de base du protocole.
14 OpenSSH sans mot de passe (clefs de chiffrement):
Une configuration un peu particulière de SSH ne nécessite pas l’utilisation de mot de passe ou de phrase secrète mais un échange de clefs. Cela permet à un utilisateur ayant un compte sur 2 machines différentes de se connecter de l’une à l’autre facilement. Mais bien sûr, cela fragilise la sécurité mise en place. En effet, l’accès au compte source donne accès au compte cible.
Voir http://forums.gentoo.org/viewtopic-t-281671-postdays-0-postorder-asc-start-0.html
Cette configuration profite aussi à SCP et à SFTP qui se connectent au même serveur que OpenSSH. Dans le cas particulier de deux comptes sur 2 ordinateurs partageant le même répertoire HOME, cette configuration marchera pour une connexion sans mot de passe dans les deux sens.
On peut ajouter à cela une passphrase et on peut utiliser ssh-agent qui est installé avec le paquet ssh afin de ne pas avoir à la taper trop souvent.
15 rsync:
Si vous souhaitez copier de gros fichiers entre la machine distante et vous, la solution la plus simple consiste à utiliser scp. Mais si une coupure réseau se produit, et que votre téléchargement n’est pas fini, il n’est pas possible de le reprendre directement avec scp. Remplacez votre commande scp par rsync: rsync prends exactement les mêmes arguments que scp, et utilise ssh en coulisse, cette application sait reprendre les téléchargements non finis. Pour ce type d’utilisation, les options les plus utiles à rajouter de rsync sont –partial et –size-only; pour une meilleur visualisation de l’avancement du téléchargement, utilisez les options -v, –progress et –stats.
On peut faire de la complétion sur les répertoires distants avec l’option:
rsync -avPessh
16 Recommandations:
SSH V2 est définie par plusieurs recommandations:
RFC 4251 : Architecture générale du protocole
RFC 4252 : Protocole d’authentification (PKI, par mot de passe ou par machine)
RFC 4253 : Protocole de transport sécurisé (Chiffrement, Signature numérique, intégrité)
RFC 4254 : Protocole de connexion (Port Tunneling, Shell)
man ssh
man scp
man rsync
man sshd_config
man ssh_config
17 Remerciements:
Ce document a été établi grâce à une synthèse de mon expérience personnelle ainsi que d’extraits :
www.openssh.com
http://fr.wikipedia.org/wiki/Secure_shell
http://forums.gentoo.org/viewtopic-t-281671-postdays-0-postorder-asc-start-0.html
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/fr/ref-guide/ch-ssh.html
http://jujuseb.com/dotclear/?2006/04/18/6-fail2ban-contre-l-attaque-par-brute-force
Merci aux gens de irc.freenode.org et irc.europnet.org qui m’ont aidé à »debugger » ce document :
perlmonk, ycarus, ju, oenone, freebzh, morphalux, domix, leander256 ainsi que JohnBananaQwerty et Phanette 
Certains passages de cet article, ou d’une version antérieure de cet article, sont basés sur l’article »Protocole SSH » du site Web www.redhat.com L’article d’origine porte la notice de copyright suivante : »Copyright © 2005 par Red Hat, Inc » Ce document est soumis à la licence GNU FDL. Vous pouvez copier, modifier des copies de cette page tant que cette note apparaît clairement. »
