Pourquoi ma connexion SSH est-elle lente ?

Essayez de régler UseDNS sur no dans /etc/sshd_config ou /etc/ssh/sshd_config.

Quand j'ai fait tourner ssh -vvv sur un serveur avec une performance aussi lente, j'ai vu un accrochage ici :

debug1: Next authentication method: gssapi-with-mic

En modifiant /etc/ssh/ssh_config et en commentant cette méthode d'authentification, j'ai obtenu des performances de connexion normales. Voici ce que j'ai dans mon /etc/ssh/ssh_config sur le serveur :

GSSAPIAuthentication no

Vous pouvez le définir globalement sur le serveur, de sorte qu'il n'accepte pas GSSAPI pour s'authentifier. Il suffit d'ajouter GSSAPIAuthentication no à /etc/ssh/sshd_config sur le serveur et de redémarrer le service.

Pour moi, le coupable était la résolution IPv6, c'était le temps mort. (Mauvais réglage DNS chez mon hébergeur, je suppose.) J'ai découvert cela en faisant ssh -v, ce qui a montré quelle étape était en suspens.

La solution est de faire ssh avec l'option -4 :

ssh -4 me@myserver.com

Avec systemd, la connexion peut être bloquée sur la communication dbus avec logind après quelques mises à jour, alors vous devez redémarrer logind

systemctl restart systemd-logind

Vu que sur debian 8, arch linx, et sur une liste suse

Vous pouvez toujours commencer ssh avec l'option -v qui affiche ce qui est fait en ce moment.

$ ssh -v you@host

Avec les informations que vous avez données, je ne peux que suggérer quelques configurations côté client :

• Puisque vous écrivez que vous entrez les mots de passe manuellement, je vous suggère d'utiliser l'authentification par clé publique si possible. Cela vous évitera d'être un goulot d'étranglement pour la vitesse.

• Vous pouvez également désactiver le X-forwarding avec -x et l'authentification forwarding avec -a (ceux-ci peuvent déjà être désactivés par défaut). La désactivation du X-forwarding en particulier peut vous permettre d'améliorer considérablement la vitesse si votre client doit démarrer un serveur X pour la commande ssh (par exemple sous OS X).

Tout le reste dépend vraiment des types de retards que vous subissez, où et quand.

En ce qui concerne le point 2, voici une réponse qui ne nécessite pas de modifier le serveur ni d'avoir des privilèges de root/administratifs.

Vous devez modifier votre fichier “user ssh_config” qui est :

vi $HOME/.ssh/config

(Note : vous devrez créer le répertoire $HOME/.ssh s'il n'existe pas)

Et ajouter :

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Vous pouvez le faire par hôte si nécessaire :) exemple :

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Assurez-vous que l'adresse IP correspond à celle de votre serveur. Un avantage intéressant est que maintenant ssh fournira l'autocomplétion pour ce serveur. Vous pouvez donc taper ssh lin + Tab et il devrait s'autocompléter à ssh linux-srv.

Vérifiez /etc/resolv.conf sur le serveur pour vous assurer que le serveur DNS, listé dans ce fichier, fonctionne bien, et supprimez tout DNS non fonctionnel.

Parfois, c'est très utile.

Outre les problèmes de DNS déjà mentionnés, si vous vous connectez à un serveur avec de nombreux montages NFS, il peut y avoir un délai entre le mot de passe et l'invite car la commande quota vérifie votre usage/quota sur tous les systèmes de fichiers non montés avec la commande noquota. Sur les systèmes Solaris, vous pouvez voir cela dans le /etc/profile par défaut et l'ignorer en exécutant touch $HOME/.hushlogin .

Si aucune des réponses ci-dessus ne fonctionne et que vous rencontrez des problèmes de recherche inversée dns, vous pouvez également vérifier si nscd (nom du service de cache daemon) est installé et fonctionne.

Si c'est le problème, c'est parce que vous n'avez pas de cache dns, et chaque fois que vous demandez un nom d'hôte qui n'est pas sur votre fichier d'hôte, vous envoyez la question à votre serveur de nom au lieu de regarder dans votre cache

J'ai essayé toutes les options ci-dessus et la seule modification qui a fonctionné a été de démarrer nscd.

Vous devez également vérifier l'ordre de résolution de la requête dns dans /etc/nsswitch.conf pour utiliser le fichier hosts en premier.

Ceci n'est probablement spécifique qu'à l'OpenSSH Debian/Ubuntu, qui comprend le fichier user-group-modes.patch écrit par l'un des responsables du paquet Debian. Ce patch permet aux fichiers ~/.ssh d'avoir le bit d'écriture de groupe (g+w) s'il n'y a qu'un seul utilisateur avec le même gid que celui du fichier. La fonction secure_permissions() du correctif effectue cette vérification. L'une des phases de la vérification consiste à passer en revue chaque entrée de mot de passe à l'aide de getpwent() et à comparer le gid de l'entrée avec celui du fichier.

