Forums d'entraide informatique - Astuces - Conseils

SSH : Secure Shell
Le mot clef Hast suivi d'un nom de machine (tel qu'utilisé sur la ligne de commande de ssh ou de scp) définit un jeu de paramètres spécifiques à cet hôte. La portée de Host est déterminée par la présence d'une autre occurrence du mot clef ou la fin du fichier de configuration. Les caractères jokers * et ? permettent de définir des motifs. Un simple * définira une configuration globale pour tous les hôtes distants.
Imaginons que nous accédions à une machine raven utilisant une ancienne version d'OpenSSH et une machine morgane qui utilise une implémentation du protocole SSH2. Nous aurons donc dans notre fichier de configuration :
Host morgane
port 22
Protocol 2
PubkeyAuthentication yes PasswordAuthentication yes
Host raven
port 22
Protocol 1
RSAAuthentication yes PasswordAuthentication yes
Ici, par mesure de sécurité, nous estimons que la première méthode d'authentification à tester est le mécanisme des clefs. Si cela échoue, nous nous rabattons sur le mécanisme classique à mot de passe. Bien sûr. dans un cas de mise en production, nous ne prendrions pas de telles initiatives. L'erreur ne peut être tolérée.
D'autres paramètres utiles peuvent êtres ajoutés dans ce fichier de configuration. Imaginons, par exemple, que nous n'utilisions pas la même paire de clefs publique/privée avec tous les hôtes distants. Nous pouvons facilement spécifier ce genre de choses en précisant quel fichier doit être lu :
Pour morgane :
IdentityFile -/.ssh/morgane/id_dsa IdentityFile -hssh/morgane/id_rsa
Pour raven :
IdentityFile -/.ssh/raven/identify
Il est ainsi possible d'organiser une arborescence
complète dans le répertoire - / . ssh afin de garder une certaine cohérence dans la configuration, tout en n'utilisant pas les mêmes clefs pour tous les hôtes distants. Un autre paramètre intéressant vous permettra de définir un utilisateur pour la connexion ssh:
User moimeme
La syntaxe de connexion du client ssh prend en effet un paramètre -1 utilisateur spécifiant le compte distant à utiliser. Il est également possible de le spécifier directement dans le nom de la machine à la manière d'une adresse email : ut ilisateur@machine. Ce paramètre User vous évitera d'utiliser le paramètre -1 sur la ligne de commande si votre compte distant n'est pas le même que sur la machine locale.
Les paramètres en ligne de commande
Le client ssh utilise la configuration fournie dans l'ordre suivant :
I- les paramètres en ligne de commande ;
2- les informations spécifiques à l'utilisateur du
fichier - / ssh/config :
3- la configuration globale du système dans le
fichier /usr/local/etc/ssh_config.
Nous pouvons donc à tout moment surpasser les informations des deux fichiers de configuration en fournissant des arguments sur la ligne de commande. Voici quelques-uns des paramètres utilisables :
•    i renseigne sur le fichier de clef à utiliser (équivalent du IdentityFile) ;
•    y permet d'activer le mode bavard (nous verrons plus amplement l'utilité de ce paramètre dans le paragraphe traitant de la résolution des problèmes) ;
•    1 précise le nom du compte distant à utiliser si celui-ci n'est pas le même qu'en local ;
•    1 ou -2 permettent de forcer respectivement l'uti-
lisation du protocole SSH1 ou SSH2 ;
•    F permet de spécifier un fichier de configuration alternatif ;
•    x et -x permettent respectivement de désactiver ou d'activer le tunneling X11 (affichage X déporté).
Connexion par mot de passe
Ici, pas grand-chose à dire ou faire. Configurez simplement Pas swordAuthent icat i on à yes dans sshd_config et dans votre ssh_config, et le tour est joué. Lancez votre client ssh ainsi
$ ssh utilisateur@machine
ou
S ssh machine
Si le compte est identique, saisissez votre mot de passe normal.
Cette méthode d'authentification n'apporte pas d'autre avantage que d'être compatible avec la méthode rlogin ou rsh et ce, avec une communi- cation chiffrée.
Connexion par paires de clefs
Qu'il s'agisse du protocole SSH I ou SSH2. il est possible de s'authentifier auprès du serveur en utilisant les clefs que vous avez générées en début d'article. Chaque paire est composée d'une partie privée et d'une partie publique.
Le système de clefs asymétriques repose sur un prin- cipe simple
Ce qui est chiffré avec la clef publique ne peut être déchiffré qu'avec la clef privée correspondante. Il n'est pas possible (dans un temps humainement cal- culable) de dériver la clef privée à partir de la clef publique.
Pour bien comprendre le schéma de fonctionne- ment, il suffit de connaître le dialogue qui s'établit lors de la connexion du client sur le serveur
Avec le protocole SSH 1. le client va se connecter au serveur. Ce dernier va chercher dans un fichier spé- cifique une clef publique correspondant au client. Il va alors lui envoyer un défi en chiffrant un nombre aléatoire avec la clef publique en question.
Le client va la recevoir et déchiffrer le message pour obtenir le nombre aléatoire en clair qu'il renverra au serveur. Si le serveur, en comparant le nombre aléa- toire d'origine et le nombre renvoyé par le client, véri- fie la similitude, le client peut se connecter.
Avec le protocole SSH2, le système est légèrement différent, bien qu'il repose sur le même principe de clefs asymétriques. Lorsque le client se connecte au serveur, il faut négocier un identificateur de session en utilisant l'algorithme Dulie-Hellman (voir Linux Mag 30). Cet algorithme permet de ne faire circuler à aucun moment l'identifiant de session sur le
réseau. Un espion écoutant la communication ne pourra pas déduire l'identifiant sans résoudre une équation extrêmement complexe. Cet identifiant est un nombre que le client va alors signer avec sa clef privée. Le serveur, dès réception de cette signature, va la vérifier à l'aide de la clef publique du client dont il dispose. Si la signature est bonne, le client peut ouvrir un shell distant.
Dans les manipulations de configuration. l'utilisa- tion de l'un ou l'autre des protocoles se résume aux fichiers clefs à utiliser. Vous l'aurez sans doute com- pris grâce aux explications qui viennent d'être don- nées : le serveur doit disposer de la clef publique du client.
Les clefs publiques des clients pouvant se connecter au serveur sont placées dans un fichier
ssh/authorized_keys dans le répertoire personnel correspondant au compte que le client souhaite utiliser sur le serveur.
Sur le poste client, l'utilisateur dispose normale- ment (s'il a généré les trois types de paires de clefs) de trois fichiers portant un suffixe . pub dans son répertoire —/ . ssh. Il s'agit des clefs publiques associées à ses clefs privées. Le nom des fichiers fournit une indication sur le type de clef. id_dsa.pub. id_rsa .pub et identity.pub sont respectivement les clefs publiques de type dsa et rsa pour SSH2 et rsal pour SSH1.
Pour que le client puisse se connecter en utilisant sa clef, il suffit de placer le contenu de l'un de ces fichiers dans le authorized_keys du serveur. Ainsi, lors de la connexion, le serveur pourra véri- fier l'identité du client.
Prenons un exemple pratique, soit les fichiers de configuration suivants :
Surleserveur
Port 22
Protocol 2
HostKey /etc/ssh_host_key HostKey /etc/ssh_host_dsa_key HostKey /etc/ssh_host_dsa_key LoginGraceTime 600
PermitRootLogin yes
PubkeyAuthentication yes
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no HostbasedAuthentication no

