Long temps d'attente à la connexion

Lorsque je me connecte sur mon serveur, j'obtiens ceci:

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

alors je dois attendre 5 sec et puis c'est prêt ...

wolfy@ubuntu-server:~$

Ce temps d'attente est-il normal ou dois-je faire quelque chose pour "réparer" cela?

Ceci est généralement le résultat de la pam_motdrégénération du /etc/motdfichier. Vous pouvez archiver les scripts individuels /etc/update-motd.dpour voir si quelque chose est particulièrement lent.

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 connexion DEBUG. A également profité de cette occasion pour rester connecté et observer d'autres tentatives de connexion. Voici ce qui se passe. Le client se connecte et est autorisé et se bloque au message ci-dessus.

Sur le serveur, la liste des processus montre 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-sysinfotrès bien pendant que je suis connecté, mais pour une raison quelconque, je ne peux pas comprendre pourquoi cela bloque le processus de connexion. Lorsque je tue le processus, la connexion continue à l'invite et réussit .

Cela ne semble pas être un problème ssh (d), c'est plus lié à update-motdet au paysage. J'ai désinstallé le update-motdpackage, mais il semble que le /etc/update-motdrépertoire persiste et que les scripts soient toujours exécutés, entraînant le blocage du processus.

Déboguer ceci plus loin:

Il s'avère que le /etc/update-motd.d/répertoire n'appartient pas vraiment au paquet update-motd, il semble être déclenché par l'authentification pam via sshd.

Il me semble l'avoir cloué!

Pam_motd désactivé 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, il supprime uniquement le script incriminé /etc/update-motd.d/et ne supprime pas tous les scripts de ce répertoire et ne se débarrasse pas pam_motdnon plus.

En général, je n'ai trouvé aucun moyen de désactiver pam_motdcomplètement car il semble, quoi qu'il fasse - cela ralentit le processus de connexion dans une certaine mesure. Il ne bloque pas comme le script landscape-common, mais il est plus lent.

Rapport de bug sur ce problème:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Solutions de contournement à partir de là:

Vous avez raison de dire que la capacité de se connecter est plus importante que de présenter un motd. Si ce comportement vous pose problème, vous pouvez le désactiver de plusieurs manières:

• commentez la ligne 'pam_motd' /etc/pam.d/sshdsi vous ne voulez pas afficher de motd.
• supprimez le contenu du /etc/update-motd.drépertoire.
• chmod -x les scripts /etc/update-motd.dque vous ne voulez pas exécuter.

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

1. sudo apt-get remove landscape-client landscape-common
2. ligne de commentaire session optional pam_motd.so dans /etc/pam.d/loginet/etc/pam.d/sshd

Maintenant, la connexion est INSTANTANÉE!

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

• Exécutez ssh avec le paramètre -v pour être détaillé.
• Essayez d'exécuter un ping sur le serveur SSH auquel vous vous connectez et voyez si cela se bloque également 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 récupérer un fichier via HTTP et le faire prendre suffisamment de temps pour qu'il puisse déclencher le comportement "suspendu".
• Vérifiez s'il ne se bloque que lorsqu'il est inactif, ou même si vous faites quelque chose en ce moment. S'il se bloque alors qu'il est inactif, les diagnostics -v vous le diront probablement, auquel cas le conseil d'utiliser keepalive pourrait vous aider (ssh -o "TCPKeepAlive yes")

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

Si PermitEmptyPasswordet UsePAMsont tous deux activés, le serveur OpenSSH tente toujours l'authentification avec un mot de passe nul, ce qui prend comme signe qu'aucune authentification n'est nécessaire pour le compte en question. Il le fait dès le début du processus d'authentification, dans les deux protocoles, et pas en réponse à une "vraie" demande d'authentification du client. OpenSSH n'autorisera un tel accès que si l'indicateur sshd_config PermitEmptyPasswordest défini; malheureusement, la façon dont le code est écrit, il effectue le test de mot de passe dans tous les cas, et apparaît donc à PAM comme un échec.

Donc: désactivez PermitEmptyPasswordou UsePAM, mais rappelez-vous: sans PAM, vous ne pourrez pas vous connecter sans clé.

Référence: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

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 prend si longtemps.

Dans mon expérience limitée, lorsque le mastic fonctionne, mais Linux, Ubuntu dans ce cas, ne fonctionne pas, il est généralement maintenu en vie. Les problèmes de réseau ou de serveur affectent les deux OS du client.

Vous pouvez utiliser l'option Keep Alive ci-dessus sur la ligne de commande, mais c'est un peu fastidieux à taper.

Plus facile de modifier quelques fichiers de configuration.

Si vous l'avez root accesset souhaitez l'activer automatiquement pour tous les utilisateurs, modifiez /etc/ssh/ssh_config, ajoutez

KeepAlive yes
ServerAliveInterval 120

Si vous ne disposez pas d'un accès root, ou pour l'activer pour un seul utilisateur, modifiez ~/.ssh/configet ajoutez les deux mêmes lignes.

Vérifiez vos journaux système dans / var / log, vous pouvez trouver un message avec l'erreur / le délai d'attente associé.

Si vous avez également un temps d'attente avant

modifier /etc/sshd_config

et définir (ou ajouter)

UseDNS no

ou ajoutez votre ip /etc/hostssi c'est un local statique

Vous souhaiterez peut-être essayer de surveiller les processus en cours pendant que vous vous connectez au serveur à partir d'une connexion déjà connectée (ou d'une console différente). Il est possible de repérer les processus les plus actifs ou utilisant le plus de CPU à ce moment-là.

Voici une méthode possible:

1. Essayez de vous connecter sur une autre console.
2. Courez toplà-bas pour voir ce qui se passe.
3. Connectez-vous sur la 1ère console.

Veuillez noter que si le retard n'est pas causé par des calculs gourmands en ressources processeur, vous ne remarquerez rien de déplacé. Dans ce cas, le problème peut être lié aux E / S (en attente d'une lecture / écriture sur le disque ou d'une réponse réseau).