[SSH] Connexion impossible depuis une machine hors du réseau

[homeostasie]

Bonjour,

Bien je me décide à poster un message dans un forum après un jour de recherche sur google et des tentatives infructueuses…

J’ai installé récemment un serveur SSH sur une Debian 5.0 (qui joue aussi le rôle de passerelle entre 2 réseaux privés). Celui-ci écoute sur le port 192.168.0.10:443.

Première chose que j’ai faîte, me connecter à partir d’une machine d’adresse 192.168.1.22 via la commande “ssh -p 443 nom@192.168.0.10”. Nikel, cela marche du premier coup, après avoir autorisé le port destination 443 vers la machine Debian à ouvrir des connexions (Iptables).

Deuxième tentative, j’ai fait une redirection de port sur ma box internet pour rediriger le port destination 443 vers ma machine Debian. Toujours à partir de ma machine 192.168.1.22, je me connecte au serveur SSH via la commande “ssh -p 443 nom@ip_internet”. Nikel, cela marche encore du premier coup. Petite remarque tout de même, c’est l’adresse interne de ma box (192.168.0.254) et non externe (internet) qui effectue la connexion.

Tentative ultime, je veux accéder à mon serveur SSH depuis un PC distant (sur le réseau internet) et là badaboum, rien n’est nikel, je suis n1ké…

1. A partir d’une machine Fedora 10, voici le résultat:

[quote]ssh -v -p 443 nomuser@ip_mabox
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: ssh_connect: needpriv 0
debug1: Connecting to ip_mabox [x.x.x.x] port 443.
debug1: Connection established.
debug1: identity file /home/toto/.ssh/identity type -1
debug1: identity file /home/toto/.ssh/id_rsa type 1
debug1: identity file /home/toto/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host[/quote]

2. A partir d’une machine XP avec putty:

Putty Fatal Error: network error: Softaware caused connection error.

Au niveau du fichier “hosts.allow”, j’ai:

... sshd: ALL
et au niveau du fichier “hosts.deny”, je n’ai rien spécifié.

Au niveau du fichier de log sur ma machine faisant tourner le serveur SSH, j’ai ceci:

sshd[3376]: Did not receive identification string from 81.x.x.x

Je suis très preneur d’aide pour résoudre le problème. Si vous avez besoin de plus d’informations, ne pas hésiter non plus.

[ripat]

'lut,

Tu as activé un log dans tes règles iptables? Ça permettrait de s’assurer que c’est pas lui qui bloque.

As-tu essayé à partir une machine Linux hors lan?

As-tu des directives filtrantes dans le sshd_config?

[homeostasie]

As-tu essayé à partir une machine Linux hors lan?

Oui et j’obtiens justement ceci:

[quote]ssh -v -p 443 nomuser@ip_mabox
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: ssh_connect: needpriv 0
debug1: Connecting to ip_mabox [x.x.x.x] port 443.
debug1: Connection established.
debug1: identity file /home/toto/.ssh/identity type -1
debug1: identity file /home/toto/.ssh/id_rsa type 1
debug1: identity file /home/toto/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host[/quote]

As-tu des directives filtrantes dans le sshd_config?

Un truc du genre:
AllowUsers nomuser mais rien, me semble t’il, de contraignant.
Je peux toujours fournir le contenu de ce fichier?

Tu as activé un log dans tes règles iptables? Ça permettrait de s’assurer que c’est pas lui qui bloque.

C’est en effet une bonne idée, je vais tâcher de vérifier cela et sinon de mettre un fichier de log en place.

[homeostasie]

Voici quelques informations supplémentaires concernant mon soucis (connexion depuis une machine cliente distante 81.x.x.x vers mon serveur SSH local).
Afin d’isoler le problème, j’ai fait tourner au préalable wireshark pour visualiser réellement ce qui se passe lors de la connexion SSH et le résultat est:

[quote]81.x.x.x (46000) -> 192.168.0.10 (443) TCP SYN
192.168.0.10 (443) -> 81.x.x.x (46000) TCP SYN/ACK
81.x.x.x (46000) -> 192.168.0.10 (443) TCP ACK
192.168.0.10 (443) -> 81.x.x.x (46000) SSL Continuation Data
81.x.x.x (46000) -> 192.168.0.10 (443) TCP RST,ACK
81.x.x.x (47554) -> 192.168.0.10 (443) TCP SYN
192.168.0.10 (443) -> 81.x.x.x (47554) TCP SYN/ACK
81.x.x.x (47554) -> 192.168.0.10 (443) TCP RST
etc…[/quote]
On observe que la poignée de main a bien eu lieu, je conclue que côté serveur il n’y a pas un problème de filtrage par le firewall.
Par contre, j’ai bien l’impression que le firewall de la boite où je suis me filtre les premières données envoyées par SSL de mon serveur vers le client étant donné le “RST,ACK” qui suit.
Où je suis surpris, c’est que le filtrage s’effectue:

1. Après la poignée de main
2. A destination d’un port 443 (https)

Quelqu’un pourrait-il me confirmer ma conclusion sur l’issue du problème?

D’autre part, je suis aussi preneur d’une explication sur comment ce type de filtrage peut être mis en place et quel est d’ailleurs la différence lorsqu’on utilise une connexion sécurisée pour accéder par exemple à ses informations bancaires?

