Voir la source de SSH

= SSh, la sécurisation par le chiffrement =

<div class="leatitre">SSh, la sécurisation par le chiffrement</div><div class="leapar">par [mailto:jpgaulier_(@)_linux-france.org Jean-philippe Gaulier]</div> 

'''Licence du document :''' FDL<br />http://www.gnu.org<br />

----

== Préambule ==

Il y a aujourd'hui deux possibilités de travail, en local (local work) ou à distance (remote work). Ce dernier est permis par l'utilisation du réseau, qu'il soit local (LAN) ou réellement éloigné, comme par Internet (WAN). De nombreux outils ont été fournis pour utiliser la capacité du réseau. Échanger, copier, utiliser des shells à distance. Les noms de ces outils sont respectivement FTP, rcp, telnet, etc... Bien que ces outils, utilisés pendant des années et même encore aujourd'hui dans certaines entreprises, soient très pratiques, ils comportent une faiblesse importante. Leurs transactions sont transmises en clair via le réseau. De ce fait, l'informatique devenant ouvert à un grand nombre, n'importe quelle personne mal intentionnée peut être en mesure d'observer ce que vous faîtes, allant même jusqu'à subtiliser vos données personnelles et mots de passe.

'''<u>Le problème par la pratique</u>'''

Pour pouvoir appuyer cette notion de non-confidentialité, nous allons regarder ce qui se passe lors de l'établissement d'une connexion d'une session telnet. Le logiciel utilisé pour tracer les connexions est '''ethereal'''.<br /> Établissons la connexion sur un serveur ''telnetd'' fonctionnant sous GNU/Linux. Après quelques échanges de paquets, nous obtenons la bannière d'accueil :

[[Image:ssh-telnet1.png]]

on constate que la connexion s'effectue sur le port 23 (en 22 et 23 dans la trame).<br /> Les données quant à elles commencent clairement en 42, avec la bannière d'accueil :<br /> Debian GNU/Linux testing/unstable centaur

Les données ont été envoyées en clair et la bannière permet de définir le système d'exploitation sur lequel nous sommes accueillis. Continuons notre étude, la demande d'identification est proposée par le système distant :

[[Image:ssh-telnet2.png]]

Il faut maintenant se faire reconnaître auprès du système. Nous supprimerons tout echo local doublant l'envoi de caractères, un pour le système distant et un pour voir ce que nous écrivons. Il en résulte une suite d'échange avec notre interlocuteur :

[[Image:ssh-telnet3.png]]<br />[[Image:ssh-telnet4.png]]<br />[[Image:ssh-telnet5.png]]<br />

Nous envoyons notre identifiant à la machine distante, les trames ne sont pas utilisées à l'économie puisque chaque paquet contient seulement un et un seul caractère comme données (data). On retrouve ici notre identifiant, jop, envoyé pour nous loguer. Ce qui est inquiétant, c'est que la même chose va également se produire pour notre mot de passe censé être privé et inviolable.<br /><br />[[Image:ssh-telnet6.png]]<br />[[Image:ssh-telnet7.png]]<br />[[Image:ssh-telnet8.png]]<br />[[Image:ssh-telnet9.png]]<br />[[Image:ssh-telnet10.png]]<br /> Le mot de passe est ici clairement exprimé. On peut lire bobo, la dernière trame transmet un retour chariot.

''<u>Nota</u> : Notre étude ne se portant pas sur le service telnet, nous ne rentrerons pas sur le détail des transmissions et considérons que ces quelques remarques suffisent pour notre étude.''

De la même manière, tout comme on vient de vous dérober votre mot de passe, on peut récupérer vos conversations, vos fichiers. La confidentialité est rompue, la porte est ouverte à l'insertion non-chalente de personnes non autorisées dans le système...

== La solution proposée ==

Afin de ne plus être ouvert au monde entier, nous avons la possibilité de chiffrer nos échanges. Pour ce faire, nous allons installer un client ssh, '''Openssh'''. Client libre et gratuit. Par la même occasion, vous pourrez installer le serveur, afin que votre ordinateur puisse aussi être contacté par d'autres utilisateurs, vous permettant de délivrer des services sécurisés.

Nous allons continuer notre étude dans le cadre de ce logiciel, libre à vous d'adapter à vos préférences par la suite, sachant que le principal est ici transcrit.

Afin de mieux comprendre le comportement et l'utilité de chaque programme, décomposons les différents paquets ainsi que l'usage fait des exécutables.

{|
! Mémo
|-
| '''sshd''' : Serveur ssh
|-
| '''scp''' : Copie distante sécurisée
|-
| '''ssh-keygen''' : génération de clefs d'authentification, management et conversion
|-
| '''sftp''' : Transfert sécurisé de fichiers
|-
| '''slogin/ssh''' : Client ssh
|-
| '''ssh-add ''' : Ajoute les identités DSA ou RSA à l'agent d'authentification
|-
| '''ssh-agent''' : Agent d'authentification
|-
| '''ssh-keyscan''' : Recueille les clefs publiques ssh
|}

Nous traiterons chacune de ces applications afin de comprendre dans quels contexte elles peuvent être utilisées.

== Connexion à un hôte ==

Le client ssh opère selon un ordre défini :

# les paramètres en ligne de commande
# les informations spécifiques à l'utilisateur du fichier '''~/.ssh/config'''
# la configuration globale du système dans le fichier '''/usr/local/etc/ssh_config''' ou '''/etc/ssh/ssh_config''' (cela dépendant de la distribution que vous utilisez)

'''<u>Le fichier ssh_config</u>''' :
Ce fichier représente la configuration du client ssh. 

<div class="code">
 #$OpenBSD: ssh_config,v 1.15 2002/06/20 20:03:34 stevesk Exp $

 <nowiki>#</nowiki> Ceci est le fichier de configuration par défaut des clients ssh du système. Voir<br />
 <nowiki>#</nowiki> ssh_config(5) pour de plus amples informations. Ce fichier fournit les paramètres par défaut<br />
 <nowiki>#</nowiki> pour les utilisateurs, ces valeurs peuvent être changées pour chaque utilisateur dans leur propre<br />
 <nowiki>#</nowiki> fichier de configuration ou sur la ligne de commande.

 <nowiki>#</nowiki> Les données de configuration sont analysées comme ci-dessous :<br />
 <nowiki>#</nowiki> 1. Les options de la ligne de commande<br />
 <nowiki>#</nowiki> 2. Le fichier spécifique de l'utilisateur<br />
 <nowiki>#</nowiki> 3. Le fichier par défaut<br />
 <nowiki>#</nowiki> N'importe quelle valeur de configuration est uniquement changée la première fois qu'elle est mise.<br />
 <nowiki>#</nowiki> Ainsi, les définitions spécifique d'hôte doivent être au début du fichier de configuration<br />
 <nowiki>#</nowiki> et les options par défaut à la fin.

 <nowiki>#</nowiki> Options par défaut

 <nowiki>#</nowiki> Pour que les options soient prises en compte, il vous faut enlever le dièse précédent la ligne.

 <nowiki>#</nowiki> Host permet de spécifier que la configuration qui suit concerne un ou plusieurs hôtes précis.<br />
 <nowiki>#</nowiki> Il est possible d'employer des caractères joker tels que * ou ?.

 '''<nowiki>#</nowiki> Host *'''<br />
 <nowiki>#</nowiki> Specifie si la connexion à l'agent d'authentification doit être renvoyé vers la machine distante

 '''<nowiki>#</nowiki> ForwardAgent no'''

 <nowiki>#</nowiki> Autorise ou non la redirection du serveur graphique

 '''<nowiki>#</nowiki> ForwardX11 no'''

 <nowiki>#</nowiki> Autorise la méthode d'authentification par Rhosts. Peu sûr.

