Bonsoir Vincent,
Regis Gras a écrit :
> Bonjour,
>
> J'ai une machine (Fedora 4 Kernel l-2.6.15 ) sur laquelle j'ai cette
> erreur
> dans /var/log/secure.
> Ce qui est surprenant, c'est que cette erreur n'empeche pas ssh de
> fonctionner
> puisque des connections ssh sont encore acceptées.
> Sont encore acceptées, mais pas depuis n'importe quelle machine autorisée.
> Pour certaine, une tentative de connection se traduit par un rejet.
>
> Sur google cette erreur est référencée plusieur fois, mais je ne trouve pas
> de solution.
>
> Relancer ssh ne sert à rien.
>
> Aucun process ne semble utiliser le port 22 de maniere anormale
> netstat -apntu donne:
> tcp 0 0 :::22
> :::* LISTEN 18092/sshd
> tcp 0 0 ::1:6010
> :::* LISTEN 28279/1
> tcp 0 0 ::ffff:193.54.242.49:22
> ::ffff:152.77.14.207:37142 ESTABLISHED 28279/1
>
> Le port 37142 est bien celui qui est referncé dans /var/log/secure
>
> Accepted password for xxx from 152.77.14.207 port 37142 ssh2
>
> Je ne vois pas pourquoi certaines connections ssh sont acceptées et pas
> d'autres.
> Avez vous une idée sur ce probléme ?
J'ai déjà répond à cette question en... 2005 :)
Comme dit Vincent, le problème vient que le démon SSH écoute en IPV6, et
qu'il veut aussi écouter en IPv4.
Une partie de la discussion est archivé ici :
http://www.guilde.asso.fr/lurker/thread/20050811.212141.3a17bad3.en.html#20050811.212141.3a17bad3
et voici une autre partie qui n'a pas été archivé par le robot de la
Guilde :
<mail>
Bonsoir Jean-Marc,
Jean-Marc Coursimault a écrit :
> > Bonjour Olivier,
> >
> >
>> >> De plus, est-ce que par hasard :
>> >>[root@]# netstat -taupn | grep 22
>> >>
>> >>donne :
>> >>tcp 0 0 :::22 :::* LISTEN 8158/sshd
> >
> >
> > Bien vu. L'option -4 au démarrage de sshd supprime le problème !
> >
> > Reste à voir si mon système est configuré pour ipv6 alors que ma
connexion
> > réseau ne l'est pas ou bien si sshd devrait avoir l'option -4 "de base".
Je viens de faire quelques tests sur une Mandrake 10.2 (je n'ai pas de
10.1 sous la main...). Ton problème est bien le fait que tu ais une
carte réseau configuré en ipv6.
Chez moi, j'avais supprimé l'ipv6 car je n'en n'avais pas l'utilité.
Mais si je le réactive, voila ce que j'obtiens :
[root@]# ifconfig
...
sit0 Lien encap:IPv6-dans-IPv4
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
...
Ceci est une émulation de ipv6 sur de l'IPv4.
A partir de ce moment là, si je fait un "service sshd restart",
j'obtiens dans le "/var/log/messages", le même message que toi :
Aug 12 23:22:00 t-40 sshd[8129]: Server listening on :: port 22.
Aug 12 23:22:00 t-40 sshd[8129]: error: Bind to port 22 on 0.0.0.0
failed: Address already in use.
Aug 12 23:22:00 t-40 sshd: démarrage succeeded
De même que :
[root@]# netstat -taupn | grep 22
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program
tcp 0 0 :::22 :::* LISTEN 7629/sshd
^^^^^ ^^^^
Le problème vient donc de l'interaction entre sshd et ipv6.
Si tu veux supprimer le support de ipv6 (à condition que tu n'en n'ai
pas besoin), il faut :
- Modifier le "/etc/sysconfig/network", et rajouter :
NETWORKING_IPV6=no
- Rebooter la machine
Le reboot n'est à priori pas obligatoire, et un simple "service network
restart" devrait normalement suffire. Cependant dans mes tests je n'ai
pas réussi à retrouver exactement la configuration initiale (sans ipv6),
car notamment "sshd" voulait toujours se configurer avec ipv6. La
commande "lsmod" indiquait que le module "ipv6" était utilisé par 6
process, et je n'ai pas réussi à les retrouver. Donc le reboot était la
seule solution.
> > Je croyais qu'un seul processus à la fois pouvait écouter sur un
port TCP
> > donné. Il faut que je révise sérieusement mes bouquins réseau...
C'est le cas. Mais dans le cas de sshd, de proftpd, httpd, et de tout
les autres demons capables de traiter plusieurs requêtes en même temps,
seul le processus PERE ouvre le port de communication (22, 21, 80,
etc...). C'est lorsqu'une nouvelle communication arrive que le processus
père FORK, et c'est le nouveau fils qui prend en charge la
communication. Car ce fils bénéficie de tout l'environnement du père (et
donc de la nouvelle session ouverte par le nouveau client).
> > Je peux te faire passer mon fichier de conf, mais le problème me semble
> > résolu. Si tu veux le reste des infos, pas de pb !
Non c'est bon. Modifie ton "/etc/sysconfig/network", reboote la
machine, et le problème de sshd devra disparaître.
> > En tout cas, merci beaucoup !
Je t'en prie.
A plus,
Olivier
</mail>
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