Nous utilisons un protocole SSH2 (Protocol 2) et souhaitons une authentification par paires de clefs. Notez que nous avons délibérément mis PasswordAuthentication à no afin que la seule méthode d'authentification utilisable soit l'utilisation des clefs. Dans la configuration du client, nous paramétrons dans le même esprit sans oublier de spécifier nos fichiers de clefs.
L'étape suivante consiste tout simplement à copier le contenu d'un des fichiers de clef publique (suffixe .pub) dans le fichier authorized_keys du serveur. La clef publique d'un client peut parfaitement être envoyée en clair, par email par exemple, à l'administrateur du serveur. En effet, comme son nom l'indique. seule la clef privée doit rester secrète pour garantir la sécurité du système.
ATTENTION : Il est important de faire le point sur un élément très important à propos des clefs privées. Alors que la clef publique peut être facilement échangée par des méthodes tout à fait classiques, la clef privée doit être protégée avec la plus grande attention. Lors de la génération des paires de clefs,
l'utilitaire ssh-keygen vous a demandé de saisir
une phrase de passe. Cette phrase protège votre clef privée. Vous pourriez parfaitement vous abstenir d'utiliser cette protection en utilisant une phrase de passe vide. Cependant. il faut bien comprendre les implications d'un tel choix :
1- Avec un simple mot de passe, vous courrez le risque que celui-ci soit deviné (s'il est mal choisi) ou que, plus simplement, quelqu'un vous observe en train de le saisir.
2- Avec une clef privée sans mot de passe, une personne ayant accès à votre compte peut copier la clef
et s'en servir pour accéder à votre compte sur le serveur SSH. En clair, le simple fait que votre clef arrive entre de mauvaises mains compromet la sécurité, c'est-à-dire si votre ordinateur client est visité.
3 - Avec une clef privée protégée par une phrase de passe, il faut à l'attaquant non seulement accéder au fichier de clefs pour voler la clef privée, mais il lui faut également trouver la phrase permettant de l'utiliser.
Maintenant, tout dépend de ce que voùs souhaitez mettre en oeuvre. L'utilisation de clefs privées sans phrase de passe doit être limitée aux cas où vous souhaitez automatiser une procédure de transfert de fichiers ou un accès aux serveurs. En effet, il n'existe qu'un seul moyen d'utiliser une phrase de passe dans une procédure automatique : s shagent. Cet utilitaire permet, entre autres choses. de saisir la phrase de passe à votre place. Nous en parlerons plus loin dans l'article.
Cet exemple peut facilement être adapté à l'utilisation du protocole SSH1 en remplaçant les entrées correspondantes dans les fichiers de configuration. Les manipulations de copie de clefs publiques sont identiques.
Dernière précision. il est possible de configurer plusieurs fichiers authorized_keys distincts. Il suffit pour cela d'utiliser le mot clef AuthorizedKeysFile dans le fichier de configuration du serveur sshd. Un certain nombre de caractères servent de caractères de remplacement. Ainsi, %u sera complété avec le nom d'utilisateur et %h par le répertoire personnel de l'utilisateur en question. Cela permettra une gestion plus souple que les fichiers authorized_keys placés dans les différents répertoires des utilisateurs.
Un petit mot sur rhost
Nous en avons déjà parlé, l'authentification utilisant rshost n'est pas recommandée. Cependant, ceci peut servir comme un atout supplémentaire pour s'assurer de l'identité des deux machines en présence. Nous avons généré en tout début d'article des paires de clefs pour la machine. Celles-ci servent à identifier clairement le serveur dans une utilisation classique.
En vous connectant pour la première fois à un serveur SSH, vous risquez de voir apparaître le messaSSH : Secure Shell
ge suivant :
The authenticity of host '193.252.208.169 (193.252.208.169)    can't be established.
RSA key fingerprint is 74:23:9e:a8:e8:26:a5:08:04:83:40:de:ab:a6:c6:85. Are you sure you want to continue connecting (yes/no)?
Il vous faudra, en principe, téléphoner à l'adminis- trateur du serveur pour qu'il vous confirme l'em- preinte (fingerprint) de la clef RSA. Dans la pra- tique, cela est assez rare. L'administrateur récupére- ra le fingerprint avec :
parfois pénible d'avoir à saisir la phrase de passe à chaque connexion. Dans ce cas, vous pouvez solu- tionner le problème en utilisant l'agent d'authentifi-
cation. s sh-agent est un programme qui se char-
ge de faire ces manipulations à votre place.
Le principe est le suivant : lors de votre tout pre- mier login sur votre machine, l'agent d'authentifica- tion est lancé. Vous pouvez alors transmettre vos différentes clefs à ce dernier avec la commande
ssh-add. Si les clefs sont protégées par un mot de passe, ssh-add vous les demandera et les trans-
mettra à l'agent.
$ ssh-keygen -1 -f /etc/ssh_host_rsa_key 1024
74:23:9e:a8:e8:26:a5:08:04:83:40:de:ab:a6:c6:85 /etc/ssh_host_rsa_key.pub
A partir du moment où vous acceptez la clef du ser- veur (en répondant yes à la question), celle-ci sera stockée dans un fichier -/ ssh/known_hosts regroupant les clefs des hôtes connus.
Si, lors d'une prochaine connexion, la clef transmi- se par le serveur ne correspond pas à celle du fichier known_hosts, un message d'avertissement blo- quera la tentative de connexion. Un changement de clefs peut provenir du fait que l'administrateur du serveur SSH ait généré de nouvelles clefs, mais surtout que quelqu'un essaie de détourner votre connexion dans le but d'une attaque de type Men In The Middle (voir le Linux Mag hors série numéro 8).
Voici un exemple d'avertissement de ce type
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is a1so possible that the RSA1 host key has just been changed.
The fingerprint for the RSA1 key sent by the remote host is
14:2a:17:b7:61:c1:41:f4:2d:54:b0:53:ae:a2:e4:76. Please contact your system administrator.
L'agent d'authentification
Si vous utilisez SSH plusieurs fois par jour, il est
Il est important de noter qu'en tuant l'agent avec
s sh- agent -k, il perdra toutes les clefs qu'il pos-
sède. C'est d'ailleurs le but : aucune clef ou phrase
de passe n'est stockée sur le système de fichiers et
les données ne sont valables que pour une seule ses-
sion.
Ainsi, durant toute la durée de votre session sur la machine locale, vous profiterez des services fournis par l'agent, mais attention : laisser votre poste sans surveillance présente un danger important pour la sécurité. Si l'agent est en cours d'exécution, n'importe qui peut accéder aux serveurs SSH sans avoir à saisir votre phrase de passe.
L'utilisation de l'agent ssh est plus sûre que la mise en oeuvre de clefs sans protection par phrase de passe, mais cela ne me semple pourtant pas suffisant. Par mesure de sécurité et en fonction de l'en- droit d'où vous vous connectez, il est préférable de prendre la peine de saisir manuellement vos phrases de passe.
Lors de son lancement, l'agent d'authentification vous fournira plusieurs variables d'environnement qui seront utilisées par ssh et ssh-add :
$ ssh-agent SSH_AUTH_SOCK./tmp/ssh-XXcbV50c/agent.19446:
export SSH_AUTH_SOCK;
SSH_AGENT_PID.19447; export SSH_AGENT_PID; echo Agent pid 19447;
Avec la commande ssh-agent sans argument,
vous obtiendrez les différentes déclarations de variables d'environnement à utiliser (un simple copier/coller fera l'affaire). Une solution plus simple consiste à utiliser le paramètre bash qui vous lancera un shell bash ou x qui lancera votre session XFree86.
Tunneling SSH
En plus de fournir l'équivalent des commandes rcp, rlogin et rsh de manière chiffrée avec une authentification bien plus sécurisée, les protocoles SSH permettent la mise en oeuvre du tunneling de manière relativement simple. Lorsque que vous ouvrez une session sur un hôte ssh, vous pouvez également ouvrir un canal de communication sécurisé pour tous les autres protocoles.
Il est indéniable que la plupart des protocoles envoient les informations en clair sur le réseau. L'astuce ici est de se servir du canal ouvert par ssh pour encapsuler les informations en clair et les faire transiter d'une machine à l'autre.
Prenons un exemple concret avec un serveur POP3. Celui-ci est par exemple accessible avec telnet sur le port 110 :
$ telnet machine 110
On utilise alors les commandes POP3 pour s'authentifier (login et mot de passe) sur le serveur et lister le contenu de la boîte POP3 sur le serveur distant. Le problème est que tout ce que vous allez taper et lire sur votre session telnet peut être espionné par un autre utilisateur. Pire encore, on peut avoir détourné le flux de données vers une autre machine en vous laissant croire que vous vous connectez réellement à votre serveur POP3 habituel.
La technique consiste alors à utiliser SSH pour faire transiter ces informations. Une fois la connexion établie, un port arbitrairement choisi sur la machine locale sera utilisé pour la communication. Les informations circulant sur ce port seront prises en charge par SSH et transmises au serveur SSH distant qui les communiquera au serveur POP3 en local. Si cela vous semble complexe, l'exemple suivant va immédiatement clarifier les choses :
Dans un premier xterm, lancer la connexion ssh : $ ssh -L 4000:machine:110 machine
• L est ici le paramètre important (L comme Local); nous spécifions que nous voulons utiliser le port 4000 de la machine en local comme point d'accès
sécurisé vers machine sur le port distant 110. Nous répétons machine pour établir la connexion. Selon votre procédure d'authentification, entrez votre mot de passe ou votre phrase de passe (ou rien du tout). Dès lors, tous les logiciels qui accéderont à localhost : 4000  accéderont en fait de manière sécurisée à machine : 110.
Vous pouvez faire le test très simplement en ouvrant un telnet dans un autre xterm de cette manière :
$ telnet localhost 4000
Vous accéderez effectivement au serveur POP3 distant au détail près que tout passe par SSH, est donc chiffré et "inespionnable".
De la même manière, à partir du serveur POP3, vous pouvez permettre à un client SSH de faire de même. Le paramètre devient -R (comme Remote):
$ ssh -R 4000:machine:110 machine
La syntaxe est la même, mais à ce moment-là, vous permettrez à l'utilisateur sur machine d'utiliser 1 ocalhost : 4000  pour accéder à votre serveur POP3 de manière sûre.
Résolution des problèmes
Il est fort probable qu'en installant et en utilisant pour la première fois OpenSSH (ou toutes autres implémentations), vous vous mélangiez les pinceaux entre les différents paramètres et protocoles. Dans la majorité des cas, l'utilisation du mode bavard est suffisant pour immédiatement repérer le problème. Ajoutez alors simplement le paramètre - y sur la ligne de commande de ssh pour voir apparaître la plupart des informations concernant la connexion. Si cela n'est pas suffisant, vous pouvez répéter l'argument plusieurs fois afin d'augmenter le niveau d'information à afficher.
Une autre solution consiste à configurer, côté serveur cette fois, quelques lignes dans le fichier de configuration sshd_conf ig. Vous afficherez ainsi toutes les informations utiles dans le journal d'activité système :
SyslogFacility AUTH
LogLevel INFO
SyslogFacility permet de choisir le type de message à employer (DAEMON, USER, AUTH, LOCALO à LOCAL7) et LogLevel spécifie le niveau d'information à mettre dans le log (QUIET, FATAL, ERROR, INFO, VERBOSE ou DEBUG). En phase de résolution de problème, c'est bien sûr DEBUG qui est à utiliser.
Dernier point important : nous avons rencontré des problèmes sur une machine utilisant GCC en ver- sion 3.0. Les symptômes se résumaient à l'impossi- bilité de saisir la phrase de passe en utilisant le pro- tocole SSH2 (clefs dsa ou rsa). Il n'y avait aucun souci avec SSH1 ou l'authentification par mot de passe. Ce problème a été signalé très récemment sur la liste de diffusion OpenSSH et concernerait un bogue dans le compilateur GCC 3.0. Le problème ne concerne pas directement OpenSSH mais les bibliothèques OpenSSL. Si ces dernières ont été compilées avec GCC 3.0, le problème surgit dans OpenSSH qui, lui, peut être compilé avec n'importe quelle version de GCC. Après vérification, nous en sommes arrivés aux mêmes conclusions. Par consé- quent, si vous utilisez un GCC 3.0. il vous faudra compiler OpenSSL avec l'ancienne version stable (GCC 2.95.3).
Faciliter les choses avec le port forwarding
Si vous utilisez SSH dans un environnement profes- sionnel pour accéder à votre machine personnelle à la maison (et inversement), il est fort probable que vous aurez à faire face au problème du firewall. En effet, pour vous connecter de votre lieu de travail à la maison, vous devrez sans doute vous connecter à la machine NAT chez vous pour ensuite rebondir sur votre station de travail. Cela devient rapidement très pénible.
Mais vous pouvez contourner ce problème grâce au port forwarding. La technique consiste, sur la machine passerelle, à détourner les connexions entrantes sur un port spécifique vers une autre machine (du réseau local) sur le port ssh (22).
Voici un premier exemple sur une machine utilisant un kernel de la série 2.2
ipmasqadm portfw -P tcp -L xxx.xxx.xxx.xxx 2222 -R 192.168.0.25 22
Nous utilisons ici le module port fw (port forward) pour détourner toutes les connexions arrivant sur xxx. xxx . xxx. xxx : 2222  vers 192.168.0.25:22 en protocole TCP.
Voici la version kernel 2.4:
$ iptables -t nat -I PREROUTING -p tcp    ethO
--dport 2222 -j DNAT --to 192.168.0.25:22
Les paramètres sont plus ou moins les mêmes, à la différence que nous pouvons préciser ici l'inter- face et non pas l'IP, ce qui peut être très avanta- geux dans le cas d'une connexion -Internet avec un IP fourni dynami- quement par le provider.
Vous n'aurez plus, ensuite, qu'à pré- ciser le port 2 222 pour la connexion avec le paramètre -p pour ssh et -P pour sep. Je tiens ici à remercier Galadril et psike du chan #parinux pour ses informations.
Et voilà, les informations pratiques de cet article devraient vous permettre de faire vos premiers pas avec OpenSSH. Un certain nombre de sujets n'ont pas été couverts comme SFTP (un FTP sécurisé SSH), mais vous trouverez sans doute facilement les informations dans les pages de manuel des diffé- rents utilitaires OpenSSH.