'''<nowiki>#</nowiki> RhostsAuthentication no'''
 
 <nowiki>#</nowiki> Autorise la méthode d'authentification par Rhosts sur du RSA. Ne fonctionne que dans la version <br />
 <nowiki>#</nowiki> première du protocole et nécessite un setuid root. De préférence à ne pas utiliser.

 '''<nowiki>#</nowiki> RhostsRSAAuthentication no'''<br />
 <nowiki>#</nowiki> Méthode d'authentification par RSA, ne fonctionne qu'avec la première version du protocole. Il <br />
 <nowiki>#</nowiki> faut que le fichier identity existe.

 '''<nowiki>#</nowiki> RSAAuthentication yes'''

 <nowiki>#</nowiki> Autorise la connexion par mot de passe, comme on pouvait la trouver dans rlogin ou telnet.

 '''<nowiki>#</nowiki> PasswordAuthentication yes'''

 <nowiki>#</nowiki> Si l'indicateur est positionné à yes, la demande de passephrase ou de mot de passe sera annulée.<br />
 <nowiki>#</nowiki> Cette option est utilisée dans le cas où seul des scripts interviennent et où il n'y a pas d'utilisateur <br />
 <nowiki>#</nowiki> présent pour insérer le mot de passe.

 '''<nowiki>#</nowiki> BatchMode no'''

 <nowiki>#</nowiki> Vérification de l'adresse IP de l'hôte qui se connecte dans le fichier known_hosts

 '''<nowiki>#</nowiki> CheckHostIP yes'''

 <nowiki>#</nowiki> Cette option permet de gérer l'ajout et le changement des clefs hôtes dans known_hosts.<br />
 <nowiki>#</nowiki> Si la clef a changé, la connexion vous sera refusée, vous indiquant le motif.

 '''<nowiki>#</nowiki> StrictHostKeyChecking ask'''

 <nowiki>#</nowiki> Localisation des fichiers identity, id_rsa, id_dsa

 '''<nowiki>#</nowiki> IdentityFile ~/.ssh/identity<br />
 <nowiki>#</nowiki> IdentityFile ~/.ssh/id_rsa<br />
 <nowiki>#</nowiki> IdentityFile ~/.ssh/id_dsa'''

 <nowiki>#</nowiki> Port de connexion à l'hôte distant.

 '''<nowiki>#</nowiki> Port 22'''

 <nowiki>#</nowiki> Version des protocoles supportés et désirés. Ici, on préfèrera employer la deuxième version si <br />
 <nowiki>#</nowiki> elle est disponible.

 '''<nowiki>#</nowiki> Protocol 2,1'''

 <nowiki>#</nowiki> Protocole de chiffrement (ssh v1) et protocoles disponibles par ordre de préfèrerance (ssh v2).

 '''<nowiki>#</nowiki> Cipher 3des<br />
 <nowiki>#</nowiki> Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc'''

 <nowiki>#</nowiki> Caractère d'échappement.

 '''<nowiki>#</nowiki> EscapeChar ~'''
