sme8: connexion SSH via port 443 // comment?

[arnaud056]

bonsoir tout le monde,
j'ai détecté aujourd'hui que mon proxy distant laisse apparemment passer les infos par les ports 21, 25, 80, 110 et 443.
J'ai bien dit apparemment car bien que la connexion (http://mon_domaine:port) n'a pu être établie (faute de renvoi du port testé sur ma sme) je n'ai pas eu de message d'erreur du style "port bloqué!" avec ces derniers.

je viens de réaliser quelques test de connexion sur ma sme avec mon wifi: en renvoyant dans la sme un (ou tous) les ports cités vers le localhost:22 je peux:
- réaliser une connexion SFTP avec WinSCP, mais simplement sans activer l'option "tunnel" qui ne fonctionne pas avec ces ports. La connexion est alors tout de même sécurisée, n'est-ce pas?
- réaliser une connexion SSH via Putty

-> à voir maintenant si les protocoles sur ces ports sont restreints.......
@ suivre......
Arnaud

[unnilennium]

21 => serveur ftp que je déconseille d'activer donc a essayer avec celui là, d'Autant que tu veux faire du scp ou du sftp
25 => serveur smtp
80 => serveur web
110 => serveur pop
443 => https

[arnaud056]

merci pour ton suivi unnilennium
Je n'avais pas encore lu ton dernier message quand j'ai essayé aujourd'hui le renvoi sur le 443 -->
Winscp et putty fonctionnent à perfection.
Donc suite à tes dernières indications, je viens d'essayer à présent le port 21 avec mon wifi --> pour winscp comme putty la connexion s'établit bien, mais dès que je commence à y faire circuler quelques KB elle décroche avec le message suivant sur le client: "connection reset by peer".
Dans le journal sshd de sme arrive alors ceci:

Code : Tout sélectionner

2012-10-24 21:54:33.633035500 Postponed publickey for root from 92.252.72.115 port 62057 ssh2
2012-10-24 21:54:39.177862500 Accepted publickey for root from 92.252.72.115 port 62057 ssh2
2012-10-24 21:54:56.877131500 session_input_channel_req: no session 1 req winadj@putty.projects.tartarus.org
2012-10-24 21:54:56.897717500 session_input_channel_req: no session 1 req winadj@putty.projects.tartarus.org
2012-10-24 21:54:56.897815500 Write failed: Connection reset by peer

Pris par le temps je n'ai pas encore approfondi mais j'ai trouvé ceci à la va-vite: https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=27337&forum=40 qui se rapproche à mon cas car il y a du ssh sur le port 21.

Contre question: mis à part le fait de devoir passer par putty pour atteindre la sme en https, y a t'il des contre-indications (en autre de sécurité) à utiliser le port 443?
Dans la négative, je conserve mon renvoi de port 443--> 22 et puis on clos le chapitre sans chercher d'autres complications.

Merci.
@+
Arnaud

Note à part: il apparait donc que la solution se trouvait plus que clairement décrite à la 2ème indication de ce topic.....

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

Il ne manquait plus que les caractères gras en rouge et en grosse police!

[unnilennium]

la seul chose c'est que tu ne pourras pas faire de https vers ton serveur, mais qu'aussi comme c'est un port de navigation quelqu'un d'autre peut s'y frotter.


pour le port 21 as tu désactivé le serveur ftp via acces à distance dans le manager ( je pense a un conflit du serveur ftp qui tente de répondre) ?

alternativement tente le port 445, il y a de forte chance qu'il soit bloqué par ton proxy mais on sait jamais.

pas de problème de sécurité en particulier, juste un risque de conflit entre https et ssh

[arnaud056]

bonsoir,
il me faut malheureusement modérer mon enthousiasme d'hier...
Et ce pour 2 raisons:
1- la liaison via le port 443 fonctionne certes, mais je me suis aperçu aujourd'hui qu'elle décroche très-très rapidement: j'ai voulu transférer avec winscp un fichier de 2MB dans le sens client distant --> sme et j'ai eu à chaque essai, dès le début de la connexion, un

Code : Tout sélectionner

software caused connection abort

Avec un fichier plus petit ça fonctionne sans problème.
Dans le sens sme --> client distant j'ai également pu transférer 5MB sans problème.
Je viens de faire un essai client distant --> sme via mon wifi sur un fichier de 400MB --> OK.
J'en conclus donc 2 pistes:
- le problème vient du proxy de mon client distant qui limite la taille des échanges (normalement un client n'upload pas de grosses quantités de données, surtout en https)
- la connexion était mauvaise (surchargé) et la liaison n'a pu être maintenu le temps nécessaire

Dans les logs sshd de la sme, j'ai au moment où j'essayais de transférer les quelques MB, de choses du style:

Code : Tout sélectionner

reverse mapping checking getaddrinfo for "le proxy de mon client distant" failed - POSSIBLE BREAK-IN ATTEMPT!

qui a un problème de DNS? ma sme ou le proxy?
et

Code : Tout sélectionner

Postponed publickey for arnaud from IP####### port 58312 ssh2
Accepted publickey for arnaud from IP####### port 58312 ssh2
subsystem request for sftp
 Bad packet length 3966339390.
Disconnecting: Packet corrupt

qu'est-ce qui a la mauvaise longueur et qui est corrompu: les paquets de données ou mon fichier? Pourquoi??

2- bien que le test http://ma_sme:21 ne produise pas de message d'erreur de la part du proxy, celui-ci bloque le sftp et le ssh sur ce port (winscp et putty).

pour le port 21 as tu désactivé le serveur ftp via acces à distance dans le manager ( je pense a un conflit du serveur ftp qui tente de répondre) ?

oui, je suis sur "accès ftp: aucun accès"



Je m'en vais faire quelques recherches..........
@ suivre
Arnaud
EDIT: en regardant les logs de la sme, j'ai remarqué qu'une âme charitable dont le FAI est aux USA a essayé de se connecter à ma sme un bonne dizaine de fois pendant que de rédigeais ce post!!

Code : Tout sélectionner

reverse mapping checking getaddrinfo for "le proxy de mon client distant" failed - POSSIBLE BREAK-IN ATTEMPT!

apparait au début de chaque connexion avec winscp (avant la vérification de la clé privée) --> ce n'est pas la source de mon probléme.

[arnaud056]

Bonsoir les amis,
et bien je crois que ce chapitre est tout du moins temporairement clos: mon client distant n'est plus dans ma possession depuis la semaine dernière
C'est une façon ............comme une autre de résoudre la problème...

Pour l'info: le problème de longueur des paquets à l'air d'être un assez répandu avec le SFTP, FTP, SSH. J'ai trouvé pas mal d'explications à dessus (cryptages incompatibles etc..) comme ici par exemple: http://www.snailbook.com/faq/sftp-corruption.auto.html mais je n'ai pas trouvé de solutions que j'ai pu appliquer.

Merci encore de m'avoir épaulé dans cette expérience, dont je pourrais, je l'espère, me resservir.

@+
Arnaud