Pourquoi l'invite «mot de passe» prend-elle une éternité lorsque je me connecte à mon serveur Ubuntu 9.05?

27

Réponse: Il s'agissait en fait d'une résolution DNS inversée. Sur la base des suggestions ci-dessous et de cet article , j'ai ajouté "UseDNS no" à mon sshd_config, redémarré ssh et maintenant l'invite de mot de passe s'affiche immédiatement.

Lorsque je me connecte à mon serveur, je reçois l'invite standard "login as:", suivie de l'invite "user @ host's password:". Pour une raison quelconque, le second prend toujours un certain temps à s'afficher. Mon serveur n'est sous aucune charge et exécute généralement des commandes assez rapidement.

Maintenant, nous ne parlons que de 10 secondes environ entre le moment où j'appuie sur Entrée pour le nom d'utilisateur et lorsque la deuxième invite s'affiche, mais lorsque vous faites cela beaucoup, cela devient ennuyeux. Je soupçonne qu'Ubuntu recherche mon compte d'utilisateur, mais il a <5 comptes sur toute l'installation.

La mise à jour @Josh / var / log / messages contient ce joyau:

Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: Called
Oct 28 16:54:59 Athena sudo: pam_sm_authenticate: username = [msmith]
Oct 28 16:54:59 Athena sudo: Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Oct 28 16:55:01 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: Passphrase key already in keyring; rc = [1]
Oct 28 16:55:02 Athena sudo: There is already a key in the user session keyring for the given passphrase.

Où msmith est mon nom d'utilisateur. Qu'est-ce-que tout cela veut dire?

— rcampbell
source

Savez-vous (ou voulez-vous apprendre) comment utiliser des renifleurs de paquets tels que Wireshark ou tcpdump? Cela peut vous dire si le serveur utilise effectivement tout ce temps seul ou s'il communique réellement avec le client.

— Arjan

17

Est-il possible qu'il effectue une recherche DNS inversée sur votre IP? Vous pouvez vérifier les résultats en ligne si le client utilise une adresse IP publique ou utiliser quelque chose comme ce qui suit à partir de votre serveur:

dig -x CLIENT_IP_ADDRESS

Y a-t-il quelque chose dedans /var/log/messages?

— Josh
source

J'ai un avertissement dans le journal: Avertissement: utilisation de la valeur de sel par défaut (non définie dans ~ / .ecryptfsrc). J'ai posté la section entière à la question pour votre analyse.

— rcampbell

@ rrc7cz, alors qu'en est-il de ce DNS inversé? Votre adresse IP résout-elle quelque chose? (Je doute que cela aide, car le plus souvent, il faudra quelques poignées de main pour décider si une invite pour le nom d'utilisateur doit être affichée. Un test rapide en utilisant Wireshark sur mon Mac montre que SSH est lancé bien avant que le nom d'utilisateur ne soit demandé. Mais peut-être que certains clients demandent ce nom d'utilisateur avant même d'essayer de se connecter ...?)

— Arjan

3

J'ai eu ce problème de recherche DNS inversée qui ralentit mes connexions ssh dans quelques installations ... Si vous trouvez que c'est le cas, commentez la ligne "UseDNS yes" dans / etc / ssh / sshd_config et redémarrez sshd.

— John Barrett

@john, vous souvenez-vous si cela a ralenti après avoir tapé le nom d'utilisateur?

— Arjan

1

"UseDNS no" m'a aussi aidé! UpVotes pour les Q & R!

— Grizly

14

La résolution DNS inversée (serveur essayant d'obtenir l'adresse IP du nom du client) prend probablement du temps. Pouvez-vous vérifier si / etc / ssh / sshd_config a le paramètre "VerifyReverseMapping yes"? Réglez-le sur "VerifyReverseMapping no" et vérifiez si cela aide.

Edit: Il semble que VerifyReverseMapping est maintenant obsolète et useDNS est la nouvelle configuration dans sshd_config .

— secureBadshah
source

C'est peut-être vrai, mais est-il logique alors que l'invite du nom d'utilisateur s'affiche immédiatement, après quoi il faut 10 secondes pour demander le mot de passe?

— Arjan

Le client est capable de résoudre le nom du serveur et d'envoyer une demande, c'est pourquoi l'invite de l'utilisateur s'affiche immédiatement. Mais le serveur essaie ensuite d'obtenir le nom du client (résolution DNS inversée). Cela peut expirer si la dose d'entrée n'existe pas. Le paramètre "VerifyReverseMapping" dans sshd-config contrôle cette vérification.

— secureBadshah

1

C'était la raison de la lenteur dans mon cas, donc cela a du sens dans certains cas au moins. Rappelez-vous que la valeur par défaut est yes, alors ne cherchez pas seulement si useDNSest défini :)

— Nanne

8

Dans votre ensemble de fichiers sshd_config GSSAPIAuthentication = no

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899

3

Vous pouvez toujours vous connecter avec le nom d'utilisateur pour commencer:

ssh user@server

cela a-t-il un effet?

Si vous utilisez PuTTY, il est configurable sous Connexion -> Données comme nom d'utilisateur de connexion automatique.

— John T
source

1

Bien que cela n'accélère évidemment pas le temps nécessaire à l'apparition de l'invite de mot de passe, cela accélère définitivement le processus de connexion global. Merci

— rcampbell

3

Si vous n'avez pas de noms de domaine appropriés pour tout, inventez quelque chose et insérez-le /etc/hosts. Voyez si cela va plus vite ... ne vous embêtez pas avec .comsimplement "bob, carol, ted, alice" ou tout ce que vous voulez ...

Si le problème est des délais d'expiration du résolveur, cela le résoudra.

— DigitalRoss
source

1

N'oubliez pas que le client effectuera également une vérification de vérification DNS inverse, ce qui peut prendre 30 secondes ou plus pour expirer si le mappage DNS inverse n'existe pas avec certaines configurations de résolution.

Dans /etc/ssh/ssh_configou dans l' ~/.ssh/configensemble CheckHostIP nopour désactiver cette recherche côté client.

Voir man 5 ssh_configpour plus de détails.

— tylerl
source

1

J'ai trouvé une solution alternative à ce problème: - http://www.patrickmin.com/linux/tip.php?name=ssh_pause

J'avais ce même problème de connexion à une machine de construction Linux en utilisant Putty sous Windows. L'ajout de l'adresse IP de ma boîte Windows à / etc / hosts sur la machine Linux a résolu le problème.

— Rob Belcham
source

3

Bienvenue sur Super User - Nous préférons généralement que vous incluiez des détails et pas seulement des liens. Pourriez-vous MODIFIER votre réponse pour ajouter plus d'informations à partir du lien?

— Simon Sheehan

1

Juste pour mémoire, j'ai rencontré le même problème où ssh serait rapide de chez moi à mon serveur domestique (l'utilisant principalement pour git), mais cela prendrait environ 10-20 secondes au travail pour obtenir une invite pour le mot de passe.

J'ai dû éteindre UseDNS noet redémarrer sshd sudo systemctl restart sshd.service. Ensuite, cela fonctionne à partir de tous les emplacements.

Je sais que la question a reçu une réponse et est acceptée, mais je voulais ajouter les informations car je devais la définir "activement" sur non afin de l'empêcher d'utiliser DNS.

— qrikko
source

0

Veuillez vérifier si nslcd (démon LDAP) est en cours d'exécution:

ps -ef | grep nslcd

Cela peut provoquer ce problème.

S'il est en cours d'exécution, arrêtez-le et supprimez de la liste des services

service nslcd stop
chkconfig nslcd off

— Anu V Das
source