Long temps d'attente à la connexion

20

Quand je me connecte sur mon serveur, je reçois ceci:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

alors je dois attendre 5 secondes et puis est prêt ...

[email protected]:~$

Ce temps d’attente est-il normal ou devrais-je faire quelque chose pour le "réparer"?

    
posée Wolfy 05.11.2010 - 14:57
la source

10 réponses

18

Ceci est généralement le résultat de pam_motd régénérant le fichier /etc/motd . Vous pouvez vérifier les scripts individuels dans /etc/update-motd.d pour voir si quelque chose est particulièrement lent.

    
réponse donnée Kees Cook 05.11.2010 - 21:33
la source
13

J'ai les mêmes problèmes avec 10.04 (LTS).

Quand je lance mon ssh avec -vvv , il meurt à:

debug1: Entering interactive session.

Extension de cette réponse.

J'ai réussi à redémarrer le serveur à distance et à activer la journalisation DEBUG. Utilisé également cette opportunité pour rester connecté et observer d'autres tentatives de connexion. Voici ce qui se passe. Le client se connecte et est autorisé et bloque le message ci-dessus.

Sur le serveur, la liste des processus affiche ceci:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Je peux exécuter /usr/bin/python /usr/bin/landscape-sysinfo pendant que je suis connecté, mais pour une raison quelconque, je n'arrive pas à comprendre pourquoi cela bloque le processus de connexion. Lorsque je supprime le processus, la connexion continue à l'invite et réussit .

Cela ne semble pas être un problème ssh (d), mais plutôt lié à update-motd et landscape. J'ai désinstallé le package update-motd , mais il semble que le répertoire /etc/update-motd persiste et que les scripts soient toujours exécutés, ce qui entraîne le blocage du processus.

Déboguer cela plus loin:

Désactive le répertoire /etc/update-motd.d/ n'appartient pas vraiment au package update-motd , il semble être déclenché par l'authentification pam via sshd.

Il semble que je l'ai bien compris!

Désactivé pam_motd dans les fichiers suivants:

  • /etc/pam.d/sshd
  • /etc/pam.d/login

Un de plus:

apt-get purge landscape-client landscape-common

Celles-ci semblent aider dans une certaine mesure. Cependant, seulement supprime le script incriminé dans /etc/update-motd.d/ et ne supprime pas tous les scripts de ce répertoire et ne supprime pas non plus pam_motd .

En général, je n'ai trouvé aucun moyen de désactiver complètement pam_motd , car cela semble ralentir le processus de connexion. Il ne bloque pas comme le script dans landscape-common , mais il est plus lent.

Rapport de bogue sur ce problème:

Solutions de contournement à partir de là:

  

Vous avez raison de dire que la possibilité de vous connecter est plus importante que   présenter un motd. Si ce comportement est un problème pour vous, il y a   plusieurs façons de le désactiver:

     
  • commente la ligne "pam_motd" dans /etc/pam.d/sshd si vous ne souhaitez pas afficher un motd.
  •   
  • supprimer le contenu du répertoire /etc/update-motd.d .
  •   
  • chmod -x les scripts de /etc/update-motd.d que vous ne voulez pas exécuter.
  •   
    
réponse donnée Till 11.07.2012 - 15:20
la source
10

J'ai trouvé la solution moi-même enfin:

  1. sudo apt-get remove landscape-client landscape-common
  2. ligne de commentaires session optional pam_motd.so en /etc/pam.d/login et /etc/pam.d/sshd

Maintenant, la connexion est INSTANTANÉE!

    
réponse donnée BarsMonster 22.03.2011 - 06:12
la source
4

