Bonjour,
Patrick Begou wrote:
>
> Tu peux aussi vérifier que ton sshd n'est pas lancé par le serveur
> xinetd sur la machine distante. C'est rare mais c'est une conf possible
> sur les machines performantes (car il doit s'initialiser à chaque fois).
Personnellement, je lance le plus de démons possible via xinetd
(proftpd, ssh, sftp, etc...) :
- cela permet de ne pas avoir ces démons en mémoire tout le temps, d'où
économie de ressources
- si je change la configuration de ces démons (modification du
/etc/ssh/sshd_config par exemple), il n'est pas nécessaire de redémarrer
le demon ssh ou xinetd : les changements seront pris à la prochaine
connexion par un client
- xinetd permet une sécurité supplémentaire par rapport aux demons. Par
exemple, sur une machine multi interfaces réseau (eth0 et ppp0 par
exemple), il permet d'indiquer sur quelles interfaces les démons seront
accessibles, ou non (
http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-05.html#II-5-5
). Il permet aussi de régler la manière dont les démons sont vu (définit
de ports en fonctions des différentes interfaces par exemple), etc...
Bref, xinetd a de nombreux avantages... ;)
Je viens de faire quelques 4 tests sur un serveur ssh (Mandrake 10.0 /
kernel 2.6.3-16mdk / OpenSSH 3.6.1p2 / clef par défaut de 768 bits) :
- 2 connexions depuis un client SSH en LAN (câble croisé, 2m), avec une
configuration xinetd+sshd. Temps de réponse : 3.5s à 4s pour la demande
de mot de passe.
- 2 connexions avec le même client SSH, mais avec une configuration
"pure serveur ssh". Temps de réponse : 3s à 3.5s.
La solution du xinetd ne semble donc faire perdre que 500ms.
Cyril, pour ton problème de vitesse de connexion, je te conseille :
- de lancer ton client ssh en mode verbeux (-v), très verbeux (-vv),
très très verbeux (-vvv), afin de voir à quel moment il y a de l'attente
entre ton client et ton serveur.
+ Chez moi, avec ssh -vvv mon_serveur_ssh, j'ai un peu d'attente entre
ces 2 lignes :
debug1: identity file /home/olivier/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.6.1p2
Cela correspond au lancement de sshd par xinetd
et encore plus entre
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
Là, c'est la fin de l'échange des clefs.
- de lancer un "strace" sur le serveur, avec affichage du temps système
: strace -f -tt -o /tmp/strace_sshd.txt -p pid_de_ssh
pour avoir le "pid_de_ssh", tu lances en temps que root :
[root@phoenix root]# netstat -taupn grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4350/xinetd
"4350" est le PID du serveur ssh (là c'est en fait xinetd qui écoute
pour le compte du serveur ssh).
A plus,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
