Retourner aux forums || Retourner au forum Linux.debian
Linux.debian : ssh possible uniquement depuis le réseau local
Posté par Kerro () le 13 janvier 2008je séche depuis deux jours sur un problème qui est probablement tout simple. Google m'a indiqué que d'autres personnes ont le même soucis... mais il n'y a personne qui trouve la réponse :-)
J'ai plusieurs machine Etch sur plusieurs sites. Tout baigne sauf pour une seule. Sur cette machine problématique, je peux me connecter en ssh depuis n'importe quelle autre machine située sur le même site. Si je tente une connexion depuis l'extérieur, niet. Ca me jette immédiatement avec "Access denied" sans même faire la pause de 2 secondes.
Je regarde dans /var/log/auth.log et surprise, aucune trace des connexions venant de l'extérieur. Me voilà fort déconcerté :-)
Tout ce qui concerne les connexions depuis le réseau local est bien là, et rien pour ce qui concerne l'extérieur.
Hem...
J'ai écarté l'hypothèse d'un problème avec PAM. J'ai mis pam_permit et rien de mieux. Sauf que n'importe quel mot de passe fonctionne :-)
Mais depuis l'extérieur, aucun changement.
Je ne pense pas que ce soit lié spécifiquement à Debian. C'est plutôt un soucis dû à sshd et/ou au dns.
La machine à problème a comme IP 192.168.50.1
Le modem/routeur ADSL est en 192.168.50.254
Si je me connecte depuis 192.168.50.x j'ai un comportement 'presque' normal. Le presque vient du fait que j'ai un délai de 10 secondes entre le moment où la connexion s'établie et la demande du mot de passe.
login as: toto
... 10 secondes ...
toto@192.168.50.1's password:
Si je fais la même chose sur un autre site, je n'ai pas ce délai. Ah, étrange. Alors je fais joujou avec 'host' :
Sur un serveur normal :
host 192.168.20.1
Host 1.02.168.192.in-addr.arpa not found: 3(NXDOMAIN)
ou
192.168.20.1 PTR record currently not present
ou
192.168.20.1 does not exist, try again
ou etc etc suivant les adresses demandées et les sites. Ce qui est normal, nous n'avons pas de dns interne, donc pas de résolution inverse. Dans tous les cas, la réponse est quasi immédiate.
Sur le serveur problématique :
host 192.168.50.1
... 10 ou 15 secondes ...
;; connection timed out; no servers could be reached
Tient donc.
Je soupçonne un problème de dns.
host linuxfr.org
linuxfr.org has address 212.27.33.221
;; Warning: Message parser reports malformed message packet.
... 10 ou 15 secondes ...
;; connection timed out; no servers could be reached
Houlala.
Bon ok, le modem/routeur fait office de relai dns. Il a un soucis, ou c'est Orange qui est mal configuré (oui, mais uniquement pour ce site ?).
Je mets un autre dns :
echo nameserver 81.253.149.9 > /etc/resolv.conf
note: c'est un dns de chez Orange.
Là les tests avec host, dig et ping donnent des résultats corrects.
Abondaccor, c'est le modem/routeur qui déconne.
Je note : changer le modem/routeur de ce site. Donner l'ancien à un concurrent.
Maintenant, si je me connecte depuis le réseau local, il n'y a plus le délai étrange de 10 secondes. Parfait, tout baigne. Problème résolu.
Ah non. Depuis l'extérieur ça ne fonctionne pas mieux.
J'ai toujours un délai entre 'user' et 'pass' mais seulement 2 ou 3 secondes, puis j'ai "Access denied" immédiatement. Toujours rien dans /var/log/auth.log
Je désactive le relai dns sur le modem/routeur au cas où. Pas mieux. Je fais éteindre/allumer le modem/routeur. Toujours rien.
Je séche.
Quelqu'un a une idée ?
Siouplait.
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi --
Alors ... extérieur ?
Il nous manque un millier de détails pour pouvoir te répondre.
Pour commencer, ça veut dire quoi « de l'extérieur » ? Si c'est depuis Internet, il est normal que tu ne puisse pas directement te connecter à une adresse interne en 192.168.x.x, ni la voir dans le DNS. Mais çà, je suppose que tu le sais :-) Je déduis également que tes autres machines fonctionnent de la même façon et se laissent être connectées.
Pour tes problèmes de timeout, cela peut provenir de deux choses :
1) Ta machine hôte utilise une paire d'adresses DNS qui n'est pas la même que celle des autres, et le premier DNS ne répond plus. Donc, à chaque accès à une machine par son nom, il faut attendre 15 secondes que la requête échoue par délai écoulé avant de se décider à passer au second.
2) Tu as un routage capricieux. Il y a un filtrage quelque part, soit sur ta machine avec une config iptables oubliée, soit dans un des switch/routeurs de ta chaîne, qui répond directement non (REJECT -> Message ICMP), soit envoie le paquet aux oubliettes (DROP).
-
[+] [^]A côté de la plaque
Posté par Kerro () le 13/01/2008 à 18:46. (lien). Évalué à -5.Tu es à l'ouest toi...
1) la fameuse paire d'adresse DNS dont tu parles, c'est je suppose le contenu de /etc/resolv.conf
Si tu avais lu, tu aurais constaté que j'ai changé le contenu de ce fichier.
Bon, pas grave, tu as dû passer à côté bêtement.
2 ) depuis quant un DROP permet tout de même de se connecter, puis de taper son login, puis son mot de passe, puis d'avoir un message d'erreur ?
Ha, effectivement, tu n'as pas lu. Dommage pour moi.
Je vais poser la question sur lea-linux :-)--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi ---
[^]Re: A côté de la plaque
Posté par Kerro () le 13/01/2008 à 19:17. (lien). Évalué à 0.C'est moi qui ai mal lu pour le 2)
Non, pas de firewall ou quoi que ce soit qui se mette en travers. Et même si il y a un problème de dns, je souhaite que ssh fonctionne. Donc dns en rade ou pas, peu importe.
Il ne manquerait plus que ssh refuse les connexions lorsque la résolution de nom locale est en panne.
Et pourtant, on dirait que c'est le cas.--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi --
-
[^]Re: A côté de la plaque
-
[^]Re: A côté de la plaque
-
à tout hazard...
tu te connectes en utilisant un nom de domaine ou une IP
pcq si tu essaie de te connecter sur toto.ton_domaine.com
mais que la machine est reglée avec autre chose comme hostname (mon_toto.mon_domaine.com)
ca peut lui poser des soucis pour comprendre qu'on s'adresse à elle.
(PS : enfin c'est une hypothese)
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux
-
[^]Re: à tout hazard...
Posté par Kerro () le 13/01/2008 à 21:03. (lien). Évalué à 1.Ce n'est pas cela non plus.
J'ai testé, au cas où. Ca ne change rien.
Sur une machine 'saine' ça ne change rien non plus. sshd ne vérifie pas cela je suppose.--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi --
routage/port forwarding
Rassure moi, tu fais bien le routage de ssh vers la machine cible ? si oui sur quel port ?
sinon ben http://www.commentcamarche.net/internet/nat.php3
-
[^]Re: routage/port forwarding
Posté par Kerro () le 13/01/2008 à 22:48. (lien). Évalué à 1.Puisque j'ai l'invite de login et de mot de passe, je crois bien que oui...
--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi ---
[^]Re: routage/port forwarding
Posté par Farvardin (page perso, ) le 14/01/2008 à 01:19. (lien). Évalué à 3.je présume que tu as bien les mêmes options d'activées entre chaque machine... ?
et sinon au niveau des ssh_host_rsa_key ou de known_hosts ces clés n'ont pas été modifiées depuis ? ce qui pourrait bloquer l'accès à la machine. J'ai déjà eu cela sur mon réseau, et cela mettait un "Access denied" du fait des clés rsa et co. Pour voir si c'est ça, essaye de te connecter depuis une autre machine à distance, sur le serveur qui pose problème., ou supprime ou renomme le fichier known_hosts--
Tous ensemble contre l'esclavitude des logiciels privateurs !
-
Côté TCPWrapper ?
Bonjour,
Pourrais tu regarder du côté du TCPWrapper (/etc/hosts.allow|deny) du serveur "capricieux" pour voir s'il n'y aurait pas ***par le plus grand des hazards *** un filtrage à ce niveau (voir [http://www.linuxforums.org/forum/suse-linux-help/37274-ssh-a(...)])
En outre, pourrais-tu faire un delta de "ssh -vv" (cf post de Barnabé [https://linuxfr.org/comments/895806.html#895806]) entre une connexion OK et une NOK à partir de la même source (pour avoir le même paramétrage côté initiateur de la connexion) ?
Enfin, pour compléter ma (longue) demande, pourrais-tu jeter un oeil sur le diff des configurations serveur (/etc/ssh/sshd_config ou autre) associé aux tests précédents afin de lever un doute sur le paramétrage côté serveur (voir [http://ubuntuforums.org/archive/index.php/t-7842.html]).
Merci d'avance & Bon Courage !
Cdlt,
PS: Merci à tous les autres posts pour leurs suggestions & leurs remarques :-)
-
[^]Un peu de douceur en ce bas monde
[+] Mauvais modem/routeur
J'en sais maintenant nettement plus sur l'origine du problème. Je suis aujourd'hui sur un second site qui vient juste d'avoir le même problème. Le serveur fonctionnait parfaitement bien au bureau et là, sur ce site, ssh impossible depuis l'extérieur. Et en plus la résolution d'adresses ne fonctionne pas du tout.
Le modem/routeur ADSL est un D-Link DSL-524T. Comme sur le premier site à problème. Ahhh...
Je fouille un peu plus.
En attendant, je met en dur dans /etc/resolv.conf les adresses des serveurs dns de chez Orange. Je mettrais un vrai serveur dns localement plus tard.
Cela dit, le ssh depuis l'extérieur ne fonctionne pas mieux, il y a donc autre chose qui gène. Probablement 'dans' le modem/routeur. Dès que j'en sais plus, je poste ici.
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi --
-
[^]Re: Mauvais modem/routeur
Posté par Pipo Le Clown () le 14/01/2008 à 14:04. (lien). Évalué à 4.T'aurais du commencer par la...
Ce machin est une bouse immonde... je le sais j'ai le meme chez moi :/
Malgré le fait que tu rediriges les ports... bah il le fait pas.
Explication:
Ce modem/routeur a un serveur ssh interne, ainsi qu'un serveur web.
Meme en redirigeant explicitement les ports 22 et 80 vers une adresse interne, tu accedes toujours au ssh et web du modem/routeur \o/. Pour le web on peut changer le port du serveur.... Pour le ssh je sais pas comment faire, et si tu trouves, ca m'interesse.
PS: C'est du busybox inside
PS2: tu n'a rien dans /var/log/auth parce que tu ne pointes pas sur ton serveur mais sur le modem/routeur (le mot de passe par défaut doit etre admin il me semble)-
[^]Re: Mauvais modem/routeur
Posté par Kerro () le 14/01/2008 à 17:46. (lien). Évalué à 1.Merci Pipo Le Savant, c'est la réponse qui explique tout :-)
Je confirme que les ports 22 et 80 ne sont pas redirigeables. Et pour changer le 22, pas trouvé non plus.
J'ai essayé en redirigeant le port externe 23 vers le port interne 22. Ca fonctionne. Ce n'est pas ce que je souhaite, mais ça fonctionne.
J'ai essayé en mettant en place la pseudo-dmz, mais 22 et 80 restent tout de même interceptés par le modem/routeur.
Et bien évidement /var/log/auth.log reste vierge, on comprend maintenant pourquoi.
A vendre : lot de 16 modem/routeur D-Link DSL-524T état neuf. 6 ne sont même pas déballés :-)
Une idée pour un modem/routeur ADSL dans les mêmes prix (car celui-ci n'est vraiment pas cher) avec sortie Ethernet ?--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi ---
[^]Re: Mauvais modem/routeur
Posté par Etienne () le 15/01/2008 à 14:18. (lien). Évalué à 1.Est-ce que en se connectant en ssh sur le modem/routeur, il n'y a pas moyen changer le port d'écoute du serveur ssh interne ? Si c'est un serveur dropbear (courant pour l'embarqué), il faut regarder d'où il est lancé et changer le script pour ajouter l'option -p qui va bien (il est peut-être lancé par inetd, il faut alors changer la conf de inetd pour écouter sur un autre port)
Etienne
-
-
[^]Changement du microprogramme
Posté par Kerro () le 03/02/2008 à 19:32. (lien). Évalué à 1.J'ai (enfin) trouvé.
Un nouveau microcode est disponible chez D-Link depuis pas mal de temps. Parmis les 'nouveautés' il y a :
Disable the SSH port 22 in WAN side by default
Par contre ça ne résoud pas le problème de DNS qui foire avec des clients Linux. Là, il faudra m'expliquer comment ils ont réussi à se vautrer, aussi bien chez D-Link que pour Linux.--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi ---
[^]dproxy
Posté par Kerro () le 03/02/2008 à 21:03. (lien). Évalué à 1.J'avance, j'avance...
Le routeur utilise dproxy qui fait office de cache et de relais pour les requêtes dns. Pas de bol, ce programme répond n'importe quoi lorsqu'on lui demande un enregistrement AAAA, ce qui fait planter les bibliotèques dns de la famille Debian. Et surement d'autres familles.
Les nouveaux microcodes de chez D-Link ne corrigent pas cela.
J'ai regardé du côté de http://openwrt.org/ mais leur microcode pour le D-Link DSL-524T grille les modems :-)
Il reste la solution de tout simplement prendre le microcode original de chez D-Link et de simplement changer dproxy. Je viens de récupérer le tar, je regarde ça demain.--
--- Dans un restaurant, Chuck Norris a commandé un steak. Le steak a obéi --
-
-
Revenir en haut de page || Retourner aux forums || Retourner au forum Linux.debian
Cette page a été générée par Templeet en 0.0824s (dont 0.0078 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.