sme8: connexion SSH via port 443 // comment?

[arnaud056]

Bonsoir tout le monde,

Contexte :
familial! Hobby, curiosité, chalenge....


Besoin :
ou plutôt souhait: accéder à ma SME8 (passerelle+serveur) par SSH, de l'extérieur, sur son port 443, tout en conservant HTTPS sur ce port.
Si possible, conserver l'utilisation du port 22 en plus (donc accès SSH sur port 22 et 443).

Schéma :


client distant: windows7, WinSCP et Putty
||
||
proxy distant: HTTP, HTTPS et FTP
||
|| internet
||
ma box: renvoie tous les ports sur la sme
||
||
ma SME8 en passerelle + serveur
||
||
mes clients ubuntu



Modem/Routeur/Box :
Comme indiqué, il renvoie bêtement tous les ports vers la sme.


Firewall/Serveur-passerelle multifonctions :
SME8, en mode passerelle+serveur, à jour. Pas de modifs de renvoi de port, iptable etc.....


Adressages :

Question :
Voilà donc la chose: je souhaite pouvoir joindre via SSh ma SME depuis un poste distant placé derrière un proxy HTTP.
Etant donné que le proxy distant rejette le SSH, les "docs de filous" telles que la 3ème citée plus bas donnent comme recette magique de passer par un tunnel SSH qui passerait par le port HTTPS (443).

Oui mais, ma SME, après réglage du port SSH sur 443 dans le server-manager --> accès à distance, n'accepte ni ne rejette les connexions. Depuis l'intérieur par exemple:

Code : Tout sélectionner

arnaud@KCNAthlon:~$ ssh root@192.168.2.5 -p 443
_


je perds simplement le prompt et dois le récupérer par un ctrl+z.

Sur les ports 444 ou 450 par exemple, la connexion est OK. Il me faut/faudrait cependant le port 443!
De plus, étant donné que le port standard est le 22, j'aimerais bien que la sme accepte en plus le SSH sur ce port: ça m'éviterait de modifier mes scripts et mes sauvegardes affa.

Alors, en résumé, comment:
- passer SSH sur port 443?
- tout en conversant HTTPS?
- laisser en plus le port 22 actif pour le SSH?