Enfin, il y a peut être moyen de passer outre cela en configurant différemment le fichier de config sshd_config…

[ripat]

Essaye simplement de changer le port du serveur ssh pour voir. Mets-le en 80 temporairement. Ce port ne devrait pas être trop filtré par le firewall de ta boîte. Sinon, je ne vois pas de trop. Si tu veux je veux bien essayer de chez moi. Si intéressé, MP.

[homeostasie]

Essaye simplement de changer le port du serveur ssh pour voir. Mets-le en 80 temporairement. Ce port ne devrait pas être trop filtré par le firewall de ta boîte

C’est déjà fait et prêt pour un test demain!

Si tu veux je veux bien essayer de chez moi. Si intéressé, MP.

J’ai demandé à un pote de tester depuis son boulot et c’est passé nikel mais merci quand même. Clair que c’est difficile à déboguer quand on a qu’une seule adresse IP publique…

[homeostasie]

Ben voilà c’est cool, j’étais confronté à une règle de filtrage de la part de ma boîte.

Si quelqu’un a des explications sur mes précédentes questions complémentaires, ne pas hésiter!

A ciao.

[SpaTule]

On va pas tarder a venir te tirer les oreilles

Ta boite filtre manifestement le protocole ssh.

Solution :

–> Utiliser ajaxterm

Principe :

• Avoir un serveur apache avec support ssl
• Installer un virtual host en 443
• Activer et configuer un reverse proxy dans ton virtual host pointant vers localhost:8022 (c’est la que ecoute ajaxterm)

Conclusion: c’est génial

Depuis ta boite tu te connecte via un navigateur web en https :
ton_IP/ajaxterm/
et après tu peux geeker tranquilement sur ton serveur avec un joli temrinal dans ta apge web. Tu rajoute l’application “screen” pour avoir la gestion des multiple terminaux et après tu te rend compte que tu bosse plus chez toi qu’à ton vrai boulot :smt003

Je te laisse te renseigner sur tout ca il y a pas mal de tuto sur le net. Si jamais tu n’y arrive pas je pourrais toujours te donner des indications, je l’utilise tous les jours

[homeostasie]

On va pas tarder a venir te tirer les oreilles

Mais non, c’est pour la bonne cause (être plus productif), en ayant accès à plus d’informations sur le net, sans restrictions…

Sinon merci pour ces indications, ca sera un bon point de départ pour jeter un coup d’oeil et mettre cela en place.

Par contre, je pense que je peux faire aussi autrement pour avoir accès au net depuis le taf, notamment en utilisant un tunnel SSH (établie sur le port 80 dans mon cas) qui redirigera le trafic web du boulot (modification du proxy dans le navigateur vers le port d’écoute du tunnel) vers mon serveur Apache.

[SpaTule]

Si c’est comme dans mon cas,la solution du tunel fonctionnera mais sera detecté par les admin et donc il pourront de gronder. Ce n’est pas parce que tu fais un tunel dans le 80 qu’on ne voit pas le protocole ssh passé. Donjc si la politique de filtrage est basée, entre autre, sur les protocoles et bien ça va coincer.

C’est pour ça que la solution ajaxterm + https et vraiment intéressante, car la on ne voit passer que du https par le 443 ce qui est autorisé quasi partout

[edit]
Viens de m’apercevoir que tu parle “d’accès internet”. C’est plus la même chose la… Je pensais que tu voulais juste te connecter en ssh chez toi. Mas si tu n’as même pas accès au net alors pas d’ajaxterm possible. Quelles sont tes restrictions en fait ? Accès internet uniquement possible par un proxy d’authentification ? Dans ce cas le tunel ssh avec ecoute sur le 80 peut etre une solution, mais si le ssh n’est pas autorisé c’est foutu.

[homeostasie]

Si c’est comme dans mon cas,la solution du tunel fonctionnera mais sera detecté par les admin et donc il pourront de gronder.

Pas grave, c’est moi l’administrateur. Non je déconne!

Ce n’est pas parce que tu fais un tunel dans le 80 qu’on ne voit pas le protocole ssh passé. Donjc si la politique de filtrage est basée, entre autre, sur les protocoles et bien ça va coincer.

C’est juste!
Dans mon cas, sur le port 80, je n’ai pas la même politique de filtrage que que le port 443, c’est pour cela que ca fonctionnera.

C’est pour ça que la solution ajaxterm + https et vraiment intéressante, car la on ne voit passer que du https par le 443 ce qui est autorisé quasi partout

En effet, je m’y intéresserais prochainement de plus près…

[quote][edit]
Viens de m’apercevoir que tu parle “d’accès internet”. C’est plus la même chose la… Je pensais que tu voulais juste te connecter en ssh chez toi. Mas si tu n’as même pas accès au net alors pas d’ajaxterm possible. Quelles sont tes restrictions en fait ? Accès internet uniquement possible par un proxy d’authentification ? Dans ce cas le tunel ssh avec ecoute sur le 80 peut etre une solution, mais si le ssh n’est pas autorisé c’est foutu.[/quote]
En fait, j’ai dévié car je pensais que tu me parlais “d’accès à internet” dans ta solution… En effet, mon topic concerne l’établissement d’une connexion SSH.