"Connection time out" avec SSH

Bonjour,

Je rencontre un problème assez étrange avec SSH : j'essaie de me connecter sur mon serveur personnel (sous Debian) via mon ordinateur portable (Fedora 17) depuis mon lieu de travail. Je lance donc la commande ssh (dont j'ai changé le port) et là il ne se passe rien pendant bien une à deux minutes, puis je reçois le message d'erreur "ssh: connect to host * port *: Connection timed out". Par contre j'arrive très bien à me connecter avec les ordinateurs de mon lieu de travail (Fedora 15) ou en local (et je me souviens m'être déjà connecté depuis l'extérieur). Donc le firewall du serveur (et de la freebox) est bien configuré pour laisser entrer SSH sur le port modifié et j'ai beau eu cherché je ne vois aucune explication.

Merci d'avance.

Il est fort probable que d'une part les règles de filtrage appliquées par ton administrateur système aux connexions des portables personnels soient autrement plus restrictives que celles en vigueur sur les machines officielles de ta compagnie et que, d'autre part, tous les ports non habituels (22, 80, 443,…) soient filtrés silencieusement et sans autre forme de procès, d'où le timeout plutôt qu'un refus de connexion explicite.

Fais des tests avec tcpdump, par exemple, pour voir si le trafic circule bien et, surtout, pose la question à ton assistance technique. C'est probablement de cette façon que tu obtiendras le plus rapidement la raison de tout cela.

Je suis passé voir l'admin réseau en premier lieu, mais il m'a dit que les connexions sortantes n'étaient pas filtrées. Et n'apparait a priori dans les logs.
En tout cas je confirme que ça vient du réseau là-bas, la connexion fonctionne lorsque je me connecte depuis un autre endroit.

J'essaierai ce que tu me conseilles demain, merci pour ton aide.

Voici ce que me donne la commande tcpdump :

Code:

---

1 2 3 4

# tcpdump -vv -i p3p1 'port x' tcpdump: listening on p3p1, link-type EN10MB (Ethernet), capture size 65535 bytes 11:00:23.920054 IP (tos 0x0, ttl 64, id 4088, offset 0, flags [DF], proto TCP (6), length 60) netbook.51244 > *-*-*-*-219-9.fbx.proxad.net.ibm-cics: Flags [S], cksum 0xbb85 (incorrect -> 0x1d7d), seq 943855411, win 14600, options [mss 1460,sackOK,TS val 1841355 ecr 0,nop,wscale 7], length 0

---

et le message se répète plusieurs fois, avec un checksum différent après "incorrect ->".
J'ai comparé avec ce que j'obtiens en me connectant sur un ordi interne au réseau (donc port 22), et je n'obtiens pas le message concernant le checksum invalide, et les flags sont dans l'ordre S, S., ., P., ., P., ., etc.
Je vais retourner voir l'admin réseau pour lui rapporter le fait que ça marche en dehors et donc que ce doit être filtré quelque part.

La valeur de chesksum incorrecte, c'est une chose, mais je vois surtout un paquet sortant (de netbook vers fbx.proxad.net) qui ne reçoit aucune réponse.

Est-ce que tu obtiens d'autres résultats lorsque tu essaies de te connecter via le même port à une autre machine extérieure (n'importe laquelle, même si elle n'est pas ouverte) et, réciproquement, parviens-tu à atteindre ta box en l'attaquant sur le port 22 (il y a des chances, cela dit, pour qu'elle-même absorbe silencieusement les paquets qu'elle filtre).

La connexion sur le port 22 est simplement refusée :

Code:

---

1 2	$ ssh *.219.9 ssh: connect to host *.219.9 port 22: Connection refused

---

Ce matin je suis retourné voir l'admin réseau, ainsi que son collègue. Ils m'ont expliqué qu'en fait les ordis portables ont une plage DHCP réservée (sachant qu'ils attribuent parfois une IP fixe dans cette plage, comme dans mon cas) et que tout ordi de cette plage se connecte vers l'extérieur via une mascarade d'adresse (machine X). Et quand on se connecte en SSH (en interne) sur X, alors la connexion vers l'extérieur depuis cette machine ne fonctionne pas, quel que soit le port (sauf 22), et ce même vers d'autres serveurs (que le port soit ouvert ou fermé sur l'autre machine).
Donc clairement cela vient de la machine qui fait la mascarade, mais ils n'ont aucune idée de la raison (ils ont vérifié les logs, la config SSH et le parefeu, et rien n'apparait en rapport avec ça).
Au final ils m'ont conseillé de revenir sur le port 22, car le changer n'améliore pas réellement la sécurité face aux attaques.

En tout cas merci pour ton aide.

Citation:

---

Envoyé par Melsophos

Et quand on se connecte en SSH (en interne) sur X, alors la connexion vers l'extérieur depuis cette machine ne fonctionne pas, quel que soit le port (sauf 22), et ce même vers d'autres serveurs (que le port soit ouvert ou fermé sur l'autre machine).

---

Comment ça, « sur X » ?

Citation:

---

Donc clairement cela vient de la machine qui fait la mascarade, mais ils n'ont aucune idée de la raison (ils ont vérifié les logs, la config SSH et le parefeu, et rien n'apparait en rapport avec ça).

---

J'avais un DSI et des admins système mégalo aussi, qui nous avaient installé un chouette firewall BSD en stateful, avec analyse active des trames, etc. Sauf qu'ils ne savaient pas l'administrer aussi bien qu'ils le croyaient, que les faux positifs arrivaient très vite et que le firewall concerné gelait la connexion au premier d'entre eux. C'est vite devenu inexploitable.

Citation:

---

Au final ils m'ont conseillé de revenir sur le port 22, car le changer n'améliore pas réellement la sécurité face aux attaques. En tout cas merci pour ton aide.

---

Super, ouais.
En tout état de cause, s'il y a une passerelle fixe dans ta boîte qui s'occupe de faire la sortie, je te suggère de laisser ton serveur sshd sur l'autre port et de faire une redirection statique de port entre 22 et le port choisi seulement lorsque l'adresse distante est celle de cette passerelle. Ça limitera beaucoup les risques.

Citation:

---

Envoyé par Obsidian

Comment ça, « sur X » ?

---

Désolé pour l'expression, j'ai utilisé X pour le nom du serveur, comme j'aurais pu dire toto.

Citation:

---

Envoyé par Obsidian

En tout état de cause, s'il y a une passerelle fixe dans ta boîte qui s'occupe de faire la sortie, je te suggère de laisser ton serveur sshd sur l'autre port et de faire une redirection statique de port entre 22 et le port choisi seulement lorsque l'adresse distante est celle de cette passerelle. Ça limitera beaucoup les risques.

---

Merci pour ce conseil, je vais voir pour faire ça.