Tunnels TCP via SSH, putty etc

closeCet article a été publié il y a 15 ans 1 mois 2 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Salut,
Je reprends cette doc écrite il y a 5 ans et anciennement disponible en bon gros HTML-vi-powered dispo ici : https://michauko.org/blog/2009/02/23/tunnels-tcp-via-ssh-putty-etc/
Les photos d’écrans datent de l’époque. Mais comme le concept n’a pas bougé…. et l’interface de PuTTY très peu aussi….

Let’s go
En relisant l’article, je vois que c’était vraiment vulgarisé pour être accessible au plus grand nombre, pardonnez donc les imprécisions techniques et le baratin simplifié – MERCI


J’ai écrit ce document pour 2 raisons. La première est que j’en ai marre d’expliquer sans cesse à mes amis cette méthode, la deuxième est que c’est vraiment une méthode très pratique, puissante et qui n’a que quelques limitations (et encore – voir chapitre à venir : VPN sur SSH).

1. Avez-vous besoin de SSH au boulot ?

Vous êtes 8h par jour au boulot et le proxy chargé de la sécurité de l’entreprise se charge surtout de vous bloquer quelques sites web et quelques protocoles réseaux à priori non professionnels. En gros, il vous emmerde à longueur de temps et vous aimeriez pouvoir faire les choses suivantes depuis votre boulot :

  • Lire vos mails en POP, IMAP (par un client mail classique plutôt que via le web et l’interface nullissime de votre fournisseur).
  • Utiliser Jabber, ICQ, MSN (ou autre protocole) depuis le boulot pour pouvoir rester en contact avec belle-maman.
  • Prendre le contrôle à distance (VNC, pcAnywhere etc) de votre PC perso avec sa ligne ADSL pour faire je ne sais quoi. D’autant plus que des outils comme VNC ne gèrent tout simplement PAS les proxys.
  • Suivre les résultats du football ou consulter un site d’actualités – en général le proxy bloque largement les sites foot, jeux, facebook et bien d’autres.
  • et plein d’autres choses encore…

Dans ce document, je présenterai le concept ainsi que la mise en oeuvre de la solution (sous Linux ou Windows).

2. Principe général

SSH est un outil qui permet de se connecter à une machine distante en mode texte. Sous Linux, on accède à un shell, sous Windows, on pourra voir ça comme l’accès à une fenêtre DOS, à priori pas très utile, certes. Ca ressemble donc de loin à une connexion telnet, sauf que c’est laaaaargement plus sécurisé (je n’en débattrai par ici mais vous pouvez me croire sur parole) et beaucoup plus puissant.
SSH permet notamment de faire du transfert de fichiers (SFTP) et surtout, des tunnels de communication, dans les deux sens (vous comprendrez plus tard). Un tunnel va servir à encapsuler (capturer) des flux réseaux entre le SSH client (votre PC en entreprise avec accès web restreints qu’on veut contourner) et votre serveur SSH (votre PC à la maison avec ADSL branché 24/24).

Tout se résume à ça : le client SSH établit une connexion avec le serveur SSH à travers le proxy en utilisant une connexion autorisée par le proxy (méthode CONNECT vers un port autorisé). Ensuite, grâce à ça, des tunnels vous permettront de faire passer presque n’importe quoi à travers le proxy (voir chapitre 4 sur les limitations de ce système).

Le client SSH que j’utilise est putty (premier lien sur google), c’est un client libre, gratuit etc, qui permet de faire du telnet, du ssh et surtout d’utiliser les fonctionnalités de ssh, les tunnels par exemple. Il sait aussi se connecter à travers un proxy.

3. Mise en place

3.1. Côté serveur SSH

Chez vous, il faut d’abord installer un serveur SSH.

3.1.1. Installation

Sous Linux, vous trouverez forcemment un paquet correspondant à votre distribution. Exemple sous Debian, tapez « apt-get install ssh » et ça devrait le faire.

Sous Windows, c’est moins simple. Je ne connais pas d’implémentation libre directement fonctionnelle sous Windows. Et comme vous n’allez quand même pas payer la version payante de www.ssh.com, vous devrez utiliser www.cygwin.com pour installer un « environnement Linux dans votre Windows ». Cet environnement comprend ensuite la plupart des outils Linux, dont OpenSSH bien sûr. Deux options (au moins) s’offrent à vous :

  • Installer cygwin de manière classique avec ce qu’il faut, notamment le paquet ssh (il vous faudra lire un peu de doc à priori).
  • Utiliser le projet sshwindows qui propose un programme d’installation global comprenant un cygwin minimaliste et sshd associé. Je n’ai pas testé personnellement cette solution.