</div>

Il existe différentes options pour se connecter à un hôte via ssh. Libre à vous de les utiliser ou non.<br /><br />'''-l login''' : Identifiant de l'utilisateur. <br />'''-v -vv -vvv''' : Mode verbeux, permet d'obtenir les messages de debugage plus ou moins complets (plus il y a de v, plus vous obtenez d'information, le nombre maximum étant 3).<br />'''-1 ou -2''' : version de ssh employé. Il est déconseillé d'employer la version 1 du protocole. Bien qu'aucun exploit public ne circule, les faiblesses cryptographique du protocole ont été prouvée. De plus, la version 2 est reconnue par l'IETF<br />'''-p port''' : Numéro du port distant

'''<u>Exemple d'utilisation</u>''' :<br /><div class="code">ssh -vv -l utilisateur -p port -(1|2) hôte</div><br /> ou<br /><div class="code">ssh utilisateur@hôte</div><br /> L'hôte distant doit avoir un serveur ssh, nommé '''sshd''', qui permet la connexion.

== Création de paire de clefs ==

Ssh s'appuie sur des algorithmes à paire de clefs, ce qui signifie que vous disposez d'une clef publique, disponible pour tout un chacun et une clef privée dont vous gardez jalousement l'entrée. Ce système va nous permettre de nous identifier auprès des hôtes que nous désirons contacter. Il nous faut au préalable créer le trousseau.

<div class="code">
 $ ssh-keygen -t dsa

 Generating public/private dsa key pair.
 Enter file in which to save the key (/home/jop/.ssh/id_dsa): 
 Enter passphrase (empty for no passphrase): 
 Enter same passphrase again: 
 Your identification has been saved in /home/jop/.ssh/id_dsa.
 Your public key has been saved in /home/jop/.ssh/id_dsa.pub.
 The key fingerprint is:
 4a:0b:3b:eb:ed:05:47:56:cb:23:28:d3:d7:81:69:08
</div>

<div class="code">
 $ ssh-keygen -t rsa

 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/jop/.ssh/id_rsa): 
 Enter passphrase (empty for no passphrase): 
 Enter same passphrase again: 
 Your identification has been saved in /home/jop/.ssh/id_rsa.
 Your public key has been saved in /home/jop/.ssh/id_rsa.pub.
 The key fingerprint is:
 52:65:28:9a:8b:64:cb:b7:6e:70:75:10:d9:0a:01:d9
</div>

Pour les deux algorithmes (dsa, rsa), le système nous demande dans quel fichier nous désirons sauvegarder la clef. Les fichiers par défaut semblent une bonne solution. Par la suite, une passphrase nous est demandée. Celle-ci est un « mot de passe amélioré », car non limité à un mot ou une petite suite de caractères. Il faut cependant prendre des précautions, car en cas de perte de la passphrase, vous ne pourriez plus vous authentifier en tant que propriétaire authentique.

Nous allons maintenant voir '''trois méthodes de connexion via ssh'''.

=== Connexion par mot de passe ===

La première des méthodes, la plus connue et la plus usitée, reposant sur le modèle employé par rlogin ou rsh; l'hôte distant demande un mot de passe pour s'assurer de votre identité.

<div class="code">
 $ ssh -p 222 -l root 192.168.0.1
 
 The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
 RSA key fingerprint is 74:4c:57:fd:c2:2c:0d:c3:3f:09:01:7d:e8:b7:21:24.
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.
 root@192.168.0.1's password: 
 Last login: Thu Dec 26 03:37:03 2002 from centaur
 $
</div>

Je me connecte au port 222 sur une machine de mon réseau local, demandant de m'identifier comme root. La machine n'est pas connue dans mon fichier '''known_hosts'''. Ce fichier contient les clés hôte DSA des serveurs SSH auxquels l'utilisateur s'est connecté. Cette méthode de connexion est intéressante, mais minimise les capacités que vous avez avec ssh. Pour des connexions telles que vers un serveur CVS, un tunnel pour votre courrier, il serait fastidieux de s'authentifier à chaque fois par ce moyen.

=== Connexion par paires de clef ===

Puisque nous utilisons des algorithmes à paire de clefs (rsa, dsa), c'est à dire composée d'une clef secrète et d'une clef publique, il faut bien que cela nous serve à quelque chose. Nous allons donc automatiser la connexion. Pour ce faire, votre hôte contient un fichier '''authorized_keys''' dans le répertoire '''.ssh '''où vous vous connectez (en général un home directory). Il suffit de copier l'identifiant ou les identifiants de vos clefs publiques pour que vous soyez reconnu du serveur. <br /><br />'''Attention''', il faut que ''PubkeyAuthentication ''soit positionné à ''yes'' dans vos fichiers de configuration.<br /> Pour insérer ma clef, j'ai plusieurs méthodes à ma disposition. Je peux employer des moyens conventionnels tels que le ftp ou le mail (à l'administrateur par exemple), ou je peux le faire au moyen d'outil sécurisé. Puisque c'est notre sujet, profitons en pour donner un exemple de ''scp'' sur lequel nous reviendrons ultérieurement.

<div class="code">
 $scp .ssh/id_dsa.pub jop@scipc-jpg:/home/jop/.ssh/dsa2connex

 Warning: Permanently added 'scipc-jpg' (RSA) to the list of known hosts.
 jop@scipc-jpg's password: 
 id_dsa.pub 100% |*****************************| 613 00:00
</div>

Mon fichier est maintenant copié sur l'hôte distant, il me reste à inclure la clef dant le fichier authorized_keys. Une simple commande suffira :

<div class="code">$ cat dsa2connex >>authorized_keys
</div>

Je peux maintenant me connecter, l'hôte distant me reconnaît. Je peux me connecter sans mot de passe et avec une passphrase si j'en ai désiré une.

=== L'agent d'authentification ===

Nous savons maintenant nous connecter à un hôte distant connaîssant notre identité par l'intermédiaire de notre clef publique. Nous avons vu précédement que nous étions libre de mettre ou non une passphrase afin de chiffrer notre identification et compliquer l'usurpation qui pourrait en être faite [mode parano on]. S'il paraît fastidieux d'insérer un mot de passe à chaque connexion, cela l'est d'autant plus lorsque l'on doit rentrer une phrase entière. L'agent ssh est là pour nous simplifier la vie. Lancé au début de la session (terminal ou graphique), il retient la passphrase le temps où '''ssh-agent '''sera actif (le temps d'une session).

Pour une session en <u>mode terminal</u> :
<div class="code">
 $ssh-agent screen
 $ssh-add
</div>

Après avoir lancé l'agent ssh, on ajoute la passphrase à l'agent par l'intermédiaire de '''ssh-add''' ; tous les hôtes distants disposant de votre clef publique ne vous demanderons alors plus la passphrase puisque gérée par l'agent ssh.

De même, en <u>mode graphique</u> :
<div class="code">$ssh-agent startx</div>

Il vous suffit ensuite d'ouvrir un terminal et de taper<br /><div class="code">$ssh-add</div><br /> L'agent sera actif pour toutes les applications utilisées en mode graphique.

Une dernière méthode consiste à '''lancer l'agent-ssh''' qui fournit un certains nombre de variables à exporter, puis demander l'action de ssh-add :
<div class="code">$ssh-agent</div>