Sur un système avec de nombreuses entrées et/ou une authentification NIS/LDAP lente, cette vérification sera lente. nscd ne met pas en cache les appels getpwent(), donc chaque entrée de mot de passe sera lue sur le réseau si le serveur n'est pas local. Sur le système que j'ai trouvé, cela a ajouté environ 4 secondes pour chaque invocation de ssh ou de connexion au système.

La correction consiste à supprimer le bit inscriptible sur tous les fichiers dans ~/.ssh en faisant chmod g-w ~/.ssh/*.

Note : Cela a commencé comme un “Comment déboguer”, tutoriel, mais a fini par être la solution qui m'a aidé sur un serveur Ubuntu 16.04 LTS.

TLDR : Lancez landscape-sysinfo et vérifiez si cette commande prend beaucoup de temps pour se terminer ; c'est l'impression des informations système sur un nouveau login SSH. Notez que cette commande n'est pas disponible sur tous les systèmes, c'est le paquet landscape-common qui l'installe. (“Mais attendez, il y a plus…”)

Démarrez un second serveur ssh sur un autre port de la machine qui a le problème, faites-le en mode débogage, ce qui ne le fera pas bifurquer et imprimera des messages de débogage :

sudo /usr/sbin/sshd -ddd -p 44321

se connecter à ce serveur depuis une autre machine en mode verbeux :

ssh -vvv -p 44321 username@server

Mon client sort les lignes suivantes juste avant de commencer à dormir :

debug1: Entering interactive session.
debug1: pledge: network

Googler ce n'est pas vraiment utile, mais les journaux du serveur sont meilleurs :

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

J'ai remarqué que lorsque je change UsePAM yes en UsePAM no alors ce problème est résolu.

n'est pas lié à UseDNS ou à un autre paramètre, seul UsePAM affecte ce problème sur mon système.

Je ne sais pas pourquoi, et je ne laisse pas non plus UsePAM à no, parce que je ne sais pas quels sont les effets secondaires, mais cela me permet de continuer à enquêter.

Alors s'il vous plaît, ne considérez pas cela comme une réponse, mais comme un premier pas pour commencer à trouver ce qui ne va pas.

Donc j'ai continué à enquêter, et j'ai fait sshd avec strace (sudo strace /usr/sbin/sshd -ddd -p 44321). Cela a donné le résultat suivant :

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

La ligne /etc/update-motd.d m'a rendu suspect, apparemment le processus attend le résultat de ce qui est dans /etc/update-motd.d

Donc j'ai cd dans /etc/update-motd.d et j'ai lancé un sudo chmod -x * afin d'empêcher PAM d'exécuter tous les fichiers qui génèrent ce Message Of The Day dynamique, ce qui inclut la charge du système et si les paquets doivent être mis à jour, et cela a résolu le problème.

Il s'agit d'un serveur basé sur un processeur N3150 “économe en énergie” qui a beaucoup de travail à faire 24 heures sur 24, 7 jours sur 7, donc je pense que collecter toutes ces motd-data était juste trop pour lui.

Je peux commencer à activer les scripts dans ce dossier de manière sélective, pour voir lesquels sont moins nocifs, mais appeler spécialement landscape-sysinfo est très lent, et 50-landscape-sysinfo appelle effectivement cette commande. Je pense que c'est celle qui provoque le plus grand retard.

Après avoir réactivé la plupart des fichiers, je suis arrivé à la conclusion que50-landscape-sysinfo et 99-esm étaient la cause de mes problèmes. 50-landscape-sysinfo a pris environ 5 secondes pour s'exécuter et 99-esm environ 3 secondes. Tous les autres fichiers ont pris environ 2 secondes en tout.

Ni 50-landscape-sysinfo ni 99-esm ne sont cruciaux. 50-landscape-sysinfo imprime des statistiques système intéressantes (et aussi si vous manquez d'espace !), et 99-esm imprime les messages relatifs à Ubuntu Extended Security Maintenance

Enfin, vous pouvez créer un script avec echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh et obtenir cette impression sur demande.

J'ai essayé toutes les réponses mais aucune n'a fonctionné. finalement je trouve mon problème :

d'abord je lance sudo tail -f /var/log/auth.log donc je peux voir le log de ssh puis dans une autre session je lance ssh 172.16.111.166 et j'ai remarqué une attente sur

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

après avoir cherché j'ai trouvé cette ligne dans /etc/ssd/ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

je l'ai commentée et le délai est passé

Travaillez bien.

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS non ne fonctionne pas avec OpenIndiana ! !!

Lire “man sshd_config” pour toutes les options

“LookupClientHostnames no” si votre serveur ne peut pas résoudre

La connexion ssh -vvv s'est très bien passée jusqu'à ce qu'elle s'accroche au système en essayant d'obtenir le terminal pendant au moins 20 secondes :

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting

Après avoir fait un systemctl restart systemd-logind sur le serveur, j'ai eu de nouveau une connexion instantanée !

C'était sur debian8 ! Donc c'est Systemd qui était le problème ici !

Note: _Bastien Durel a déjà donné une réponse pour ce problème, mais il manque les informations de débogage. J'espère que cela sera utile à quelqu'un.

Nous pouvons constater que la méthode de résolution de nom préférée n'est pas le fichier hôte puis le DNS.

Par exemple, ce serait la configuration habituelle :

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts: db files nisplus nis dns
hosts: files dns myhostname

D'abord, le fichier hôte est atteint (option : files) et ensuite le DNS (option : dns), cependant nous pouvons constater qu'un autre système de résolution de nom a été ajouté qui n'est pas opérationnel et nous cause la lenteur à essayer de faire la résolution inverse.

Si l'ordre de résolution des noms n'est pas correct, vous pouvez le changer à : /etc/nsswitch.conf

Extrait de : http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

Ce fil de discussion fournit déjà un tas de solutions mais la mienne n'est pas donnée ici =). Donc, le voici. Mon problème (il a fallu environ 1 minute pour se connecter à ssh dans mon pi framboise), était dû à un fichier .bash_history corrompu. Comme le fichier est lu lors de la connexion, cela causait le retard de la connexion. Une fois que j'ai supprimé le fichier, le temps de connexion est revenu à la normale, comme instantané.

J'espère que cela aidera d'autres personnes.

Pour compléter toutes les réponses montrant que les résolutions DNS peuvent ralentir votre connexion ssh, il manque parfois une règle de pare-feu. Par exemple, si vous DROPPEZ tous les paquets INPUT par défaut

iptables -t filter -P INPUT DROP

alors vous devrez accepter INPUT pour le port ssh et la requête DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
```.

J'ai récemment découvert une autre cause de lenteur dans les connexions ssh.

Même si vous avez UseDNS no dans /etc/sshd_config, sshd peut toujours effectuer des recherches DNS inversées si /etc/hosts.deny a une entrée du genre :

nnn-nnn-nnn-nnn.rev.some.domain.com

Cela peut arriver si vous avez DenyHosts installé dans votre système.

Ce serait bien si quelqu'un savait comment faire en sorte que DenyHosts évite de mettre ce genre d'entrée dans /etc/hosts.deny.

Voici un lien, vers la FAQ DenyHosts , sur la façon de supprimer des entrées de /etc/hosts.deny - voir Comment supprimer une adresse IP bloquée par DenyHosts ?

J'ai constaté que le redémarrage de systemd-logind.service n'a réglé le problème que pendant quelques heures. Le changement de UsePAM de yes à no dans sshd_config a permis des connexions rapides, bien que motd ne soit plus affiché. Des commentaires sur les problèmes de sécurité ?

Pour moi, il y avait un problème dans mon fichier local /etc/hosts. ssh essayait donc deux IP différentes (dont une erronée), ce qui a pris une éternité à s'éteindre.

L'utilisation de ssh -v a fait l'affaire ici :

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.

Pour moi, j'avais besoin de GSSAPI, et je ne voulais pas désactiver les consultations DNS inversées. Cela ne me semblait pas être une bonne idée, alors j'ai consulté la page principale de resolv.conf. Il s'est avéré qu'un pare-feu entre moi et les serveurs sur lesquels je faisais de la SSH, interférait avec les requêtes DNS, parce qu'elles n'étaient pas sous la forme attendue par le pare-feu. Au final, tout ce que j'avais à faire était d'ajouter cette ligne à resolv.conf sur les serveurs sur lesquels je faisais de la SSH :

options single-request-reopen

Remarquablement, une mise à jour du paquet bind sur CentOS 7 a cassé named, indiquant maintenant dans le journal que /etc/named.conf avait un problème de permissions. Cela avait bien fonctionné pendant des mois avec 0640. Maintenant, il veut la version 0644. Cela a du sens puisque le démon named appartient à l'utilisateur “named”.

Avec named down, tout était lent, des connexions ssh au service de pages à partir du serveur web local, des applications LAMP lentes, etc., très probablement parce que chaque requête prenait du temps sur le serveur local mort avant de chercher un DNS secondaire externe qui est configuré.