Bonjour à tous,
je 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.
Forum Linux.debian/ubuntu ssh possible uniquement depuis le réseau local
13
jan.
2008
# Alors ... extérieur ?
Posté par Obsidian . Évalué à 2.
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 . Évalué à -5.
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 :-)
[^] # Re: A côté de la plaque
Posté par Kerro . Évalué à 0.
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.
[^] # Re: A côté de la plaque
Posté par Barnabé . Évalué à 8.
- Essaie ssh -vv depuis l'exterieur
- Essaie de rester poli avec les personnes qui tentent de t'aider.
[^] # Re: A côté de la plaque
Posté par snt . Évalué à 9.
Quand on est pas capable de faire un ssh depuis l'exterieur, on répond plus gentillement aux gens qui essayent d'aider :-p
# à tout hazard...
Posté par NeoX . Évalué à 1.
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)
[^] # Re: à tout hazard...
Posté par Kerro . Évalué à 1.
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.
# routage/port forwarding
Posté par finss (site web personnel) . Évalué à 1.
sinon ben http://www.commentcamarche.net/internet/nat.php3
\_o<
[^] # Re: routage/port forwarding
Posté par Kerro . Évalué à 1.
[^] # Re: routage/port forwarding
Posté par B16F4RV4RD1N . Évalué à 3.
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
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Côté TCPWrapper ?
Posté par Steve Azriel . Évalué à 1.
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
Posté par Kerro . Évalué à 0.
# Mauvais modem/routeur
Posté par Kerro . Évalué à -1.
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.
[^] # Re: Mauvais modem/routeur
Posté par Pipo Le Clown . Évalué à 4.
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 . Évalué à 1.
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 ?
[^] # Re: Mauvais modem/routeur
Posté par Étienne . Évalué à 1.
Etienne
[^] # Changement du microprogramme
Posté par Kerro . Évalué à 1.
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.
[^] # dproxy
Posté par Kerro . Évalué à 1.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.