Présentation barbare de l’installation de cygwin : dans les grandes lignes, vous téléchargez le setup.exe puis vous choisissez un miroir de téléchargement, vous installez le minimum vital (par défaut je crois) et vérifiez bien que le paquet ssh est inclus. Au final, vous obtenez une sorte de raccourci façon « fenêtre DOS », sauf que vous êtes dans un environnement Linux et disposez de sa panoplie d’outils en ligne de commande et même graphique si vous cherchez bien (pour peu que vous ayez installé les paquets qu’il faut).

3.1.2. Génération des clefs

Si vous ne connaissez pas le principe d’authentification par clefs de SSH, sachez juste que vous devez générer une paire de clefs cryptées utilisées pour la communication entre le serveur et les clients. Même si dans ce document je ne vais pas détailler l’authentification par clefs, mais juste par mot de passe, cette paire de clefs est nécessaire pour l’identification du serveur et pour les premières étapes de l’établissement de la connexion (par mot de passe).
Si vous avez installé SSH sous Debian, le programme d’installation génère automatiquiment les clefs, pour les solutions, je ne sais pas. Sous cygwin par exemple, vous devrez donc générer ces clefs via la commande « ssh-keygen -t dsa ». Vous pourrez voir ces clefs dans « /etc/ssh », les fichiers sont ssh_host_dsa_key*.

3.1.3. Etape supplémentaire pour Cygwin

Un détail sous cygwin (encoooooore), il faut que vous lisiez les docs pour savoir comment lancer le serveur SSH en tant que service Windows plutôt qu’à la main le matin en partant au boulot… (cherchez des infos sur le programme cygrunsrv.exe). Pour la version « packagée » par le projet sshwindows, je ne sais pas, lisez la doc.

Sous Linux, ce sera forcemment fait automatiquement.

3.1.4. Changement du port du serveur SSH

SSH tourne sur le port 22 par défaut et vous pouvez être quasimment sûr que le proxy du boulot bloque ce port. Donc vous ne pourrez pas atteindre votre serveur depuis chez vous. Ajoutez donc dans le fichier de configuration de sshd (/etc/ssh/sshd_config) une ligne « Port 443 » après la ligne « Port 22 » ou remplacez cette dernière. Redémarrez le service. On choisit le port 443 car c’est le port https par défaut et le proxy du boulot tolèrera forcemment ce port (au pire, prenez le port 80, http). De plus, https et SSH présentent des similitudes (la couche SSL) et donc utiliser le port 443 a l’avantage d’être plus discret (voir chapitre 4.2.).
Si votre firewall le tolère, vous pouvez aussi faire un forward du port 443 vers le 22 en ne laissant que la ligne « Port 22 » dans sshd_config.

3.1.5. Votre firewall

Enfin, vous avez certainement chez vous un firewall, n’oubliez pas d’ouvrir le port 443 ou 22 (voir chapitre précédent).
Vous avez très probablement aussi une adresse IP dynamique et donc il faut que vous vous trouviez un nom de domaine (essayez www.dyndns.org, ils ont un service gratuit et vous aurez un nom du style chezmoi.dyndns.org mis à jour à chaque reconnexion de votre ADSL). Sinon, vous devrez récupérer votre adresse IP tous les matins et priez pour que l’ADSL ne tombe pas auquel cas vous risqueriez de changer d’IP.

Je suppose maintenant que votre serveur est lancé, accessible depuis l’extérieur et qu’il fonctionne correctement.

3.2. Côté client SSH

3.2.1. Récupération des paramètres proxy

Pour les utilisateurs d’Internet Explorer, allez dans Outils -> Options Internet -> Connexions -> Paramètres réseaux. Vous aurez 2 possibilités, soit l’adresse et le port sont directement écrit :

tunnel1

Soit votre entreprise utilise un script d’autoconfiguration :

tunnel2

Dans ce dernier cas, téléchargez ce script en recopiant l’adresse dans votre navigateur. Ouvrez-le, c’est un fichier texte. C’est simple à comprendre et en général, les dernières lignes vous donnent le proxy qui permet d’atteindre les sites extérieurs (Internet). La fin ressemble à quelque chose comme « PROXY host:port ».

Si vous utilisez un autre navigateur (je l’espère pour vous ;), vous saurez sûrement où trouver ces informations.

3.2.2. Installation de putty (client SSH)

Téléchargez putty. Il n’y a pas d’installation, pas besoin d’être admin de son poste. Vous n’avez besoin que de putty.exe sinon prenez le zip qui contient tous les binaires. Le paramétrage se fait comme suit :
tunnel3

Vous saisissez dans le menu « Session » l’adresse du PC chez vous (IP ou DNS), précisez le protocole SSH et modifiez le port où tourne le serveur SSH (443 à priori – voir chapitres précédents).

tunnel4

