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, ssh redémarré et maintenant, l'invite du mot de passe s'affiche immédiatement.
Lorsque je me connecte à mon serveur SSH, on me donne l'invite standard "login as:", suivie du mot de passe "utilisateur @ hôte:". Pour une raison quelconque, le second prend toujours un certain temps à afficher. Mon serveur n'est soumis à aucune charge et exécute généralement des commandes assez rapidement.
Nous ne parlons plus que d’une dizaine de secondes entre le moment où j’ai appuyé sur Entrée pour le nom d’utilisateur et le moment où le deuxième message d’invitation s’affiche, mais lorsque vous faites cela souvent, cela devient agaçant. Je soupçonne Ubuntu de rechercher mon compte d'utilisateur, mais il y a <5 comptes sur toute l'installation.
Mettre à jour @Josh /var/log/messages contient cette gemme:
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?
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 les éléments suivants sur votre serveur:
Dig -x CLIENT_IP_ADDRESS
Y at-il quelque chose dans /var/log/messages
?
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 soit maintenant obsolète et useDNS est la nouvelle configuration dans le sshd_config .
Dans votre fichier sshd_config, définissez GSSAPIAuthentication = no
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899
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 en tant que nom d'utilisateur pour la connexion automatique.
Si vous n'avez pas les noms de domaine appropriés pour tout, créez simplement quelque chose et mettez-le dans /etc/hosts
. Voyez si cela va plus vite ... ne vous embêtez pas avec .com
, utilisez simplement "bob, carol, ted, alice" ou ce que vous voulez ...
Si le problème est lié aux délais d'attente du résolveur, cela résoudra le problème.
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 en me connectant à une machine de compilation Linux en utilisant PuTTY sous Windows. Ajouter l’adresse IP de ma machine Windows à/etc/hosts sur la machine Linux a résolu le problème.
Pour mémoire, j’ai rencontré le même problème: ssh serait rapide de chez moi à mon serveur domestique (principalement pour l’utilisation de git), mais il faudrait environ 10 à 20 secondes au travail pour obtenir une invite pour le mot de passe.
J'ai dû désactiver UseDNS no
et redémarrer sshd
Sudo systemctl restart sshd.service
. Ensuite, cela fonctionne de tous les endroits.
Je sais que la question a reçu une réponse et a été acceptée, mais je voulais ajouter cette information car je devais la définir "activement" sur non pour l'obtenir. cesser d'utiliser dns.
N'oubliez pas que le client effectue également la vérification du reverse DNS, ce qui peut prendre 30 secondes ou plus avant l'expiration du délai si le mappage reverse-DNS n'existe pas. avec certaines configurations de résolution.
Dans /etc/ssh/ssh_config
ou dans ~/.ssh/config
, définissez CheckHostIP no
pour désactiver cette recherche côté client.
Voir man 5 ssh_config
pour plus de détails.
Veuillez vérifier si nslcd (démon LDAP) est en cours d'exécution:
ps -ef | grep nslcd
Cela peut causer ce problème.
S'il est en cours d'exécution, arrêtez-le et supprimez-le de la liste des services.
service nslcd stop
chkconfig nslcd off