Pistes imaginées :
Je pense que le "problème" vient du fait que la sme continue d'attendre du HTTPS sur le port 443
--> me faut-il un multiplexeur (sshl par ex.)? Ça existe pour la SME (j'ai bien entendu déjà cherché... un peu...) ?

Je pourrais peut être faire en sorte que ma box renvoie le port 443 sur le 22 de la sme. Oui, mais le vrai HTTPS (webmail) arrivera également alors sur le port 22 de la sme --> je ne pense pas que ça fonctionne!

Recherches :
http://smeserver.fr/faq_aef.php
http://doc.ubuntu-fr.org/ssh
http://olivier.cochard.me/bidouillage/comment-surfer-tranquille-au-bureau (assez bonne doc pour débutant, malgré un titre "special" // m'a fait venir l'idée du multiplexeur HTTPS/SSH "sshl")
http://forums.ixus.net/viewtopic.php?t=42926
http://forums.ixus.net/viewtopic.php?t=43070

ainsi qu'avec mon ami google avec des requètes du style:

http://www.google.fr/#hl=fr&q=sme+server+ssh+port+443+no+connexion&oq=sme+server+ssh+port+443+no+connexion&gs_l=serp.3...5060552.5062305.2.5062782.4.4.0.0.0.0.673.1235.1j1j0j1j0j1.4.0...0.0...1c.1.bXk5yaEv0Hc&bav=on.2,or.r_gc.r_pw.&fp=e60121a80e72ba16&bpcl=35243188&biw=1600&bih=701

http://www.google.fr/#hl=fr&q=sme+server+ssh+et+https+port+443&oq=sme+server+ssh+et+https+port+443&gs_l=serp.3...51663.58019.2.58582.21.21.0.0.0.0.175.2326.5j16.21.0...0.0...1c.1.q-6ypb7dNjg&bav=on.2,or.r_gc.r_pw.&fp=e60121a80e72ba16&bpcl=35243188&biw=1600&bih=701

Logs et tests :
Test 1: essai de connexion de l'extérieur sur le port 22 depuis mon client distant: bloquage par le proxy distant
Test 2: essai de connexion de l'extérieur sur le port 22 via le wifi de mon voisin --> OK
Test 3: essai de connexion de l'extérieur sur le port 443 depuis mon client distant: pas de connexion, pas de message d'erreur particulier à part un "time out" de WinSCP et un perte du prompt de Putty
Test 4: idem depuis l'intérieur (cad mon client ubunt) --> même résultat
Test 5: test depuis l'intérieur sur ports 444, 450: connexion OK


Merci de me filer un tuyau car j'ai dû passer bêtement à côté de quelque chose de basique: j'ai l'air d'être le seul à avoir ce problème au vu des quelques vieux résultats (sme6 etc...) que m'a donné google sur le changement de port en question.

@+
Arnaud

[sibsib]

Hello,

Réponse vite fait, il me semble complexe d'avoir à la fois ssh et https sur le port 443 Plus généralement, il est complexe d'avoir deux programmes qui écoutent sur le même port

Si tu es super branché développement, tu dois pouvoir créer un listener à toi qui écoute sur le port 443, qui analyse le début de la demande, et en fonction, qui forke un sshd ou un https... Gros dev à prévoir, et je ne ferais pas çà sur ma machine !

Par contre, ayant la même contrainte que toi (en fait, en plus sévère, parce que notre proxy analyse le flux, et ce n'est pas la peine d'essayer de lui faire croire que du ssh est du https !), j'ai mis la solution suivante en place sur ma sme : ajaxterm
Attention, ce n'est pas exactement du ssh complet. C'est plutôt un émulateur de terminal codé en ajax, qui permet de se connecter en ssh à la machine locale. Donc, pas de transfert de fichiers avec çà.
Mais bon, ça permet de passer chez soi depuis le taf, grâce aussi à mon certificat gandi (pas de connexion ssh au taf si le certificat n'émane pas d'une autorité reconnue ...)

A+,
Pascal

[arnaud056]

Bonsoir,
merci Pascal pour tes indications et pour me rappeler qu'il se peut que le proxy qui me bloque le port 22 est peut être aussi strict que le tien.....
Je suis donc en train de regarder ce que la voie que tu as indiquée (=web-based SSH) peut me proposer et quels en sont les avantages et les inconvénients.

En fait, ce que je qui m'a fait me lancer sur la voie du SSH est le transfert de fichiers (winSCP avec un login utilisateur) --> c'est râpé apparemment....
le reste (navigation web via ma sme etc..) ne m'intéresse pas vraiment. Bien sûr, maintenant que j'ai un peu vu ce que permet un tunnel SSh, j'ai bien envie d'essayer de faire fonctionner ça par curiosité.

Dans le pire des cas, il faudra que je me rabatte sur le FTP, mais ce n'est malheureusement pas le même niveau de sécurité....

@+
Arnaud

[unnilennium]

deux solutions :

- c'est le port qui est filtré alors passe sur le port 445 ou 23 ou n'importe lequel (au passage ipcop fait du https sur 445 au lieu de 443 pour son interface de management)
- c'est le protocole qui est filtré alors, tu peux essayer le vpn et au travers du vpn passer en ssh ( double cryptage du coup)

pour le vpn tu peux choisir soit le pptp de base de sme soit la contrib openvpn, cela te fera donc deux protocols differents a essayer et avec un peu de chance l'un d'eux n'est pas filtré par ton proxy

ajaxterm est effectivement une alternative mais pas pour l'upload, tu pourrais aussi penser a phpwebftp via une connexion https pour l'upload en ouvrant le ftp que au localhost


alternativement je tenterais de faire un transfert de port sur la sme 443 externe => 22 localhost
je pense que ssh n'Aimera pas mais tu peux essayer
de cette facon de l'Exterieur ton port 443 est bindé au 22, mais en reseau local cette regle existe pas et tu as acces au https par ce port
de même le 22 est intact des deux coté pour le SSH

seule limite plus possible de faire du https depuis le web sur ton serveur sauf via vpn ou tunnel ssh ...

[arnaud056]

Bonsoir unnilennium
et merci pour tes indications.
Je ne pense pas que ce soit que le port 22 qui soit filtré: il est normalement (tout du moins je le pense...) plus facile de tout fermer et de n'ouvrir que ce l'on autorise. Mais bon, je vais tester car ce serait la solution la plus simple.

Et oui, le VPN: je l'avais oublié celui-là... Ça vient certainement du fait que je ne m'y suis jamais collé et que le net est plein d'un tas de de choses commerciales --> au lieu de trouver une méthode ou de la doc on trouve plus facilement un produit à acheter ou à tester pendant un mois!
Mais j'ai regardé aujourd'hui et en fait ça à l'air plus simple que pensé (tout du moins jusqu'à présent...):
- pptp est d'origine sur la sme (comme tu me l'as rappelé) et est déjà prévu dans win 7 (natif disent les pros). J'ai fait un essai toujours via le wifi de mon voisin: ça a marché du premier coup! Reste à savoir si mes droits sur le win7 distant vont me permettre de configurer la connexion --> test demain
- openvpn existe apparemment en version "portable" que je pourrais, je pense, lancer d'une clé usb (comme Putty ou WinSCP) --> test si le pptp ne fonctionne pas
Mais là aussi: il faut que les ports soient ouverts........

