Pourquoi ma connexion SSH est-elle lente?
Je constate des retards dans les connexions SSH. Plus précisément, il y a deux endroits où je vois une plage de délais instantanée à plusieurs secondes.
- Entre l’émission de la commande ssh et l’obtention d’une invite de connexion et
- entre la saisie de la phrase secrète et la charge du shell
Maintenant, spécifiquement, je regarde les détails SSH seulement ici. Évidemment, la latence du réseau, la vitesse du matériel et des systèmes d'exploitation impliqués, des scripts de connexion complexes, etc. peuvent entraîner des retards. Pour le contexte, ssh utilise une multitude de distributions Linux et certains hôtes Solaris qui utilisent principalement Ubuntu, CentOS et MacOS X comme système client. Presque tout le temps, la configuration du serveur ssh est inchangée par rapport aux paramètres par défaut du système d'exploitation.
À quelles configurations de serveur ssh devrais-je m'intéresser? Existe-t-il des paramètres système/noyau pouvant être ajustés? Login Trucs de shell? Etc?
Essayez de définir UseDNS à no dans /etc/sshd_config ou /etc/ssh/sshd_config.
Quand j'ai exécuté ssh -vvv sur un serveur avec une performance similaire similaire, j'ai vu un blocage ici:
debug1: Next authentication method: gssapi-with-mic
En éditant /etc/ssh/ssh_config et en commentant cette méthode d'authentification, les performances de connexion sont redevenues normales. Voici ce que j'ai dans mon /etc/ssh/ssh_config sur le serveur:
GSSAPIAuthentication no
Vous pouvez définir ceci globalement sur le serveur, de sorte qu'il n'accepte pas que GSSAPI s'authentifie. Ajoutez simplement GSSAPIAuthentication no à /etc/ssh/sshd_config sur le serveur et redémarrez le service.
Pour moi, le coupable était la résolution IPv6, le délai était écoulé. (Je suppose que le paramètre DNS est mauvais chez mon fournisseur d’hôte.) J’ai découvert cela en faisant ssh -v, qui indiquait quelle étape était suspendue.
La solution consiste à ssh avec l'option -4:
ssh -4 [email protected]
Avec systemd, la connexion peut se bloquer sur la communication dbus avec logind après certaines mises à niveau, vous devez alors redémarrer logind
systemctl restart systemd-logind
Vu cela sur debian 8, Arch linx et sur une liste de choix
Vous pouvez toujours démarrer ssh avec l'option -v qui affiche ce qui est fait pour le moment.
$ ssh -v you@Host
Avec les informations que vous avez données, je ne peux que suggérer certaines configurations côté client:
Puisque vous écrivez que vous entrez les mots de passe manuellement, je vous suggérerais d'utiliser l'authentification par clé publique si possible. Cela vous élimine comme un goulot d'étranglement.
Vous pouvez également désactiver le transfert X avec
-xet le transfert d'authentification avec-a(ceux-ci peuvent déjà être désactivés par défaut). La désactivation de X-forwarding en particulier peut vous apporter une grande amélioration en termes de vitesse si votre client doit démarrer un serveur X pour la commandessh(par exemple sous OS X).
Tout le reste dépend vraiment du type de retard que vous rencontrez, où et quand.
En ce qui concerne le 2. point, voici une réponse qui ne nécessite pas de modifier le serveur ni d’avoir les privilèges root/administratif.
Vous devez éditer votre fichier "user ssh_config" qui est:
vi $HOME/.ssh/config
(Remarque: 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 sur une base 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 à l'adresse IP de votre serveur. Un avantage intéressant est que ssh fournira maintenant la saisie semi-automatique pour ce serveur. Donc, vous pouvez taper ssh lin + Tab et il devrait compléter automatiquement à ssh linux-srv.
Vérifiez /etc/resolv.conf sur le serveur pour vous assurer que le serveur DNS, répertorié dans ce fichier, fonctionne correctement et supprimez tout DNS qui ne fonctionne pas.
Parfois, c'est très utile.
Outre les problèmes DNS déjà mentionnés, si vous êtes connecté à un serveur avec de nombreux montages NFS, il peut y avoir un délai entre mot de passe et Invite lorsque la commande quota vérifie votre utilisation/quota sur tous les systèmes de fichiers non montés avec noquota. . Sur les systèmes Solaris, vous pouvez le voir dans le /etc/profile par défaut et le ignorer en exécutant touch $HOME/.hushlogin.
Ceci est probablement uniquement spécifique à l’OpenSSH Debian/Ubuntu, qui comprend le groupe user-group-modes.patch écrit par l’un des responsables de paquet Debian. Ce correctif permet aux fichiers ~/.ssh de définir le bit d’inscription de groupe (g + w) s’il n’ya qu’un seul utilisateur avec le même gid que celui du fichier. La fonction secure_permissions () du patch effectue cette vérification. L'une des phases de la vérification consiste à parcourir chaque entrée de mot de passe à l'aide de getpwent () et à comparer le gid de l'entrée au gid du fichier.
Sur un système comportant de nombreuses entrées et/ou une authentification lente NIS/LDAP, 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, j'ai trouvé cela, il a ajouté environ 4 secondes pour chaque invocation de ssh ou connexion au système.
Le correctif consiste à supprimer le bit en écriture sur tous les fichiers de ~/.ssh en faisant chmod g-w ~/.ssh/*.
J'ai constaté que le redémarrage de systemd-logind.service ne réglait le problème que pendant quelques heures. La modification de UsePAM de oui à non dans sshd_config a entraîné des connexions rapides, bien que motd ne soit plus affiché. Des commentaires sur des problèmes de sécurité?
Ce fil fournit déjà un tas de solutions, mais le mien n’est pas donné ici =). Alors le voici. Mon problème (il a fallu environ 1 minute pour que SSH se connecte à mon Raspberry Pi) était dû à un fichier .bash_history corrompu. Étant donné que le fichier est lu lors de la connexion, cela entraînait un délai de connexion. Une fois le fichier supprimé, le temps de connexion est revenu à la normale, de manière instantanée.
J'espère que cela aidera d'autres personnes.
À votre santé
J'ai récemment trouvé une autre cause de connexions ssh lentes.
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 type:
nnn-nnn-nnn-nnn.rev.some.domain.com
Cela peut arriver si vous avez DenyHosts installé sur votre système.
Ce serait formidable 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 le DenyHosts FAQ , sur la façon de supprimer des entrées de /etc/hosts.deny - voir Comment puis-je supprimer une adresse IP bloquée par DenyHosts?
Nous pouvons constater que la méthode de résolution de noms préférée n'est pas le fichier hôte, puis 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
Tout d'abord, le fichier hosts est atteint (option: fichiers), puis DNS (option: dns). Cependant, nous pouvons constater qu'un autre système de résolution de noms a été ajouté. Il n'est pas opérationnel et nous ralentit lorsque nous essayons de faire la résolution inverse.
Si l'ordre de résolution du nom n'est pas correct, vous pouvez le modifier à l'adresse suivante: /etc/nsswitch.conf
Extrait de: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html
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 supprimez 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 essayé toutes les réponses mais aucune d'entre elles n'a fonctionné. enfin je découvre mon problème:
j'exécute d'abord Sudo tail -f /var/log/auth.log pour pouvoir voir le journal de ssh, puis dans une autre session, lancez ssh 172.16.111.166 et remarque que j'attends
/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é et le délai est passé
Travailler 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 no ne fonctionne pas avec OpenIndiana !!!
Lisez "man sshd_config" pour toutes les options
"LookupClientHostnames no" si votre serveur ne peut pas résoudre
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 (démon cache de service de noms) est installé et en cours d'exécution.
Si tel est le problème, c’est que vous n’avez pas de cache DNS, et chaque fois que vous recherchez un nom d’hôte qui ne figure pas sur votre fichier hôte, vous envoyez la question à votre serveur de noms au lieu de chercher dans votre cache
J'ai essayé toutes les options ci-dessus et le seul changement qui a fonctionné était start nscd.
Vous devez également vérifier l’ordre dans lequel la résolution des requêtes DNS dans /etc/nsswitch.conf doit être utilisée en premier.
La connexion ssh -vvv s'est très bien passée jusqu'à ce qu'elle soit bloquée sur le système et tente 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 [email protected]
debug1: Entering interactive session.
... waiting ... waiting ... waiting
Après avoir fait un systemctl restart systemd-logind sur le serveur j’ai eu une connexion instantanée à nouveau!
C'était sur debian8 ! Donc, le problème était ici!
Remarque: - Bastien Durel a déjà donné une réponse à ce problème, mais les informations de débogage manquent. J'espère que cela est utile à quelqu'un.
Note: Ceci a commencé comme un tutoriel "Comment déboguer", mais a fini par être la solution qui m'a aidé sur un serveur Ubuntu 16.04 LTS.
TLDR: Exécutez landscape-sysinfo et vérifiez si la commande prend beaucoup de temps; c'est l'impression des informations système sur une nouvelle connexion SSH. Notez que cette commande n'est pas disponible sur tous les systèmes, le package landscape-common l'installe. ("Mais attendez, il y a plus ...")
Démarrez un deuxième serveur ssh sur un autre port de la machine qui rencontre le problème, faites-le en mode débogage, ce qui ne le fera pas changer et affichera les messages de débogage:
Sudo /usr/sbin/sshd -ddd -p 44321
connectez-vous à ce serveur à partir d'une autre machine en mode prolixe:
ssh -vvv -p 44321 username@server
Mon client affiche 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 remplace UsePAM yes par UsePAM no, le problème est résolu.
Non lié à UseDNS ni à aucun autre paramètre, seul UsePAM affecte ce problème sur mon système.
Je ne sais pas pourquoi, et je ne quitte pas non plus UsePAM à no, car je ne sais pas quels sont les effets secondaires, mais cela me permet de poursuivre mes recherches.
Alors, s'il vous plaît, ne considérez pas cela comme une réponse, mais une première étape pour commencer à découvrir ce qui ne va pas.
J'ai donc continué à enquêter et ai lancé sshd avec strace (Sudo strace /usr/sbin/sshd -ddd -p 44321). Cela a donné ce qui suit:
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 méfiant. Apparemment, le processus attend le résultat des éléments en /etc/update-motd.d.
Donc, je cd 'd dans /etc/update-motd.d et ai exécuté 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, qui inclut la charge du système et si les packages doivent être mis à niveau, ce qui a résolu le problème.
Ceci est un serveur basé sur un processeur N3150 "économe en énergie" qui a beaucoup de travail à faire 24h/24, donc je pense que la collecte de toutes ces données motd était trop pour elle.
Je peux commencer à activer les scripts de ce dossier de manière sélective, afin de voir ceux qui sont moins nocifs, mais appeler spécialement landscape-sysinfo est très lent, et 50-landscape-sysinfo appelle cette commande. Je pense que c'est celui qui cause le plus gros retard.
Après avoir réactivé la plupart des fichiers, je suis parvenu à la conclusion que 50-landscape-sysinfo et 99-esm étaient la cause de mes problèmes. 50-landscape-sysinfo a pris environ 5 secondes à exécuter et 99-esm environ 3 secondes. Tous les fichiers restants environ 2 secondes au total.
Ni 50-landscape-sysinfo ni 99-esm ne sont cruciaux. 50-landscape-sysinfo affiche des statistiques système intéressantes (et également si vous manquez d'espace!), et 99-esm imprime des messages liés à 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 à la demande.
Pour moi, j'avais besoin de GSSAPI et je ne voulais pas désactiver les recherches DNS inversées. Cela ne semblait pas être une bonne idée, alors j’ai vérifié la page principale de resolv.conf. Il s'est avéré qu'un pare-feu entre moi et les serveurs sur lesquels je travaillais sous SSH interférait avec les requêtes DNS, car elles ne se présentaient pas sous la forme attendue par le pare-feu. En fin de compte, tout ce que j'avais à faire était d'ajouter cette ligne à resolv.conf sur les serveurs pour lesquels j'étais SSHing:
options single-request-reopen
Remarquablement, une mise à jour du paquet de bind sur CentOS 7 a été nommée de façon erronée, indiquant maintenant dans le journal que /etc/named.conf avait un problème d’autorisations. Cela fonctionnait bien depuis des mois avec 0640. Maintenant, il veut 0644. Cela a du sens, car le démon nommé appartient à l'utilisateur "nommé".
Avec le nom indiqué, tout était lent, des connexions ssh au serveur Web local, en passant par les applications LAMP lentes, etc. DNS configuré.
Pour moi, il y avait un problème dans mon fichier /etc/hosts local. Donc, ssh essayait deux adresses IP différentes (une fausse), ce qui prenait une éternité.
Utiliser 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.