SSH lent au démarrage de la session

8

Le démarrage d'un shell interactif sur SSH est lent pour l'un de mes serveurs. Tout ce qui y mène, y compris la négociation du chiffrement, est rapide, mais il se bloque pendant 45 secondes. Après ça, ça finit et j'ai une coquille. Comment puis-je identifier de quoi il s'agit? J'ai essayé d'effacer l'environnement et de désactiver tous les transferts au cas où cela le ralentirait mais cela n'a pas aidé. Voici ma commande de test:

env -i ssh -x -a -vvv server

et voici la sortie de SSH:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
*(hangs for 45 seconds here)*
debug3: Wrote 128 bytes for a total of 3191
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.

— pingouin359
source

unix.stackexchange.com/questions/10476/…

— forcefsck

@forcefsck Je ne pense pas que ce message soit pertinent. Ma connexion initiale est rapide, les clés sont échangées, l'authentification est rapide, pas d'attente sur une invite de mot de passe comme dans le post ci-dessus. De plus, tous les DNS avant et arrière devraient être terminés à ce stade, je suis presque certain. De plus, ce problème n'est pas intermittent comme dans le post ci-dessus, c'est à chaque fois. La sortie détaillée que j'ai publiée ci-dessus commence juste après le message d'authentification réussie. Je pense que c'est plus dans le sens de bash ou qu'un module de session pam est lent à démarrer.

— penguin359

Y a-t-il également un délai pour les sessions non interactives? Y a-t-il un délai lorsque vous démarrez une deuxième connexion alors qu'une est active? Quelle méthode d'authentification utilisez-vous? Votre répertoire personnel est-il monté automatiquement lors de la connexion d'une manière ou d'une autre (à distance ou crypté)? Un module pam pourrait être l'empreinte, dans quoi avez-vous /etc/pam.d/sshd(ou comment il s'appelle sur votre système)? Si vous avez accès aux journaux du serveur, y a-t-il quelque chose de pertinent?

— Gilles 'SO- arrête d'être méchant'

@ Gilles Oui, cela semble affecter les commandes à distance, scp et sftp. Si vous voulez dire deux connexions SSH distinctes, les deux sont lentes. Si vous voulez commencer une deuxième session via le même socket de contrôle, je viens de l'essayer et c'est rapide, mais je reçois un avertissement concernant l'échec de xauth à verrouiller .Xauthority. J'utilise n'importe quoi de clavier-interactif, publickey, basé sur l'hôte, à gssapi-keyex. L'authentification est toujours rapide malgré tout, bien que la vitesse varie légèrement. Mon répertoire personnel est local sur le serveur et n'est pas chiffré. PAM est essentiellement Ubuntu par défaut + pam_krb5.so installé.

— penguin359

Vous dites "lent à l'un de mes serveurs". Se comporte-t-il normalement lors du transfert vers d'autres machines? Et cela vient de votre ordinateur personnel, auquel vous êtes connecté localement? Quel est le système d'exploitation local et distant (y compris la version)? De plus, le transfert du serveur vers votre ordinateur personnel est-il normal? Sshing en tant qu'autre utilisateur (local et distant) fait-il une différence?

— Faheem Mitha

6

Dans un cas très similaire, c'était l'un des scripts update-motd.

Ce qui suit a fait l'affaire:

sudo rm /etc/update-motd.d/90-updates-available

Voici un petit assistant qui mesure le temps de chaque script:

$ for f in /etc/update-motd.d/*;do echo $f;time $f;done
/etc/update-motd.d/00-header            0m0.007s
/etc/update-motd.d/10-help-text         0m0.005s
/etc/update-motd.d/90-updates-available 0m49.163s
/etc/update-motd.d/91-release-upgrade   0m0.152s
/etc/update-motd.d/98-fsck-at-reboot    0m0.015s
/etc/update-motd.d/98-reboot-required   0m0.003s
(output reduced to the relevant parts)

— Daniel Alder
source

Merci! La plupart des gens conseillent simplement de désactiver le DNS, mais ma connexion ssh était toujours lente. J'ai commencé à creuser dans le processus de connexion, et votre réponse m'a indiqué /etc/update-motd.d/50-landscape-sysinfo, qui semblait être le plus lent.

— Rennex

1

c'est vraiment utile - pour moi, le tueur était 50-landscape-sysinfo. Et fyi, vous pouvez simplement l' chmod -x /etc/update-motd.d/90-updates-availableempêcher de s'exécuter à la connexion au lieu de le supprimer complètement.

— billynoah

3

pam_krb5.so a été configuré pour acquérir des jetons AFS pour un shell inexistant qui avait un délai de 30 secondes arrêtant toute authentification utilisant ce module, pas seulement SSH. Suppression de cela et l'authentification se produit beaucoup plus rapidement.

— pingouin359
source

2

Si votre serveur ssh a activé le mappage DNS inversé, cela pourrait être la cause du retard, recherchez VerifyReverseMappingdans le /etc/ssh/sshd_configfichier du serveur.

— Frederik Deweerdt
source

1

Je pensais que le mappage DNS inversé s'était produit avant que l'authentification ne soit autorisée à réussir, mais je vais tester cela.

— penguin359

Je pense que vous voulez dire UseDNS, j'ai reçu un avertissement déprécié sur VerifyReverseMapping. Quoi qu'il en soit, j'ai réglé les deux sur non et cela n'a pas aidé. Je fais attention à m'assurer que mon mappage inversé est correct et que l'hôte peut mapper le nom d'hôte de mon client sur un enregistrement A et vice versa sans problème.

— penguin359

0

J'ai eu le même problème, mais apparemment causé par autre chose. La solution:

/etc/ssh/sshd_config:
#UsePAM yes

et:

sudo /etc/init.d/ssh stop;sudo /etc/init.d/ssh start;

— Ole Tange
source