@ suivre.......
Arnaud

[arnaud056]

Bon , et bien le résultat des courses n'a pas été probant:
- avec les paramètres par défaut pour la connexion vpn du client win7 distant: j'obtiens une erreur 800 (-->temps limite dépassé)
- en décochant le L2TP et en mettant PPTP comme codage: j'obtiens une erreur 807 (--> connexion interrompue)

En regardant vite fait: erreur 807 = très souvent blocage par le pare-feu --> il faudrait donc ouvrir le/les ports correspondants

Je compte donc essayer avec openvpn. Cependant il faut que je me renseigne avant sur les droits nécessaires pour faire tourner le client sous win7. De plus je ne souhaite pas réaliser de véritable installation: apparemment il est possible de le faire tourner en mode portable sur une clé usb --> à vérifier.
Lien: http://sourceforge.net/projects/ovpnp/

@ suivre...
Arnaud

[arnaud056]

...exercice en pause forcée en ce moment.....

[unnilennium]

openvpn doit avoir les droits d’administration sur le poste pour fonctionner afin de modifier la table de routage.

as tu essayé de faire un simple transfert de port comme proposé ? En effet la bonne logique est de bloquer un protocole et non pas un port, mais il m'est arrivé souvent de voir des blocage par port ....


je commencerais genre par transfert du port 81 vers 80 sur localhost, puis tu tente de naviguer sur ton navigateur web favoris vers :

http://ipPubliqueDeTonServeur:81

si cela ne passe pas, c'est le port qui est bloqué, réessaye avec un autre jusqu'a ce que tu en trouve un de fonctionnel.

si cela passe c'est que le port est ouvert, tu peux donc tenter de supprimer cette règle et d'en refaire une autre : port 81 vers 22 sur localhost et d'essayer avec Putty. Si cela bloc c'est que c'est le protocol ssh qui est filtré par le firewall.

[arnaud056]

Bonsoir,
merci bien unnilennium de me soutenir dans les essais de mon gadget!

openvpn doit avoir les droits d’administration sur le poste pour fonctionner afin de modifier la table de routage.

oui... Je l'ai remarqué également. J'avais espéré que la version "portable" d'openvpn permette de passer à travers mais, comme tu l'indiques, le "problème" est situé plus profondément dans le système d'exploitation et ne dépend pas du logiciel

as tu essayé de faire un simple transfert de port comme proposé ?

Pas encore.
Je suis les pistes que tu m'as indiquées il y a quelques pots de cela dans l'ordre où elles le sont, cad méthodiquement de haut en bas
Ça m'aurait arrangé que le vpn fonctionne et j'en ai profité pour me plonger un peu dans ce domaine (une première pour moi...), mettre des choses nouvelles en place et regarder ce que cela permet et où cela bloque.

je commencerais genre par transfert du port 81 vers 80 sur localhost, puis tu tente de naviguer sur ton navigateur web favoris vers :
http://ipPubliqueDeTonServeur:81

Je comprends l'esprit de la ruse.
La manière de faire m'échappe encore un peu: dans le server-manager --> sécurité --> renvoi de port, on peut bien entendu...... renvoyer des ports!
Mais ici, il faudrait renvoyer le port 81 externe (car la requête arrive de l'extérieur) vers le 80 interne ou externe
--> ma question: comment spécifier "externe"? En ne mettant pas "localhost"?
Je pense que pour interne il n'y a qu'à mettre "localhost".

si cela ne passe pas, c'est le port qui est bloqué, réessaye avec un autre jusqu'à ce que tu en trouve un de fonctionnel.

oui, mais des ports il y en a..... 11371 ça fait beaucoup à essayer un par un.......
--> j'essaye au pif (exceptés ceux déjà réservés)?

Je m'en vais essayer de mettre le 81 sur le 80
@ suivre.......
Arnaud

[unnilennium]

en externe tu n'as pas besoin de restreindre à une ip externe.

le reglage est
ip externe : vide
port externe : 81
port interne 80
ip interne: localhost


il y a même bien plus de ports que cela mais en general on essaye des ports du style 81 8080 etc.