Bonjour,
dans mon entreprise j'ai accès via le site à mes mails et à la possibilité d'ouvrir pour la machine de connection le port ssh d'une machine "cachée" de mon entreprise (dont je connais l'adresse IP ex 198.56.84.35). Cela fonctionne bien sauf que souvent je suis chez des clients et l'accès internet passe par un proxy. Du coup quand j'ouvre ma session ssh je pense que c'est le proxy qui est autorisé par la machine 198.56.84.35 et non l'ordinateur que j'utilise. Chez moi cela fonctionne très bien car je n'utilise pas de proxy. Comment faire pour contourner cela ? Merci
Bonne soirée
Forum général.général Connection sur une machine distante
24
sept.
2009
# demandes à ton admin
Posté par NeoX . Évalué à 5.
- les besoins de l'entreprise (securité, tout ca)
- les besoins des utilsateurs (toi, le fait que tu sois chez un client...)
[^] # Re: demandes à ton admin
Posté par cppuser . Évalué à 1.
[^] # Re: demandes à ton admin
Posté par NeoX . Évalué à 3.
la variable : depuis ton entreprise ou depuis le client
l'action : tu veux te connecter chez toi en SSH
le probleme :
ton client utilise un proxy
la solution :
c'est sur TON parefeu qu'il faut autorisé l'ip du proxy du client
ce qui souleve un autre probleme, c'est qu'il faut connaitre les IPs de tout tes clients
une autre solution :
creer un VPN qui ecoute sur le port 443 (par exemple)
ainsi ton client vpn (sur ton portable)
peut ouvrir le vpn vers chez toi (le proxy laissant surement passer le port 443)
et router ensuite tes besoins via ce 'reseau' vpn
# D'abord mieux formuler la question
Posté par benoar . Évalué à 2.
[^] # Re: D'abord mieux formuler la question
Posté par cppuser . Évalué à 1.
je peux me connecter sur le serveur de mon entreprise via ssh. Mais il faut au préalable autorisé la connection ssh. Pour cela je me connecte sur le serveur et je demande l'ouverture pour une certaine durée du port 22 de ssh. Du coup par cette passerelle je peux me connecter sur l'ordinateur correspondant dans mon entreprise.
Pour des raisons de sécurité seule la machine ayant demandé l'ouverture de "ssh" peut se connecter. Donc en connection directe de chez moi je peux y accéder sans problème car je n'ai pas de proxy donc c'est ma machine (le client) qui est autorisé.
Mais à l'extérieur (chez des clients) j'ai accès à internet via un proxy et donc, c'est du coup ce proxy qui est autorisé par mon entreprise à se connecter sous ssh et pas moi ;-).
Exemple : moi IP_la_mienne, proxy IP_proxy, serveur d'entrerise IP_serveur
Du coup IP_serveur autorise IP_proxy en ssh mais pas IP_la_mienne.
Et comme je suis chez des clients (pour des formations) ils ne peuvent me donner des droits supplémentaires. J'ai juste besoin que le proxy redirige les paquets ssh sur moi pour que cela fonctionne mais sans avoir besoin de droits. Le proxy autorise le port 22.
Est ce assez clair ?
[^] # Re: D'abord mieux formuler la question
Posté par nono14 (site web personnel) . Évalué à 1.
Tu confonds peut etre nat / proxy ?
Système - Réseau - Sécurité Open Source
[^] # Re: D'abord mieux formuler la question
Posté par nono14 (site web personnel) . Évalué à 1.
corkscrew ssh port 443
Système - Réseau - Sécurité Open Source
[^] # Re: D'abord mieux formuler la question
Posté par benoar . Évalué à 2.
"cette passerelle" : quelle passerelle ? Tu n'as pas encore parlé de passerelle ...
Ensuite, tu parles (chez le client) de l'IP du proxy derrière lequel tu as une autre IP : dans ce que j'imagine, derrière un proxy tu auras (en général) une adresse privée, donc depuis l'extérieur (ton entreprise) tu auras tout le temps l'adresse du proxy.
D'ailleurs, un proxy qui "autorise le port 22" ça ne veut rien dire, vu qu'un proxy ne fait normalement que du HTTP/FTP (ou alors détaille un peu plus ce que c'est).
Bref, ce n'est toujours pas très cohérent, ce serait bien de savoir si c'est parce que tu expliques mal, ou que tu connais mal le réseau.
[^] # Re: D'abord mieux formuler la question
Posté par cppuser . Évalué à 1.
Mais cea ne fonctionne pas quand je suis derrière un proxy. Désolé mais n'étant pas familiarisé avec les réseaux je m'exprime certainement pas de façon claire pour des experts. Et je ne connais pas le réseau du client non plus. En général j'interviens pour des formations pour ce client (des cours en fait). Lorsque je ne suis pas derrière un proxy tout fonctionne bien. J'ai la commande suivante qui marche chez moi :
ssh -N -f nom_nom@198.66.53.48 -L3389:172.54.56.88:3389
pour accéder au terminal serveur de l'entreprise. Mais j'en déduis que lorsque je suis chez le client, le proxy "bloque" le fonctionnement normal que j'ai chez moi. j'en déduis que du coup la machine 198.66.53.45 n'autorise le port 22 de 198.66.53.46 (ce que j'ai nommé la passerelle) que pour le proxy et non pour mon adresse privée qui se trouve derrière le proxy.
Le client n'est pas d'accord de modifier quoi que ce soit sur son proxy (question de sécurité).
[^] # Re: D'abord mieux formuler la question
Posté par nono14 (site web personnel) . Évalué à 1.
Configure ton ssh ou firewall pour ecouter sur le port 443.
C'est ce que je disait plus haut.
Du coup la sécurité chez ton client c'est toi qui la contourne...
Un proxy applicatif est différent d'une passerelle/firewall.
Système - Réseau - Sécurité Open Source
[^] # Re: D'abord mieux formuler la question
Posté par benoar . Évalué à 2.
Bon, je suis désolé, mais tu ne connais pas assez le réseau pour essayer de faire un truc qui peut marcher comme tu as l'air de raconter (ce que je cite c'est toutes les bourdes qui ne veulent rien dire). C'est de plus super tordu, je trouve, par rapport à une solution plus simple comme nono14 indique.
Pour moi, ton problème chez le client c'est juste qu'il bloque le port 22, point. Un proxy http (genre squid) permet d'aller sur le web pour le http, c'est bien, mais en dehors de ça, je suppose que chez ton client tout accès "direct" au net est prohibé. Donc pas de SSH.
Après, tu peux essayer de bidouiller avec le proxy, voire déjà s'il autorise le CONNECT, sur le port 22 ce serait mieux, ou sinon sur le 443 comme indique nono14 ça a plus de chances de passer. Après, si le CONNECT est bloqué (ou le deviendra, puisque c'est un contournement de la politique de sécurité et ça se verra un jour) il te reste le GET/POST classique avec un tunnel qui va bien, du polling et tout le bazarre .... Bref, c'est très crade.
Enfin bref, ta solution, selon moi, c'est soit que ton entreprise trouve une solution adaptée (et moins galère ...) à tes clients, soit de dire à tes clients d'arrêter de faire les prudes avec leur "politique de sécurité" (OK, je m'avance un peu sur leur niveau de connaissance, mais les politiques de sécu sont souvent à deux vitesses ...)
Bon, et quelques conseils si tu gardes ta méthode : ton espèce de port knocking, c'est chiant et galère, pourquoi n'ouvres-tu pas directement le 22 sur 198.66.53.48 ? Ensuite, ton tunnel SSH (-L ...:...:...) c'est un peu gore, moi j'aurais "simplement" fait du port forwarding vers 172.54.56.88 (qui n'est pas une adresse privée selon la "norme", mais bon ...).
Voilà, si en plus tu as fait tout ça parce que l'admin de ta boite est borné est n'a pas de meilleure solution, ça fait un double contournement de sécurité, donc pour ton taf je te souhaite bon courage.
[^] # Re: D'abord mieux formuler la question
Posté par cppuser . Évalué à 2.
Ben on ne peut pas ouvrir le port 22 sur cette machine directement, on doit d'abord se connecter sur son compte (mail...) et demander une ouverture d'une heure. C'est la sécurité de mon entreprise je dois faire avec.
Pour information, quand je suis chez le client c'est à tire personnel et non professionel, mais comme ce n'est pas sur le même site. Il arrive que j'ai des manipulations à faire sur divers logiciels à distance. Et du coup chez le client (pour qui ce n'est son affaire) je n'arrive pas à faire la même manipulation que chez moi (port 22 bloqué d'après toi chez le client).
Je suis désolé de sortir des "bourdes", si j'étais un expert réseau je ne poserais pas ces questions, ce n'est pas du tout mon domaine de compétences. Et puis je suis là pour apprendre ;-)
Je n'essaye pas de contourner la politique de mon entreprise, si je le voulais je laissserais ma machine de bureau allumée et je ferais un reverse ssh pour y accéder mais je préfère rester dans la "légalité" de mon entreprise.
Merci de vos réponses je vais essayer la solution de nono14
[^] # Re: D'abord mieux formuler la question
Posté par benoar . Évalué à 2.
En tous cas c'est cool que tu aies envie d'apprendre, mais pour l'instant je laisse tomber le problème ,je n'arrive pas à comprendre : j'avoue que même tes phrases sont pour moi parfois incompréhensibles, en dehors de l'aspect technique (français, logique).
Si t'avances et que tu as plus de détails à peu près bien présentés, rangés et expliqués, n'hésites pas. Bon courage.
[^] # Re: D'abord mieux formuler la question
Posté par cppuser . Évalué à 2.
merci de tes réponses. Aller chez un client à titre non professionnel c'est pour moi "poser une journée pour faire une formation avec l'accord de mon employeur". Et donc le "client" est l'école (car c'est souvent une école) ou je fais des cours, d'où le problème du proxy car il concerne aussi les étudiants. Du coup le responsable informatique de l'école n'a pas envie de faire des modifications pour que je puisse accéder de l'école à mon entreprise. C'est ce responsable informatique qui m'a dit que cela devait être le proxy qui bloquait. Mais vos remarques me donnent des pistes (port https) pour essayer de contourner le problème en toute légitimité. Si cela ne fonctionne pas ce n'est pas grave, j'aime bien résoudre des problèmes mais je n'ai pas le temps de me former aux réseaux (chacun son domaine).
Bon week-end
[^] # Re: D'abord mieux formuler la question
Posté par benoar . Évalué à 2.
Dans ce cas, oui la solution de nono14 est probablement celle qui a la chance de mieux marcher. Avec les réserves que j'ai énoncé un peu plus haut, mais ça vaut le coup d'essayer. En tous cas, ça demandera sûrement un peu de modification du côté de ton entreprise (faut bien qu'un des deux côtés s'adapte si l'autre est rigide).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.