SME7 - Pb ssh, erreur de dns?

[Argenlos]

Bonsoir,

Aujourd'hui, j'ai mis à jour un serveur SME7 de la RC1 à la RC2. La mise à jour c'est réalisée correctement sans problème.

Mais je m'apperçois, de quelque chose d'étrange, lorsque je me connecte via ssh sur ce serveur qui est dans le LAN, j'ai cette erreur:

Code: Tout sélectionner

argenlos@ubuntu:~$ ssh 192.168.0.x -l root
root@192.168.0.x's password:
reverse mapping checking getaddrinfo for pc-00002.argenlos.dyndns.org failed - POSSIBLE BREAKIN ATTEMPT!
Last login: Thu May  4 20:56:36 2006 from 192.168.0.2
[root@sme ~]#


Tout comme dans [url="http://contribs.org/modules/pbboard/viewtopic.php?t=30812&sid=c6ee30211478546de4fcf490422898bf"]ce post[/url] sur Contribs.org

Je me demande pourquoi il me donne cette erreur, pourquoi un problème de dns?

Pour information ce serveur est monté en serveur simple.

J'ai utiliser notre amis Google, mais rien...
Je suis aller voir le bugtrack sur contribs.org, rien non plus.

Avez-vous une idée?


Merci.

P.S: Dans les logs il n'y a rien

[sibsib]

Hello,

Il est fait mention de troubles non vraiment déterminés au niveau DNS dans certains cas de conf en serveur seul avec un dns externe. (Enfin, il me semble...)
Au niveau de ta conf, le serveur SME est serveur DNS ?
As-tu un IPCop entre SME et ton P.C. (çe serait alors peut-être une résurgence d'un bug de SME 6 au niveau du reverse DNS des autres réseaux)?
Sur ton sme, que donne

Code: Tout sélectionner

host -d 192.168.0.2

?

Toussa, toussa...

A+,
Pascal

[Argenlos]

Bonjour Sibsib,

Mon serveur ne sert pas de dns.
Ce serveur est configuré pour pointer vers le routeur pour toutes adresses externes, et ce dernier est lui même configuré sur le dns du FAI.

Je n'ai pas d'IPcop, juste un routeur firewall (DLINK).


internet
|
|
|
routeur/firewall (192.168.0.1)---------(192.168.0.2)PC1
|
|
|
(192.168.0.11)sme (http+messagerie)



Je posterai le résultat de la commande ce soir.

Cordialement,

[Argenlos]

Bonsoir à tous,

Voici donc le résultat de la commande, comme promis: host -d 192.168.0.2

Code: Tout sélectionner

argenlos@ubuntu:~$ ssh 192.168.0.11 -l root
root@192.168.0.11's password:
reverse mapping checking getaddrinfo for pc-00002.argenlos.dyndns.org failed - POSSIBLE BREAKIN ATTEMPT!
Last login: Thu May  4 21:24:33 2006 from 192.168.0.2
[root@sme ~]# host -d 192.168.0.2
Trying "2.0.168.192.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54608
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.168.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
2.0.168.192.in-addr.arpa. 10569 IN      PTR     pc-00002.argenlos.dyndns.org.

Received 84 bytes from 192.168.0.11#53 in 12 ms
[root@sme ~]#

J'avoue ne pas bien comprendre le résultat...mon PC (192.168.0.2) est identifié comme étant "pc-00002.argenlos.dyndns.org" par mon serveur SME? C'est bien cela?

[Mode hypothèse haute voltige]
Admettons que ce soit cela:

Hum...sachant que je n'ai pas de dns dans mon réseau, j'ai demandé à tous mes postes (qui sont en DHCP - rôle donné au routeur) implicitement de se baser sur le dns du FAI via le routeur pour toutes traductions d'adresses.
Idem pour mon serveur (adresse fixe), il se référe aux enregistrements de mon FAI.
Donc les postes de mon LAN n'étant pas reconnu par mon serveur (le serveur interroge peut être le dns du FAI, mais mon FAI n'est pas cencé connaitre mon LAN ) je me retrouve avec un nom attribué au hasard par le serveur sme (en l'occurance "pc-00002.argenlos.dyndns.org") ?
SME n'étant pas sûr de la provenance de la connexion m'informe d'une possible intrusion? (il m'informe d'un intrusion lors de la connexion, mais rien dans les log, ce n'est pas logique)


Est-ce clair?
Pour vous c'est cela?
Je divague? (pas obligé de repondre à cette question)
[/Mode hypothèse haute voltige]


Cordialement,

[sibsib]

Hello,

Là, je suis au boulot, en attente d'une nuit de haute voltige... Je n'ai pas de SME sous la main, donc.

Ceci dit :

SME 7 diffère à mon avis (pourquoi mon avis : il s'agit d'un truc constaté, mais que je n'ai pas validé, je préfère donc prendre des pincettes) de SME 6 en ce sens que, même configuré pour utiliser un DNS externe, il se base sur lui pour ce qu'il considère comme sa zone d'autorité.

D'autre part, depuis SME 6, le dns crée des entrées type pc-00002 pour toutes les adresses IP du LAN local.

Donc oui, un P.C. en 192.168.0.2 est connu dans le DNS local comme pc-00002 et inversement.

Là, je ne connais pas de différences entre SME 7 rc 1 et SME 7 rc 2. (J'ai peu pravaillé avec un DNS externe en rc 2, il faut dire !)

Par contre, tous les protocoles dde type rsh et ssh font une double résolution DNS :
La station qui se connecte présente une IP
Le serveur convertit cette IP en nom (notamment pour consulter les fichiers genre hosts.allow et hosts.deny) et fait ensuite une conversion nom vers IP pour contrôle.
Il se pourrait (là aussi, haute voltige !) que les contrôles aient étés renforcés : avant, l'absence de résolution DNS était peut-être tolérée, maintenant plus.
Mais également possilbe : un changement au niveau de la configuration de ta zone dyndns.org, ou un changement da nom de domaine ou de host.

Une possibilité, peut-être pour résoudre temporairement ton problème et essayer de pointer le trouble : ajoute

Code: Tout sélectionner

192.168.0.2 pc-00002.argenlos.dyndns.org

dans ton fichier /etc/hosts pour voir ce que çà donne.

A+,
Pascal

[Argenlos]

Re bonsoir,

Et bien que de vols planés


J'avais bien pensé à faire cela:

Une possibilité, peut-être pour résoudre temporairement ton problème et essayer de pointer le trouble : ajoute

Code: Tout sélectionner

192.168.0.2 pc-00002.argenlos.dyndns.org

dans ton fichier /etc/hosts pour voir ce que çà donne.

Et en effet, cela fonctionne correctement, plus de message d'alerte.

Code: Tout sélectionner

argenlos@ubuntu:~$ ssh 192.168.0.11 -l root
root@192.168.0.11's password:
Last login: Fri May  5 20:13:22 2006 from 192.168.0.2
[root@sme ~]#


De plus, aprés réflexion, je pense que c'est une volonté de l'équipe de dév. de vouloir ce fonctionnement.

Il se pourrait (là aussi, haute voltige !) que les contrôles aient étés renforcés : avant, l'absence de résolution DNS était peut-être tolérée, maintenant plus.

Je vais peut être laisser un message sur contribs.org, voir le bugtrack...

Merci pour les idées et les avis.

A bientôt.

[Methos_Hi]

C'est probablement une option de sshd qui fait un test de reverse DNS.
Cela doit être désactivable.