Utiliser Putty via port 80 sous Win XP ?

Pause Café
#1

Bonjour à toutes et tous!

Je ne manque pas de culot de venir poser une question en rapport avec Windows XP sur un forum Debian, mais le but est tout à fait louable :smiley:

Au taf les PC sont sous Windows XP. Auparavant, j’utilisais Putty pour me connecter en SSH sur mon PC perso, mais l’administrateur filtre le port 22 et je ne peux donc plus me connecter chez moi.

Les ports encore ouverts sont: 22 (ssh mais filtré), 443 (https) et 80.

Mon intention est d’utiliser le port 80 pour Putty via un programme du genre HTTPORT, mais c’est là que je bloque :frowning: et que j’ai besoin de votre aide.

Ma question est de savoir si quelqu’un a déjà utilisé ce logiciel et s’il veut bien m’expliquer clairement son fonctionnement.

Merci d’avance à ceux qui me répondront !

Bonne après-midi :smiley:

#2

Gare à toi si jamais Ed passe par là :smt067

#3

Une autre solution déjà mit en oeuvre, tu fais en sorte que le serveur ssh cible écoute sur un des ports non filtrés, 80 ou 443 (ou alors via redirection de flux avec iptables).

#4

La méthode discrète consiste à utiliser sslh qui permet de switcher une connexion sur un port donné entre du SSL ou du SSH autrement dit un serveur https et un serveur ssh.
Tu le fais écouter sur le port 443 et siwtche le traffic sur ton serveur SSH (si traffic SSH) ou un port 442 (si traffic SSL), cela permet de dissimuler un serveur SSH derrière un serveur Web HTTPS

#5

Merci pour vos réponses rapides!

@Fran: si j’ai bien saisi, du côté client (XP + Putty) je lui renseigne le port 443 et du côté serveur (at home) j’édite mon sshd.conf (de mémoire) pour qu’il écoute sur le port 443 :question:

EDIT: après avoir installé sslh bien sur ^^

#6

Faudrait savoir, le port 22 est ouvert ou filtré ?

#7

Faudrait savoir, le port 22 est ouvert ou filtré ?[/quote]

Désolé pour le manque de termes techniques adéquats.

Sur le site Shields-Up, il apparaît comme ouvert mais étant donné qu’auparavant je pouvais me connecter sans problème et que maintenant ça ne fonctionne plus, je pense que ce port ne laisse passer que certaines IP (d’où le terme ‘filtré’ employé abusivement).

Bien sur, ce n’est là que supposition car je me vois mal demander ce qu’il en est à l’admin :smiley:

#8

[quote=“Vonstorm”]Merci pour vos réponses rapides!

@Fran: si j’ai bien saisi, du côté client (XP + Putty) je lui renseigne le port 443 et du côté serveur (at home) j’édite mon sshd.conf (de mémoire) pour qu’il écoute sur le port 443 :question:

EDIT: après avoir installé sslh bien sur ^^[/quote]

Pas tout à fait, tu peux faire la chose suivante:

  1. Tu as un seerveur web https que tu veux garder
  • Tu le fais écouter sur le port 442
  • Tu laisses ton serveur ssh classiquement sur le port 22
  • Tu installes sslh (paquet sslh
    deb boisson.homeip.net/debian lenny divers
    )
  • Tu le configures par /etc/default/sslh

PIDFILE=/var/run/sslh.pid LISTEN=0.0.0.0:443 SSH=localhost:22 SSL=localhost:442
et hop, ça marche: tons erveur web répondra encore aux requêtes sur le port 443 et un ssh sur le port 443 te donnera ton ssh.

  1. Tu n’as pas de serveur Web https, il te suffit de faire écouter le serveur SSH sur le port 443.
#9

[quote]
2) Tu n’as pas de serveur Web https, il te suffit de faire écouter le serveur SSH sur le port 443.[/quote]

OK…

Je n’ai pas de serveur web à la maison, je vais donc faire écouter le serveur SSH sur le port 443 et configurer Putty au taf pour le port 443…

Je vous tiens au courant dès demain.

Merci ! :smiley:

#10

Les sites de scan comme “Shields Up” testent les ports en entrée, pas en sortie.

#11

Remarque pertinente! Et c’est l’occasion pour moi de te demander quelle serait la bonne méthode pour tester un port en sortie ?

#12

Tu peux utiliser un scanner de port tel que nmap par exemple vers une machine à l’extérieur.

#13

Nmap de l’intérieur vers l’adresse IP d’une machine à toi ayant tous les ports qui t’intéressent ouverts (même sans vrai service qui écoute dessus, ça peut être juste un trou noir du genre discard). Mais ce n’est peut-être pas la méthode la plus discrète vis-à-vis du firewall et de son administrateur. Les ports ouverts sur la machine cible, c’est pour le cas d’un firewall “poli” qui simulerait la réponse d’un port fermé (TCP RST) comme le fait la cible REJECT d’iptables. Pour un seul port particulier pas besoin de dégainer l’artillerie lourde nmap ; tcptraceroute voire telnet ou nc peuvent suffire.

Ça c’est pour TCP. Pour UDP c’est plus compliqué car un port UDP ouvert ne renvoie pas forcément de réponse, on ne peut pas le distinguer directement d’un port filtré silencieusement. Si on veut une réponse, il faut utiliser le protocole du service associé.