Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
J'ai testé avec Putty, l'accès SSH marche nickel sur les 2 ports !
Par contre, avec MobaXterm, que je trouve assez pratique quand on utilise plusieurs machines, impossible d'accéder en SSH via le port 443 ! 
Seul l'accès SSH en 44322 est OK.
La dernière version portable et gratuite de MobaXterm est dispo ici:
https://mobaxterm.mobatek.net/download- … ition.html
Pour Putty portable et gratuit, c'est par ici :
https://portableapps.com/apps/internet/putty_portable
Si une bonne âme veut bien se donner la peine de tester et de communiquer les résultats obtenus, merci !
Le VPS : 51*38*235*238
2 ports à tester en SSH : 443 et 44322
Objectif: obtenir le prompt de login
@+
El Gecko.
Dernière modification par El_Gecko (26-06-2022 15:53:35)
On commence à vieillir quand on finit d'apprendre (proverbe japonais)
Hors ligne
Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.
Que se passe-t-il exactement avec mobaxterm ?
Apparemment openvpn attend indéfiniment que le client envoie quelque chose pour rediriger la connexion si le protocole n'est pas le sien.
Dans le protocole HTTP ou HTTPS, c'est toujours le client qui parle en premier. Dans le protocole SSH, le client peut attendre que le serveur parle en premier.
Une hypothèse est que putty "parle" dès que la connexion est établie alors que mobaxterm attend que le serveur parle en premier. Je n'ai ni putty ni mobaxterm pour le vérifier. Il faudrait faire une capture du trafic d'une connexion avec chaque client pour confirmer.
Le programme sslh fait aussi ce genre d'aiguillage en fonction du protocole, et peut sélectionner un protocole par défaut après un délai.
Il vaut mieux montrer que raconter.
Hors ligne
Très pratique pour s'assurer d'avoir un accès VPN et SSH quel que soit le matériel auquel on est connecté (hotspot Wifi...), le port 443 étant toujours ouvert.
A condition que l'accès internet ne limite pas l'utilisation de ce port au protocole TLS/SSL pour lequel il est prévu.
Et puis le transport d'un VPN de couche 2 ou 3 sur TCP, ce n'est pas idéal pour les performances. A utiliser en dernier recours.
Il vaut mieux montrer que raconter.
Hors ligne
option port-share ... Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.
C'est justement ça qui a attisé ma curiosité ! 
... et ça marche nickel avec Putty et X2go qui passent sans soucis en SSH sur les ports 443 et 44322 !
MobaXterm qui s'appuie, d'après mes lectures, pourtant sur Putty, semble attendre indéfiniment.
Dans le protocole SSH, le client peut attendre que le serveur parle en premier.
???
C'est la 1ère fois que je lis ça... mais c'est ce qui semble se passer !?!
Je ne vois pas bien comment ça peut marcher.
Tu aurais un peu de littérature sur le sujet ?
J'ai sniffé le début de session, sous Putty, on voit que c'est Putty qui parle en 1er à Debian SSH server.
Avec MobaXterm vers le port SSH 44322, on voit Debian SSH server en 1er !
Ca me démange les neurones tout ça !
J'ai d'ailleurs branché le support MobaXterm sur le sujet, mais bon, comme je suis en version gratuite, mon cas n'est bien sûr pas prioritaire ! Ils m'ont fait testé avec leur ancien "SSH engine" mais ça ne change rien.
Et puis le transport d'un VPN de couche 2 ou 3 sur TCP, ce n'est pas idéal pour les performances. A utiliser en dernier recours.
UDP est certes à privilégier pour les perfs si disponible et non bridé.
Mais je préfère avoir un accès VPN lent mais qui marche partout plutôt que rien du tout.
L'idéal est d'avoir une instance OpenVPN en UDP et l'autre en TCP.
Mais le top du top en matière de vitesse est le tunnel SSH d'où l'idée d'avoir via le port 443, toujours ouvert, accès à un serveur VPN et un serveur SSH. C'est ceinture et bretelles ! 
Ceci offre un maximum de chance d'accès au web, qqs le routeur par lequel on passe.
/!\ Contourner la "censure" ou le blocage de ports peux coûter très cher selon les pays ou... la charte régissant les activités pro ou scolaires /!\
@+
El_Gecko.
On commence à vieillir quand on finit d'apprendre (proverbe japonais)
Hors ligne
Je n'ai ni putty ni mobaxterm pour le vérifier.
Si tu as un poste client sous Windows sous le coude:
La dernière version portable et gratuite de MobaXterm est dispo ici:
https://mobaxterm.mobatek.net/download- … ition.html
Pour Putty portable et gratuit, c'est par ici :
https://portableapps.com/apps/internet/putty_portable
On commence à vieillir quand on finit d'apprendre (proverbe japonais)
Hors ligne
Je ne vois pas bien comment ça peut marcher.
Tu aurais un peu de littérature sur le sujet ?
Il faudrait regarder ce que dit la RFC qui spécifie le protocole SSH. J'observe qu'autant le client que le serveur d'openssh envoient leur identification dès l'établissement de la connexion sans attendre que l'autre côté le fasse. Mais il est courant dans d'autres protocoles (SMTP, POP, IMAP, FTP, NNTP...) que le client doive attendre que le serveur envoie d'abord sa bannière, ses capacités et/ou un message indiquant qu'il est prêt à recevoir une commande. Je ne suis pas particulièrement choqué qu'un client SSH se comporte de la même façon même si le protocole ne l'impose pas, par exemple pour s'assurer qu'il est bien connecté à un serveur SSH. Ce n'est pas pour rien que sslh a l'option dont j'ai parlé pour spécifier un protocole par défaut en cas de time-out.
Si tu as un poste client sous Windows sous le coude
Je n'en ai plus chez moi. Je connais putty que j'ai utilisé lorsque mon PC principal était encore sous Windows, et mobaxterm que j'utilise au travail, mais de toute façon je ne vois pas ce que je pourrais faire de plus puisque tu as déjà confirmé mon hypothèse.
Il vaut mieux montrer que raconter.
Hors ligne
...je ne vois pas ce que je pourrais faire de plus puisque tu as déjà confirmé mon hypothèse.
J'ai regardé avec un petit sniffer gratuit très basique (Nirsoft - Smart sniffer) mais qui rend bien des services.
Je pensais que tu étais peut-être mieux outillé (Wireshark...) et plus compétent que moi pour une observation plus précise.
Mais bon, le serveur qui initie la session, ça m'intrigue.
C'est plus un serveur, par définition, non ?
....ou alors il crée un tunnel puis attend le client mais là, c'est pas le cas.
Si MobaXterm daigne me répondre, je vous tiendrai au jus.
@+
El Gecko.
On commence à vieillir quand on finit d'apprendre (proverbe japonais)
Hors ligne
Je pensais que tu étais peut-être mieux outillé (Wireshark...) et plus compétent que moi pour une observation plus précise
Je ne vois pas ce que je pourrais apporter de plus.
le serveur qui initie la session, ça m'intrigue
Le serveur n'initie pas la session, il envoie sa version quand il reçoit une connexion. Comme je l'ai écrit, c'est très commun dans les protocoles que le serveur envoie un message dès la connexion du client. C'est comme quand un client entre dans un magasin, le vendeur dit bonjour, le client dit bonjour, peu importe l'ordre. Ici on a un client qui attend que le vendeur dise bonjour avant de dire bonjour.
Dernière modification par raleur (27-06-2022 22:49:32)
Il vaut mieux montrer que raconter.
Hors ligne
Le serveur n'initie pas la session, il envoie sa version quand il reçoit une connexion.
Et on ne voit rien passer sur le réseau "quand il reçoit une connexion" ??? 
@+
El_Gecko
On commence à vieillir quand on finit d'apprendre (proverbe japonais)
Hors ligne
Et on ne voit rien passer sur le réseau "quand il reçoit une connexion" ?
Si, la "poignée de main" TCP (3-way handshake SYN, SYN+ACK, ACK). J'ai l'impression que ton outil ne montre que les données.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par El_Gecko (07-07-2022 00:18:37)
On commence à vieillir quand on finit d'apprendre (proverbe japonais)
Hors ligne
Pages : 1