Dans le menu « Connection », activez l’envoi de paquets vides réguliers, toutes les 10 secondes par exemple. La connexion SSH se faisant via la méthode CONNECT (comme pour du https), le proxy risque fort de la couper régulièrement si aucun trafic n’est généré.
tunnel5

Dans le menu « Proxy », vous indiquez le type de proxy, à priori HTTP, son adresse, son port et l’utilisateur/mot de passe si besoin. La ligne « telnet command » représente en gros le début de la communication entre putty et le proxy pour permettre la connexion au serveur distant (le PC chez vous). Tentez la ligne suivante : « connect %host %port HTTP/1.1\nHost: %host » si la ligne par défaut ne fonctionne pas.

tunnel6

Enfin, dans le menu « SSH », vous précisez que vous utilisez le protocole en version 2 et activez la compression – c’est toujours ça de gagné.

Retournez dans le menu « Session », donnez un nom à votre session et faites « Save » à nouveau. Puis « Open ».

3.2.3. Le moment de vérité

Faites « Open », si tout va bien, vous obtiendrez un écran du genre :
tunnel7

Connectez vous et ça roule. Dans les autres cas, vérifiez bien les informations saisies et éventuellement changez le type de proxy. Parmi les 25 entreprises que j’ai pu visiter (grandes multinationales comprises), seules 2 ont refusé cette connexion, la première car le proxy était un logiciel merdico-archaïque de Microsoft qui avait déjà du mal à fonctionner normalement avec IE, la deuxième car le proxy était buggé et avait l’air de ne pas respecter le protocole « normal » entre putty et le serveur ssh (d’après les traces que j’ai analysées, le serveur SSH était atteint puis tout partait n’importe comment).

A ce niveau là, si la connexion est établie et que vous pouvez accéder à votre machine, c’est banco, vous pourrez « tuyauter » n’importe quoi via SSH 🙂

3.3. Les tunnels

3.3.1. Créer un port mapping

Dans le menu « Tunnels », créez un tunnel vers vos serveurs de messagerie (ATTENTION, lisez le chapitre 4.1.3 à propos du forward de messagerie) :

tunnel8

Cette fois-ci, lorsque la fenêtre putty sera ouverte et que vous serez signé sur le serveur SSH, il y aura eu création d’un port mapping du port local 10110 du poste client vers le port 110 du serveur POP de votre provider (le tout via le relai SSH ;). Idem pour les ports 10025/smtp:25. J’ai choisi des numéros de ports locaux (10110 et 10025) différents des vrais ports notamment pour la compréhension. Rien (ou presque) ne vous empêcherait de mapper les port 25 et 110 vers les ports 25 et 110 des serveurs POP et SMTP de monprovider.com.