On récupère les variables fournies et on les exporte :
<div class="code">
 $SSH_AUTH_SOCK=/tmp/ssh-XXy0hiXW/agent.2019; export SSH_AUTH_SOCK;
 $SSH_AGENT_PID=2020; export SSH_AGENT_PID;
 $echo Agent pid 2020;
</div>

On ajoute :
<div class="code">$ssh-add</div>

Pour tuer l'agent ssh, il suffit de faire :
<div class="code">
 $ ssh-agent -k
 unset SSH_AUTH_SOCK;
 unset SSH_AGENT_PID;
 echo Agent pid 2020 killed;
</div>

'''Invalidité des clefs d'un hôte connu :'''

Comme nous l'avons vu précédement, lors de votre connexion, il vous est possible d'enregistrer l'emprunt (fingerprint) fournit par le serveur distant. Dans le cas où celle-ci serait modifiée, vous seriez immédiatement prévenu. Cela peut découler de quatre choses :

* Vous vous êtes fait pirater et l'on a modifié les clefs présentes dans votre known_hosts.
* Le serveur distant c'est fait pirater et la valeur de ses clefs a changé.
* La troisième peut correspondre à une attaque en bon et due forme d'un man-in-the-middle.
* La dernière et néanmoins plus plausible des solution nécessite que l'administrateur du serveur distant ait changé les clefs.

