Pourquoi la demande de mot de passe "password" de ssh met-elle autant de temps à apparaître?

Pour moi, le changement du système DNS en 127.0.0.1 a été nécessaire, car auparavant il s'agissait d'un hôte inexistant.

nano /etc/resolv.conf

Et écrire ce qui suit

domain localdomain
search localdomain
(Ligne supprimée) ===> nameserver 10.0.0.1
(Ligne ajoutée) ===> nameserver 127.0.0.1

Je ne connais pas autant que je le voudrais sur l'environnement de l'auteur de l'article, mais pour d'autres personnes ayant un problème similaire, cela pourrait être un problème avec sssd, que nous utilisons pour se connecter à ldap mojo.

Cela m'arrive aussi :

$ time ssh server.example.com

real  2m0.018s
user  0m0.006s
sys   0m0.004s

Je dois accéder au serveur (dans mon cas via la console) puis faire :

service restart sssd

Après ça, tout fonctionne normalement. Je n'ai pas eu le temps de déboguer la cause racine, mais ce correctif temporaire fonctionne pour moi.

J'ai pu résoudre le problème du mot de passe lent avec la fenêtre d'invite ssh en activant Activer la relais DNS dans les paramètres DHCP de mon routeur Dlink. Ensuite, les connexions avec SSH se sont établies en une seconde.

Paramètres réseau -> Paramètres du routeur -> Activer la relais DNS [x]

La configuration par défaut redirige chaque requête DNS vers le fournisseur. C'était lent même lorsque je me connectais via ssh pi@10.0.0.103. Un indice pour la solution était une entrée dans /etc/resolv.conf "search upc.at" qui était fournie via dhcp.

Le manuel de dlink indique :

Lorsque le relais DNS est activé, les clients DHCP du routeur se verront attribuer 
l'adresse IP LAN du routeur comme serveur DNS. Toutes les requêtes DNS que 
le routeur reçoit seront redirigées vers les serveurs DNS de votre FAI. 
Lorsque le relais DNS est désactivé, tous les clients DHCP du routeur 
se verront attribuer le serveur DNS du FAI. 

Après une libération du dhcp sur le client et le serveur, la connexion via SSH était à nouveau rapide. En espérant que cela aide.

Dans mon cas, le DNS résolvait via IPv6, pour une raison quelconque cela ralentissait ssh. J'ai fait une entrée IPv4 dans /etc/hosts sur la machine cliente, et ensuite ssh/scp était à nouveau rapide