Ca veut dire que si un programme de messagerie (mozilla, thunderbird, outlook express, lotus notes etc) s’adresse à votre propre machine (localhost) sur le port 10025, c’est bien le serveur SMTP de monprovider.com:25 qui répondra. Idem pour le port 10110/110, c’est le serveur POP qui répondra. A partir de là, configurez votre client mail en indiquant que les serveurs POP et SMTP de monprovider.com sont respectivement localhost (sur port 10110) et localhost (sur port 10025).
Lorsque le client mail fera une requête, c’est putty qui interceptera la communication et dira au serveur d’effectuer la requête à partir de l’autre bout du tunnel vers le serveur:port précisé. Et voilà ! (j’espère que c’est clair 😉

Attention : vérifiez bien que votre client mail n’utilise aucun proxy pour les connexions locales ! (exemple : « outlook express » utilise la configuration de IE, veillez bien à cocher dans IE la case qui précise de ne « pas utiliser de proxy pour les connexions locales », ça devrait être fait par défaut).

Avec un beau schéma, ça donne ça :
tunnel9
Maintenant que vous savez faire ça, vous pouvez mapper n’importe quoi et vous coimprendrez rapidement que le port mapping n’est pas la solution pour tous les problèmes. Exemple, si vous voulez faire de l’IRC, le serveur que vous joindrez ne sera pas toujours le même suivant les réseaux que vous voulez utiliser.

3.3.2. Tunnel dynamique (pour ICQ par exemple)

La limitation des port mapping apparaît rapidement car il faut définir absolument toutes les connexions dont vous avez besoin, ce qui peut être très lourd. Imaginez que vous vouliez mapper certains sites web interdits, comme www.pleindetrucsinterdits.com. Vous n’avez qu’à créer un port mapping du style « localhost:12345 -> www.pleindetrucsinterdits.com:80 ». Ca fonctionne – pas dans tous les cas à cause des « virtual hosts » (Merci Toine) – mais il ne faut pas avoir 50 sites à mapper sinon c’est l’enfer.

Une autre limitation est que vous ne pouvez tout simplement pas de cette manière vous connecter à certains services comme ICQ par exemple : en effet, vous pourriez faire un port mapping vers le serveur d’authentification login.icq.com:5190 par exemple, mais le reste de la communication ne se fera pas car il y a ensuite tout un tas de ports dynamiques alloués qui entrent en jeu. Impossible donc.

La solution est le mapping dynamique. En gros, vous créez un port d’écoute (port 1080 dans la suite du texte) qui se charge de prendre toute trame réseau qui rentre telle quelle et de la « faire exécuter » depuis l’autre bout du tunnel. Ca ressemble à un proxy n’est-ce pas ? En effet, c’est bien un service que l’on utilise pour contacter n’importe quel site/port inaccessible depuis le réseau où l’on est. C’est pas beau ça ?
Ca veut notamment dire que dans l’application qui doit utiliser ce « proxy », vous devez préciser que le nouveau proxy est localhost:1080 et non pas le proxy de l’entreprise.

Dans putty, créez un tunnel « Dynamic » sur le port 1080 par exemple :

tunnel10

Ca donne ça :

tunnel11

Et globalement, on peut donc schématiser ça comme ça :

tunnel12

ATTENTION : une fois ce système mis en place, n’oubliez pas de dire à l’application concernée que le proxy pour sortir n’est plus le proxy de l’entreprise mais le « proxy » de type SOCKS 4 (si vous avez besoin de le préciser) situé sur localhost, port 1080 ! Pigé ?

(MAJ 2009)
Si vous n’arrivez pas à faire utiliser ce proxy à votre navigateur, pourquoi ne pas installer un vrai proxy sur votre serveur relai et le mapper via un tunnel normal ? (un « squid » local à votre serveur relai fera l’affaire)

3.3.3. Tunnel remote ? Ou comment exporter un serveur local (interne) vers l’extérieur

Enfin, sur l’interface de putty, vous avez peut-être remarqué une fonctionnalité inexplorée jusqu’à présent : les tunnels « remote », par opposition aux tunnels « locaux ». Ca permet non pas de mapper un port local vers un couple machine/port distant mais de faire l’inverse : mapper un couple machine/port local vers un port distant (sur la machine PC ADSL). Vous ne voyez pas à quoi ça peut servir ? Lisez la suite :

Attention : c’est mal de faire ça 🙂 car ça vous permet de rendre accessible un serveur d’Intranet (par exemple) à partir de votre machine extérieure (PC ADSL) et donc potentiellement accessible à tout le monde depuis le web si vous ne faites pas attention à votre configuration réseau !

4. Compléments d’informations

4.1. Limitations

4.1.1. Bande passante

Gardez à l’esprit que vous faites tout passer par la machine chez vous, certainement plus lente en débit que l’accès web de l’entreprise notamment pour l’upload (le retour de communication de votre PC ADSL vers putty). Donc si vous mappez des sites web interdits, ne vous étonnez pas si ça raaaaame, surtout si votre client favori de peer-to-peer tourne plein pot…

4.1.2. Jouer en réseau ?

Décidemment, votre boulot vous passionne… Bon désolé, c’est pas possible. La plupart des jeux en réseaux fonctionnent en mode non connecté (UDP) et c’est pas possible de relayer de l’UDP avec cette solution. Si vous voulez quand même, cherchez des infos sur un soft qui s’appelle ZeBeDee, j’avais pas eu le temps de creuser à l’époque.

(MAJ 2009) Sinon, pensez VPN, hamachi…

4.1.3. Remarques sur la messagerie

A propos du mapping vers des serveurs de messagerie, notez que les fournisseurs bloquent en général l’accès à leur propre SMTP si l’IP émettrice n’est pas sur une plage appartenant à l’opérateur. Pour éviter le spam d’inconnus. Donc évitez de passer par le SSH d’un copain ayant son accès web chez un autre fournisseur pour atteindre votre SMTP, ça risque de ne pas fonctionner. Exemple : vous voulez utiliser le SMTP de wanadoo en passant par une passerelle SSH chez Nerim.

Dans le même ordre d’idées, il faut en général faire du POP avant de pouvoir envoyer un mail, ça s’appelle pop before smtp me semble-t-il et c’est aussi fait pour s’assurer à peu près que l’adresse IP de l’émetteur du mail n’est pas un inconnu car il s’est authentifié par un login/password pour accéder au POP.

4.2. « Légalité » de la chose

Si vous avez peur qu’un gros baraqué de l’équipe réseaux débarque dans votre bureau en disant « qui c’est l’abruti qui fait du SSH ? », n’ayez pas peur.
Premièrement, la connexion au serveur SSH ne se traduit que par une ligne dans les logs du proxy, une ligne du style « CONNECT votrenom.dyndns.org:443 », exactement comme si vous vous connectiez au site https de votre banque. C’est même mieux vu qu’il n’y aura qu’une ligne alors que pour un vrai site web en http(s), il y a aura une ligne par ressource (image, page web etc).
Deuxièmement, au niveau volumétrie de données échangées, étudions l’exemple de la lecture de vos mails : on utilise grâce au tunnel SSH un protocole dédié à la lecture de mail et l’envoi (POP/SMTP). Ca consommera laaaaaaaargement moins de bande passante que de lire les même mails par l’interface web (bourrée de pubs par exempe). De plus, comme ça ramera moins que le chargement complet de pages web, vous mettrez moins de temps à lire vos mails.
Rassuré ?
Une nuance tout de même, si un psychopathe réalise qu’il s’agit de SSH sur port 443 et non de HTTPS, il devrait se poser des questions tout de même. Je n’ai pas encore rencontré de tels psychopathes.

Enfin, rappelez vous quand même la charte informatique que vous avez signée en rentrant dans votre entreprise.

4.3. Partage de tunnels ?

Si vous souhaitez faire profiter de votre tunnel un collègue qui tient absolument à suivre aussi le match de football bloqué par le proxy, regardez les options de putty/ssh pour permettr l’accès aux ports mappés depuis autre part que votre poste local. Exemple : votre collègue entrerait l’adresse ip de votre machine et un port mappé pour accéder à un site web particulier…

4.4. Bug dans putty

Je ne sais pas si ce bug est toujours d’actualité, mais à un moment donné, il fallait absolument mettre le tunnel dynamique en dernier dans la liste des tunnels, sinon il ne fonctionnait pas.

4.5. Transfert de fichier ?

Installez filezilla, il permet de faire du SFTP. Vous n’aurez pas besoin de tunnels SSH mais je tenais à signaler cet outil, libre, gratuit etc etc.
Il vous suffit de déclarer le proxy de l’entreprise dans les préférences puis de créer une connexion de type SFTP (changez le port en 443) et le tour est joué.

Sinon, sous Windows, le produit commercial « Total Commander » permet d’utiliser votre tunnel dynamique (SOCKS 4).

4.6. Méthodes alternatives

Si SSH ne vous plait pas (pauvre fou), vous pouvez toujours vous renseigner sur les outils suivants : httport, httptunnel (linux only je crois). Ils font un peu le même genre de choses, mais en laaaaaaaargement moins bien.
Les deux encapsulent votre trafic réseau dans des trames HTTP, c’est lourd, c’est lent etc. Le seul avantage de httport est que les éditeurs vous fournissent des serveurs (htthost) publics, donc pas besoin d’avoir un serveur relai chez vous ou chez un ami, mais ils rament, sauf si vous payez 😉 Quitte à mettre en place un outil pour faire relai, optez pour SSH !
(MAJ 2009)
A noter stunnel pour faire du tunnel SSL pur (si votre admin réseau a grillé votre communication SSH sur un port SSL…
(MAJ 2009)
Quelques liens récemment donnés par Toinator et que je n’ai pas creusé. Lui oui, c’est du lourd apparement.
Un bon gros guide :
http://dag.wieers.com/howto/ssh-http-tunneling/
sslh : en PERL (fixme : retrouver l’url)
sshl : le même recodé en C pour raisons d’optimisations

5. Remerciements

  • Toinator pour la relecture et quelques précisions, l’initiation à ce genre d’outils et le chapitre à venir sur le VPN over SSH, si on peut dire.
  • Mandraxe

45 comments

  1. Excellent article, j’utilise la redirection dynamique seulement la charge du processeur du serveur SSH distant monte assez vite si on commence à aller essayer de démarrer wine + steam + online game en TCP. Cette méthode à donc ses limites mais à le mérite de pouvoir passez à peu près partout.

    Il peut y avoir un petit hic avec la création du proxy http il faut parfois rajouter un user-agent car certain proxy bloque certains user-agent, c’est pourquoi on peut rajouter dans la ligne « Telnet command » :
    connect %host:%port HTTP/1.1\nUser-Agent:Mozilla/4.01 (compatible; MSIE 6.0; Windows NT 5.1)\nHost:%host\n

    En tout cas belle article complet 🙂

  2. Works perfectly!redirection dynamique

    Derrière un proxy transparent : IPTABLES (bien ficelé : le LAN peut faire du http/s, ftp)

  3. Salut,
    Si tu suis encore la discussion.

    Je serais curieux de savoir comment vous faites un proxy transparent pour le httpS (pas le http, mais bien le 443)
    Merci

  4. @michauko : je n’ai jamais tenté, techniquement parlant on établi déjà un tunnel SSH qui est encrypté, dans lequel on inclurais une autre encryption… Là faudrait être vraiment parano pour que quelqu’un sur la machine servant de serveur SSH aille capturer des trames http sur le localhost.

    Si tu trouve une réponse je serais heureux de la lire 🙂

  5. ok j’ai mal compris, je croyais qu’on parlait d’un proxy d’une entreprise qui actuellement tolérait le proxying transparent pour le https (ce qui n’est pas possible, je n’ai plus l’explication simple en tête, si qq1 a envie, n’hésitez pas)

  6. Slt michauko,

    Tu penses que si j’utilise pas comme toi le dyndns et plutot mon adresse IP ,on remonter chez moi et me griller?

  7. dans tous les cas, quelqu’un qui lit les logs verra un nom ou une IP (c’est en général plus louche d’ailleurs) associée à une connx CONNECT sur 443
    Si c’est une IP (dyndns ou non), on pourra tjs connaitre l’ip associée
    Ca change rien

    Par contre, quelques fois, les IP tapées en brut ne passent pas dans les proxy car le navigateur peut utiliser un fichier .PAC qui raisonne uniquement par nom, pas par IP

    Bref, ça changera pas grand chose, pour faire simple

  8. Salut
    Petite question. Ici (au taff) ils ont un filtre actif pour le web (WebWasher), CAD qu’il a une liste noir de site interdit et une liste « grise » qui demande si l’on veut vraiment acceder au site. Le truc c’est que même si l’on dit « OUI » une fois, au bout de 5 minutes d’inactivitée PAF il le redemande. Et donc tu imagine bien ce qu’il se passe de la connexion SSH … PAF aussi
    La seule « parade » que j’ai trouvé pour l’instant est d’avoir un navigateur ouvert et de faire rafraichir la page toute les 4 minutes (soit dans le code de la page soit par un plugin FF) … mais si tu as une autre idée je suis preneur

    @+

    1. Salut, si j’ai bien suivi, je dirais : est-ce que l’option genre « keepalive » dans putty, qui permet de balancer un paquet toutes les « x » secondes, ne serait pas une aide ?

  9. En effet cette option à l’aire de faire son office.
    Pour info elle se trouve dans « Connection » ou l’on peut mettre le nombre de seconde enter chaque paquet. Il y a deux autres option aussi
    « Diseable Nagle’s algorithm (TCP_NODELAY option) »
    « Enable TCP keepalives (SO_KEEPALIVE option »
    La première est cochée par défaut, j’ai cochée la deuxième au cas où.

  10. j’ai jamais eu besoin de changer ces 2 options
    je parlais juste du « secondes between keepalives (0 to turn off)
    Tu mets 60 et vois si ça le fait
    enfin du moment que tu trouves le bon réglage

  11. salut,
    moi j’ai un petit soucis j’obtiens une erreur de connexion au proxy avec putty
    Proxy error: 407 Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied. )
    Si vous avez une idée …
    Merci

    1. Je suppose qu’au premier lancement d’un navigateur, au premier accès web de la journée, il vous faut vous authentifier sur le proxy avec un login et passwd.
      Dans ce cas, il faut renseigner les champs adéquats dans putty

  12. oui on doit rentré un mot de passe, c’est ce que j’ai fait dans putty mais il ne veut toujours pas, je vais continuer à chercher de mon côté, si jamais quelqu’un à une solution …

  13. J’ai le même problème au boulot, avec le proxy ISA de Microsoft.
    J’ai essayé un peu toutes les chaînes trouvées, ça ne marche pas non plus.

    J’ai un nom d’utilisateur sur un domaine, ie mon login est de type DOMAIN\nom
    Est-ce qu’il faut faire quelque chose de spécial dans ces cas-là ?

    1. ‘sais pas
      J’avais eu une fois un problème avec ce proxy, mais c’était une vieille version de merde qui gérait mal la conversation, pour avoir sniffé l’échange et comparé
      Par contre, un user type DOM\usr ça doit passer pareil je pense

  14. hop hop hop
    – soit ton SSH écoute sur le 80, et là c’est mal. Faut au moins « que ça ressemble à du https, disons SSL », donc faire écouter (ou rediriger) ton 443 distant vers 22
    – soit tu me dis que le proxy de ta boite écoute sur le port 80 et on s’en fout royalement car c’est juste le port pour contacter le proxy. Ca pourrait être 12000. Souvent, c’est 3128 (squid)

  15. le proxy écoute bien sur le port 80
    configuration de putty le ssh est bien sur le 443, mon serveur ssh est configuré pour écouter à la fois sur le 22 et sur le 443, redirection du port 443 dans mon routeur sur le pc qui a le serveur

  16. ok
    Je vois pas pourquoi ça voudrait pas relayer vers du 443, un truc proche du https, pcqu’il tourne sur le 80 O_o.
    Par contre, sait-on jamais, y’a ptet une super fonction qui voit que le soit-disant trafic HTTPS s’avère être du SSH. Ca peut se faire (déjà en voyant la réponse standard du serveur SSH), mais c’est couteux. A ma connaissance, seules quelques appliances couteuses font ça.

    sinon tenter avec stunnel, là au moins c’est vraiment du SSL. On peut même le configurer pour qu’il détecte qu’on veut parler en SSH ou en HTTPS. De sorte que si c’est un outil qui cherche à voir si c’est pas un serveur SSH, il réponde par une vraie page HTTPS.
    Un ami a fait ça, j’ai pas eu le temps et surtout pas le besoin, donc j’ai pas fait d’article 🙂

  17. Salut,

    finalement, j’ai réussi à faire avec le proxy ISA de ma boîte.
    J’ai installé un serveur ntlmap sur ma machine (léger), et je l’ai configuré en rensiegnant le domaine, mon nom d’user, etc.
    Du coup, je lance ntlmap, ça se met sur un port particulier, et je configure mon navigateur pour qu’il utilise le proxy ntlmap plutôt que celui de ma boîte. Après, si j’ai bien compris, c’est le proxy ntlmap qui fait le lien avec le vrai proxy, etc.
    Résultat, j’ai maintenant Gmail au boulot, et j’ai pu désactiver buzz sans soucis…

    A+

  18. Salut,
    voilà j’ai enfin réussi en utilisant la méthode de ZR, j’ai installé ntlmap (http://ntlmaps.sourceforge.net/), j’ai configuré le fichier server.cfg en y mettant
    PARENT_PROXY => l’adresse du proxy de la boite
    PARENT_PROXY_PORT => le port du proxy de la boite
    NT_DOMAIN => le domaine de la boite (ce qu’il ya a gauche du « \ » pour l’autentification)
    USER => le nom d’utilisateur (ce qu’il ya à droite du « \ » pour l’authentification)
    Ensuite dans putty, dans la partie proxy :
    proxy type => HTTP
    proxy hostname => 127.0.0.1
    port => 5865
    telnet command => connect %host %port\n
    Il faut d’abord lancer ntlmap avec le .bat et ensuite utiliser putty

  19. salut,

    j’utilise cette méthode depuis quelques mois sans problème.

    Je souhaiterai maintenant me passer de ma connexion perso, et utiliser un shell, toujours sur le 443, du style bshellz.

    J’ai testé, et ça marche tout aussi bien, voir mieux, car ils donnent plus de bande passante que ma connexion adsl.

    A part bshellz, vous en auriez d’autres qui laisse le 443 ouvert pour le tunnel ssh ?

    Merci

  20. salut
    J’avoue que je connaissais pas bshellz ; encore moins d’autres du genre.
    Le seul truc que je suggère en cas de faible bande passante du relai (PC à la maison avec upload pourri), c’est de trouver un serveur : un copain, un mec qui a une fibre optique, n’importe. désolé

  21. Salut tout le monde,
    Je vous explique rapidement mon (léger) problème : j’aimerais récupérer des fichiers se trouvant sur un ordi distant tournant sous Linux. Je peux m’y connecter par SSH (en utilisant Putty), mais je ne connais pas les lignes de commande me permettant d’importer mes fichiers sur mon ordi (Windows) (j’arrive à les voir en faisant un « ls » mais je ne sais pas quoi faire ensuite). Si quelqu’un pouvait me dire comment faire, ça serait sympa…
    Merci d’avance

  22. Allez j’ai un nouveau défi pour vous.

    Je suis en entreprise, on a un filtrage de ports (seul 80 et 443 open), un filtrage très puissant sur le web (blogs, forums, téléchargements, proxy web…) et un proxy interne qui fait du DPI.

    J’ai installé un serveur SSH chez moi sur le port 443, je suis au bureau sur Putty, à tâtonnement j’ai pu trouver le port et l’adresse du proxy. Maintenant, Putty me répond : Proxy error: 407 Proxy Authentication Required. J’ai entré mes identifiants de réseau dans l’onglet proxy, ca ne donne rien. Mais au moins je sais que les autres infos sont bonnes.

    Les postes sont bridés par les GPO d’un Active Diretory et je n’ai donc pas accès à la conf d’IE, sauf en VM (bridged tout de même). Pas de C:, pas de System32, rien.

    Je viens d’apprendre que pour utiliser Internet dans les machines virtuelles du boulot il faut donner à la conf réseau de IE/Firefox un petit fichier script (qui n’est pas un .pac mais ici un .php, il contient du JavaScript, c’est la conf standard du proxy). J’ai récupéré le script complet, je l’ai testé il marche. Donc dans Firefox aucun soucis, je traverse, mais dans PuTTY ça coince.

    Je suppose maintenant que le proxy de l’entreprise est très intelligent et doit détecter la conformité du protocole circulant sur le port 443 (il interdit mon SSH à la place de SSL).

    Un blogueur (Olivier Cochard) propose d’encapsuler SSH dans SSL avec un multiplexeur « sslh » coté serveur, et soit par l’utilisation de « Shell in a box » soit par l’utilisation de stunnel.

    J’ai à ma disposition un Firefox portable et un Putty portable.

    Je suis preneur de la moindre idée =)

  23. Pas de smartphone 😀 Sinon j’aurais explosé ma limite à 200Mo tu penses bien ! Même lent c’est toujours mieux que TOR.

    Je cherche à foutre mon fichier « .pac » (qui est en php) quelque part dans Windows XP de manière à ce que toutes les applications soient comprises dans le proxy, et non plus individuellement comme je dois le faire. TOR non plus n’arrive pas à se logguer au proxy.

  24.  » Putty me répond : Proxy error: 407 Proxy Authentication Required »

    Et il n’y aurais pas une authentification NTLM par hasard ? Regarde les commentaires du 17 février au 9 septembre avec la mise ne place d’un proxy d’authentification NTLM entre ton PUTTY et le proxy de ta boite.
    Si le proxy de ta boite fait bien du DPI (ce qui est vraiment très rare), il faut bien que tu encapsule ton SSH dans du SSL …

  25. Si si effectivement, l’authentification bloque Putty. Du coup je fais de l’IP overs DNS avec iodine, ca marche du tonnerre. mais c’est très lent, limite pas viable pour le surf. Je m’en sert avec un client lourd pour jabber.

  26. Si le forum est toujours actif…..
    J’ai également une erreur de type 407 Proxy Authentication Required.
    J’ai installé ntlmap qui ne marche pas et cntlm ne se lance pas en service, automatiquement fermé…
    quelqu’un a-t-il une idée pour moi ?
    Merci par avance.

  27. Bonjour,
    Merci pour cet article. Il commence à dater un peu mais il n’as pas pris une ride, et en plus il est super simple à comprendre ! Merci beaucoup beaucoup 🙂

    J’en profite pour exposer un problème que j’ai concernant l’utilisation de serveurs proxy et dont je n’arrive pas à trouver de solution (peut-être que quelqu’un pourra m’aider).
    Voici le problème: certains logiciels nécessitant d’accéder à internet ne permettent pas de configurer un proxy pour sortir. Le proxy étant bien configuré au niveau du système (Windows), ils ne parviennent tout de même pas à récupérer les ressources dont ils ont besoin pour fonctionner, comme si la configuration système n’était même pas lue. Existe-il un moyen/une astuce/un logiciel permettant de forcer ces logiciels « non configurables » à utiliser tout de même le proxy ? Par exemple, j’imaginerais un logiciel capable d’intercepter la demande « GET /page.html » faite par le logiciel, de convertir cette requête pour utiliser le proxy, puis de renvoyer le résultat au logiciel comme si de rien n’était.
    Peut-être que le tunneling peut résoudre ce problème mais j’ai du mal à voir comment. Ou peut-être que l’installation d’un proxy transparent sur la même machine que celle contenant le logiciel pourrait résoudre ce problème ? Mais ici non plus, je ne vois pas comment faire. Si quelqu’un a une idée pour m’aider ce serait vraiment génial 🙂 Merci d’avance !

    1. Merci
      Oui il suffirait que pour sortir, la machine doive passer par une passerelle ayant un proxy transaparent, alors ça marcherait (en http).
      Mais plus simplement, je ne me rappelle plus l’outil que j’utilisais oil y a bien longtemps pour faire, ça, mais le principe était de lancer l’outil qu’on veut proxifier à l’intérieur de cet outil magique et il encapsulait tout ce qui sortait sur le réseau pour envoyer vers un proxy de notre choix.
      En fait, ça existe encore : https://www.google.fr/search?q=tcp+wrapper+proxify+any+application&oq=tcp+wrapper+proxify+any+application&aqs=chrome..69i57.9785j0j7&sourceid=chrome&espv=210&es_sm=122&ie=UTF-8

      proxycap peut-être, mais je vois qu’il y a plein d’outils, payant ou non je n’ai pas regardé

  28. Bravo pour ce tuto pédagogique qui m’a aidé a mieux cerner le sujet. Mais chez moi,
    Firefox refuse de se connecter en local :
    « connexion impossible » ou « connexion interrompue par le serveur »

    Après de nombreuses recherches, je tombe sur le site bpardo.fr :
    Edition 10 avril 2013 : Il semblerais que sur certaines configuration du synology DSM 4.2 le proxy SOCK5 ne soir pas activé. pour cela modifiez le fichier : /etc/ssh/sshd_config
    et veillez bien que cette ligne soit présente : AllowTcpForwarding yes

    Redémarrage du service ssh de synology : synoservicectl –reload sshd (ou au choix synoservicectl –restart sshd)

    Et ça marche……MERCI MERCI MERCI.
    C’est RESOLU. julien.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.