La seule solution fiable demande de contacter l'administrateur en question et lui demander ce qu'il en est. Dans la pratique, peu de personnes usent de cette assurance de sécurité.

<div class="code">
 $ ssh 127.0.0.1

 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 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 also possible that the RSA host key has just been changed.
 The fingerprint for the RSA key sent by the remote host is
 8b:d5:26:a3:79:ed:25:0f:3b:6f:fe:30:1f:ed:89:ae.
 Please contact your system administrator.
 Add correct host key in /home/jop/.ssh/known_hosts to get rid of this message.
 Offending key in /home/jop/.ssh/known_hosts:13
 RSA host key for 127.0.0.1 has changed and you have requested strict checking.
 Host key verification failed.
 $
</div>

== La copie sécurisée ==

Comme nous avons pu le voir plus haut, ssh fournit un outil de copie sécurisée en standard, sous le nom de scp pour '''SecureCoPy'''. Il remplace son ancêtre rcp. Son usage est très simple :

<div class="code">scp hôte_d_ou_je_veux_copier:source_copie hôte_destination:cible
</div>

Lorsque l'hôte correspond à la machine où vous vous trouvez, il n'est pas nécessaire de l'inscrire.

<div class="code">
 $scp iptables scipc-jpg:/home/jop/download

 iptables 100% |*****************************| 27654 00:00 