D'après votre description, cela ressemble plus à un problème de réseau. Pour diagnostiquer:

  • Exécutez ssh avec le paramètre -v pour qu'il soit verbeux.
  • Essayez d’exécuter un ping sur le serveur SSH auquel vous vous connectez et voyez si cela se bloque en même temps.
  • Essayez un autre type de transfert vers le même serveur. Par exemple, wget avec le paramètre --limit-rate pour extraire un fichier via HTTP et le faire prendre suffisamment de temps pour déclencher le comportement de "suspension".
  • Voyez si cela ne se bloque que lorsque vous êtes inactif, ou même si vous faites quelque chose pour le moment. Si elle se bloque en mode veille, le diagnostic -v vous le dira probablement, auquel cas le conseil d'utilisation de keepalive pourrait vous aider (ssh -o "TCPKeepAlive yes")

Si vous pouvez vous connecter avec Windows et PuTTY, ce n’est probablement pas un problème du côté du serveur.

    
réponse donnée roadmr 08.12.2011 - 05:49
la source
2

Je pense que lorsque vous vous connectez, Ubuntu exécute un ou plusieurs de ces fichiers:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Vous pouvez voir ce qu’ils contiennent et peut-être même essayer de les exécuter pour voir ce qui dure si longtemps.

    
réponse donnée Savvas Radevic 05.11.2010 - 16:30
la source
2

Dans mon expérience limitée, lorsque le mastic fonctionne, mais que Linux, Ubuntu dans ce cas, ne fonctionne pas, il reste généralement vivant. Des problèmes de réseau ou de serveur affecteront à la fois le système d’exploitation client.

Vous pouvez utiliser l’option keep alive ci-dessus sur la ligne de commande, mais c’est en quelque sorte fastidieux à taper.

Plus facile de modifier quelques fichiers de configuration.

Si vous avez root access et souhaitez l’activer automatiquement pour tous les utilisateurs, éditez /etc/ssh/ssh_config , ajoutez

KeepAlive yes
ServerAliveInterval 120

Si vous n’avez pas d’accès root ou pour l’activer pour un seul utilisateur, éditez ~/.ssh/config et ajoutez les deux mêmes lignes.

    
réponse donnée Panther 08.12.2011 - 06:48
la source
2

Si PermitEmptyPassword et UsePAM sont tous deux activés, le serveur OpenSSH tente toujours l’authentification avec un mot de passe nul, ce qui signifie qu’aucune authentification n’est requise pour le compte en question. Il le fait dès que le processus d'authentification commence, dans les deux protocoles, et non en réponse à une requête d'authentification "réelle" du client. OpenSSH n'autorisera cet accès que si sshd_config flag PermitEmptyPassword est défini; malheureusement, la façon dont le code est écrit, il effectue le test de mot de passe dans tous les cas, et montre donc à PAM comme un échec.

Donc: désactivez PermitEmptyPassword ou UsePAM , mais souvenez-vous: sans PAM, vous ne pourrez pas vous connecter sans clé.

Référence: lien

    
réponse donnée Alessandro Pezzato 01.10.2012 - 22:53
la source
0

Vérifiez les journaux de votre système dans / var / log, vous pouvez trouver un message avec l’erreur / le timeout associé.

    
réponse donnée João Pinto 05.11.2010 - 15:14
la source
0

Si vous avez également un peu d’attente avant

Modifier /etc/sshd_config

et définir (ou ajouter)

UseDNS no

ou ajoutez votre adresse IP dans /etc/hosts si c'est un local statique

    
réponse donnée user11187 21.02.2011 - 00:09
la source
0

Vous pouvez essayer de surveiller les processus en cours d'exécution lorsque vous vous connectez au serveur à partir d'une connexion déjà connectée (ou d'une autre console). Il y a une chance de repérer les processus les plus actifs ou utilisant le plus de CPU à ce moment.

Voici une méthode possible:

  1. Essayez de vous connecter sur une autre console.
  2. Exécutez top pour voir ce qui se passe.
  3. Connectez-vous sur la 1ère console.

Veuillez noter que si le retard n’est pas dû à un calcul intensif en CPU, vous ne verrez aucun élément déplacé. Dans ce cas, le problème peut être lié aux E / S (en attente d’une lecture / écriture du disque ou d’une réponse réseau).

    
réponse donnée ido 05.11.2010 - 15:17
la source

Lire d'autres questions sur les étiquettes