Re: ssh temps d'attente

Top Page

Reply to this message
Author: Olivier Allard-Jacquin
Date:  
CC: Guilde Linux
Subject: Re: ssh temps d'attente
    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 !!