</div>

Vous pouvez également faire des copies récursives, comme nous le ferions avec n'importe quel autre utilitaire de copie.

<div class="code">
 $scp -r download scipc-jpg:/home/jpg/dl

 img2.png 100% |*****************************| 277 00:00 
 internals.pl 100% |*****************************| 188 00:00 
 labels.pl 100% |*****************************| 271 00:00 
 images.pl 100% |*****************************| 624 00:00 
 portscanning.css 100% |*****************************| 891 00:00 
 index.html 100% |*****************************| 56753 00:00 
</div>

== Le transfert de fichier sécurisé ==

Tout comme on peut copier des fichiers à distance par l'intermédiaire de scp, il est également possible de transférer des fichiers par l'intermédiaire d'un ftp sécurisé nommé '''SecureFTP'''.<br /> Bien que l'outil soit encore trivial (pas de reprise de chargement en cas de coupure, pas d'indication du temps restant, pas de telechargement ou de chargement réccursif, ...), il vous permettra de faire toutes les manipulations basiques disponibles sur un ftp non sécurisé.

Commandes disponibles sur '''sftp''' :

{|
| <tt>cd path <br /> lcd path<br /> chgrp grp path<br /> chmod mode path<br /> chown own path<br /> help<br /> get remote-path [local-path]<br /> lls [ls-options [path]]<br /> ln oldpath newpath<br /> lmkdir path<br /> lpwd<br /> ls [path]<br /> lumask umask<br /> mkdir path<br /> put local-path [remote-path]<br /> pwd<br /> exit<br /> quit<br /> rename oldpath newpath<br /> rmdir path<br /> rm path<br /> symlink oldpath newpath<br /> version<br /> !command<br /> !<br /> ?<br /></tt>
| Change le répertoire distant vers 'path'<br /> Change le répertoire local vers 'path'<br /> Change le groupe de fichier 'path' par 'grp'<br /> Change les permissions du fichier 'path' à 'mode'<br /> Change le propriétaire du fichier 'path' par 'own'<br /> Affiche ce message d'aide<br /> Télécharge le fichier<br /> Affiche le listing du répertoire local<br /> Crée un lien symbolique du fichier distant<br /> Crée un répertoire local<br /> Affiche le répertoire courant<br /> Affiche le listing du répertoire distant<br /> Positionne l'umask local à 'umask'<br /> Crée le répertoire distant<br /> Charge le fichier<br /> Affiche le répertoire courant distant<br /> Quitte sftp<br /> Quitte sftp<br /> Renomme le fichier distant<br /> Supprime le répertoire distant<br /> Supprime le fichier distant<br /> Crée un lien symbolique du fichier distant<br /> Affiche la version de sftp<br /> Exécute la 'commande' dans un shell local<br /> Sort vers un shell local<br /> Affiche ce message d'aide<br />
|}

<div class="code">
 $ sftp jop@scipc-jpg

 Connecting to scipc-jpg...
 $sftp> lpwd
 Local working directory: /home/jop
 $sftp> lcd download
 $sftp> lpwd
 Local working directory: /home/jop/download
 $sftp> put iptables
 Uploading iptables to /home/jop/iptables
 $sftp> quit
 $
</div>

== Le tunnel et le Xforwarding ==

Tout au long de cet article, vous avez pu découvrir des applications connues, il nous manque cependant l'exportation des applications distantes. En effet, à l'aide de telnet, vous pouviez utiliser un logiciel non présent sur votre machine, mais présent sur l'ordinateur distant. Il suffisait de taper :

<div class="code">$export DISPLAY=mon_adresse:0.0
</div>

Comme par magie, l'application arrivait plus ou moins rapidement selon votre connexion sur votre écran. C'est ce qu'on appelle du '''Xforwarding'''. L'avantage une fois de plus d'utiliser ssh réside dans la connexion chiffrée et l'impossibilité à un agresseur éventuel de lire ce que vous faîtes via le réseau.

<div class="code">$ssh jop@scipc-jpg gedit
</div>

Dans l'exemple donné, nous demandons d'ouvrir la connexion ssh pour inscrire Gedit à l'intérieur (bloc-notes de Gnome). En fermant Gedit, nous fermerons la connexion ssh.<br /> Pour que cela soit réalisable, n'oubliez cependant pas d''''activer l'option X11Forwarding '''dans les fichiers de configuration.

Toujours dans la même idée de tunneler des applications, ssh vous permet d'encapsuler des protocoles. Cela est très intéressant lorsque vous avez recours à des protocoles tels que smtp, pop, ... Vous courriers, pour l'exemple, ne serons plus à l'indiscrétion de vos fournisseurs, ni des fouines du réseau.

<div class="code">ssh -L port_local:hôte_distant:port_distant nom_utilisateur@nom_hôte
</div> 
Mettons que je veuille encapsuler les ports 25 (smtp) et 110 (pop) 
<div class="code">
 $ssh -L 2025:scipc-jpg:25 jop@scipc-jpg 
 $ssh -L 2110:scipc-jpg:110 jop@scipc-jpg
</div>

Il vous suffit de configurer votre logiciel de messagerie favori aux ports 2025 pour le smtp et 2110 pour le pop pour recevoir correctement votre courrier, et ce de manière sécurisée.

== Autre implémentation du protocole ==

Openssh est l'implémentation la plus connue, mais n'est pas la seule. On peut également utiliser :
* [http://www.lysator.liu.se/~nisse/lsh/ Lsh], une version GNU
* [http://matt.ucc.asn.au/dropbear/dropbear.html Dropbear], un serveur dédié à l'embarqué
* [http://twistedmatrix.com/projects/conch/ Conch], une implémentation en python


== Où se trouve quoi ? ==

Le paquet '''OpenSSH '''fournit : /etc/ssh<br /> /etc/ssh/moduli<br /> /usr/bin/scp<br /> /usr/bin/ssh-keygen<br /> /usr/libexec/openssh<br /> /usr/libexec/openssh/ssh-keysign<br /> /usr/share/doc/openssh-3.5p1<br /> /usr/share/doc/openssh-3.5p1/CREDITS<br /> /usr/share/doc/openssh-3.5p1/ChangeLog<br /> /usr/share/doc/openssh-3.5p1/INSTALL<br /> /usr/share/doc/openssh-3.5p1/LICENCE<br /> /usr/share/doc/openssh-3.5p1/OVERVIEW<br /> /usr/share/doc/openssh-3.5p1/README<br /> /usr/share/doc/openssh-3.5p1/README.privsep<br /> /usr/share/doc/openssh-3.5p1/README.smartcard<br /> /usr/share/doc/openssh-3.5p1/RFC.nroff<br /> /usr/share/doc/openssh-3.5p1/TODO<br /> /usr/share/doc/openssh-3.5p1/WARNING.RNG<br /> /usr/share/man/man1/scp.1.gz<br /> /usr/share/man/man1/ssh-keygen.1.gz<br /><br /> Le paquet '''OpenSSH-client''' fournit :<br /> /etc/ssh/ssh_config<br /> /usr/bin/sftp<br /> /usr/bin/slogin<br /> /usr/bin/ssh<br /> /usr/bin/ssh-add<br /> /usr/bin/ssh-agent<br /> /usr/bin/ssh-keyscan<br /> /usr/share/man/man1/sftp.1.gz<br /> /usr/share/man/man1/slogin.1.gz<br /> /usr/share/man/man1/ssh-add.1.gz<br /> /usr/share/man/man1/ssh-agent.1.gz<br /> /usr/share/man/man1/ssh-keyscan.1.gz<br /> /usr/share/man/man1/ssh.1.gz<br /> /usr/share/man/man5/ssh_config.5.gz<br /><br /> Le paquet '''OpenSSH-server '''fournit :<br /> /etc/pam.d/sshd<br /> /etc/rc.d/init.d/sshd<br /> /etc/ssh<br /> /etc/ssh/sshd_config<br /> /usr/libexec/openssh/sftp-server<br /> /usr/sbin/sshd<br /> /usr/share/man/man5/sshd_config.5.gz<br /> /usr/share/man/man8/sftp-server.8.gz<br /> /usr/share/man/man8/sshd.8.gz<br /> /var/empty/sshd<br /> Les documentations sont répertoriées en bordeaux Les fichiers de configuration en vert Les exécutables en bleu

== Conclusion ==

Georges Orwell écrivait 1984 bien des années plus tôt et nommait un ennemi invisible Big Brother en avançant le slogan « ''Big Brother is watching you'' ». Non loin de cette réalité, nous avons atteint avec Internet l'ouverture de l'outil informatique aux masses. Ne pouvant être en mesure de s'assurer que personne ne s'introduit dans votre intimité, le conseil reste d'être prudent avec vos données sensibles et personnelles. Oubliez donc les vieux protocoles non sécurisés et travaillez en toute sécurité...

== Bibliographie ==

=== RFC ===

'''[http://www.eisti.fr/res/res/rfc854/854.htm Telnet] - numéro 854 '''<br />'''[http://www.ietf.org/html.charters/secsh-charter.html  SSH] - Groupe de travail IETF '''<br />'''[http://www.linux-france.org/prj/edu/archinet/SECU/ssh.pdf SSH - SCP - SFTP] - Alix Mascret '''<br />'''[http://okki666.free.fr/docmaster/articles/linux123.html Secure Shell] - Denis Bodor'''<br />'''[http://www.via.ecp.fr/~alexis/formation-linux Formation Linux Debian] - Alexis de lattre'''<br />

=== Logiciel ===

'''[http://www.openssh.org OpenSSH - Secure Shell ]'''<br />'''[http://www.openssl.org OpenSSL -- Secure Socket Layer]'''<br />'''[http://www.ethereal.com Ethereal - sniffeur]'''<br />'''[http://www.openoffice.org OpenOffice.org - suite bureautique]'''<br />'''[http://www.gimp.org The gimp - Traitement d'image]'''<br />'''[http://www.ipso-facto.demon.co.uk/ksnapshot/index.html Ksnapshot - Impression d'écran]'''<br />

Je remercie tout particulièrement [[Utilisateur:Ennael|Anne]] pour le temps qu'elle a passé à la relecture de cet article ainsi qu'à sa correction et sa mise en forme.


<br/>
<br/>
'''<b>[[Sécurité et vie privée|@ Retour à la rubrique Sécurité et vie privée]]</b>'''
<br/>

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Jean-Philippe Gaulier le 01/17/2003.</div>

= Copyright =
Copyright &copy; 01/17/2003, Jean-Philippe Gaulier
{{FDL}}

[[Category:Sécurité et vie privée]]