<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>4. La solution sécurisée : percer en utilisant ssh</title><link href="style.css" rel="stylesheet" type="text/css"><meta content="DocBook XSL Stylesheets V1.70.1" name="generator"><link rel="start" href="index.html" title="Petit guide du perçage de pare-feux"><link rel="up" href="index.html" title="Petit guide du perçage de pare-feux"><link rel="prev" href="ar01s03.html" title="3. Compréhension du problème"><link rel="next" href="ar01s05.html" title="5. La solution non sécurisée : percer en utilisant telnet"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">4. La solution sécurisée : percer en utilisant ssh</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ar01s03.html">Précédent</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ar01s05.html">Suivant</a></td></tr></table><hr></div><div class="sect1" lang="fr"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10231"></a>4. La solution sécurisée : percer en utilisant ssh</h2></div></div></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N10234"></a>4.1. Principe</h3></div></div></div><p> Considérons que votre administrateur de pare-feu autorise les connexions TCP transparentes vers un port quelconque sur un serveur de l’autre côté du pare-feu (que ce soit le port du ssh normal, le 22, un autre port de destination, tel que le port http, le 80, ou autre), ou que vous vous débrouillez d’une façon ou d’une autre pour qu’un port quelconque d’un côté du pare-feu soit redirigé vers un port de l’autre côté (en utilisant <span><strong class="command">httptunnel</strong></span>, <span><strong class="command">mailtunnel</strong></span>, un tunnel sur le <span><strong class="command">telnet</strong></span>, ou autre). </p><p> Vous pouvez alors lancer un <span><strong class="command">sshd</strong></span> sur le port côté serveur, et vous y connecter avec un <span><strong class="command">ssh</strong></span> sur le port côté client. Des deux côtés de la connexion <span><strong class="command">ssh</strong></span> vous lancez des émulateurs d’IP ( <span><strong class="command">pppd</strong></span>), et là vous avez votre VPN, réseau privé virtuel, qui évite les restrictions stupides du pare-feu, avec un bonus en plus : la confidentialité grâce au cryptage (faites attention, l’administrateur du pare-feu connaît tout de même l’autre bout du tunnel, et toute information d’authentification quelle qu’elle soit que vous pouvez avoir envoyée avant de lancer le <span><strong class="command">ssh</strong></span>). </p><p> Exactement la même technologie peut être utilisée pour construire un VPN, réseau privé virtuel, qui permet de regrouper de façon sécurisée des sites physiques en un seul réseau logique sans sacrifier la sécurité au niveau du réseau de transport entre les sites. </p></div><div class="sect2" lang="fr"><div class="titlepage"><div><div><h3 class="title"><a name="N1025D"></a>4.2. Exemple de session</h3></div></div></div><p> Ci-dessous se trouve un exemple de script que vous pouvez adapter à vos besoins. Il utilise le système de rangée de <span><strong class="command">zsh</strong></span>, mais vous pouvez l’adapter facilement à votre shell favori. Utilisez l’option <span><strong class="command">-p</strong></span> pour que <span><strong class="command">ssh</strong></span> essaie un autre port que le port 22 (mais à ce moment-là, veillez à bien lancer <span><strong class="command">sshd</strong></span> sur le même port). </p><p> Notez que le script suppose que <span><strong class="command">ssh</strong></span> peut s’ouvrir sans que vous ayez à taper interactivement votre mot de passe (en effet, son tty de contrôle sera connecté à <span><strong class="command">pppd</strong></span>, alors s'il vous demande un mot de passe, c’est raté). Ceci peut se faire soit avec les clefs ssh dans votre <code class="filename">˜/.ssh/authorized_keys</code> pour lesquelles un mot de passe n'est pas nécessaire, ou que l'on peut débloquer en utilisant <span><strong class="command">ssh-agent</strong></span> ou <span><strong class="command">ssh-askpass</strong></span>. Regardez votre documentation sur ssh. En fait vous pourriez aussi utiliser un script de chat pour entrer votre mot de passe, mais ce n’est assurément <span class="emphasis"><em>pas</em></span> la chose à faire. </p><p> Si vous n’êtes pas <span><strong class="command">root</strong></span> ou simplement si vous voulez protéger le réseau de votre client des connexions sortantes, vous pouvez utiliser <span><strong class="command">slirp</strong></span> au lieu de <span><strong class="command">pppd</strong></span> comme émulateur PPP du serveur. Il n’y a qu’à décommenter la ligne appropriée. </p><p> <pre class="programlisting"> #!/bin/zsh -f SERVER_ACCOUNT=root@server.fqdn.tld SERVER_PPPD="pppd ipcp-accept-local ipcp-accept-remote" #SERVER_PPPD="pppd" ### Ceci suffit normalement si c’est dans /usr/sbin/ #SERVER_PPPD="/home/joekluser/bin/slirp ppp" CLIENT_PPPD=( pppd silent 10.0.2.15:10.0.2.2 ### Si vous voulez tester décommentez les lignes suivantes: # updetach debug ### Une autre option potentiellement utile (allez voir la section sur le routage)&nbsp;: # defaultroute ) $CLIENT_PPPD pty "ssh -t $SERVER_ACCOUNT $SERVER_PPPD" </pre> </p><p> Notez que les options par défaut de votre <code class="filename">/etc/ppp/options</code> ou <code class="filename">˜/.slirprc</code> peuvent casser ce script, enlevez donc toute option non désirée. </p><p> Notez également que <code class="literal">10.0.2.2</code> est le paramétrage par défaut pour <span><strong class="command">slirp</strong></span>, ce qui peut ne pas fonctionner avec votre installation particulière. En tout cas, vous devriez de préférence utiliser une adresse dans l’une des catégories réservées par la RFC-1918 pour les réseaux privés : <code class="literal">10.0.0.0/8</code>, <code class="literal">172.16.0.0/12</code> ou <code class="literal">192.168.0.0/16</code>. Il se pourrait que le réseau local protégé par pare-feu utilise certaines d’entre elles et il est de votre responsabilité d’éviter les conflits. Pour une plus grande personnalisation, lisez la documentation appropriée. </p><p> Si le <span><strong class="command">pppd</strong></span> de votre client est vieux ou non-linux (par exemple BSD) et n’a pas d’option <span><strong class="command">pty</strong></span>, utilisez : <pre class="programlisting"> cotty -d -- $CLIENT_PPPD -- ssh -t $SERVER_ACCOUNT $SERVER_PPPD </pre> Pièges : ne mettez pas les commandes données à cotty entre guillemets, car elles s’exécutent <span><strong class="command">exec()</strong></span>telles quel, et n’oubliez pas de spécifier le chemin complet pour le <span><strong class="command">pppd</strong></span> du serveur s’il n’est pas dans le chemin standard installé par <span><strong class="command">ssh</strong></span>. </p><p> On laisse au lecteur la reconnexion automatique (conseil : l’option <span><strong class="command">nodetach</strong></span> de <span><strong class="command">pppd</strong></span> pourrait être utile pour ça). </p></div></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ar01s03.html">Précédent</a> </td><td align="center" width="20%"> </td><td align="right" width="40%"> <a accesskey="n" href="ar01s05.html">Suivant</a></td></tr><tr><td valign="top" align="left" width="40%">3. Compréhension du problème </td><td align="center" width="20%"><a accesskey="h" href="index.html">Sommaire</a></td><td valign="top" align="right" width="40%"> 5. La solution non sécurisée : percer en utilisant telnet</td></tr></table></div></body></html>
