1 votes

ssh vers un nom .local inexistant n'échoue jamais

Si j'essaie de me connecter à un nom d'hôte .local inexistant à l'aide de la plupart des utilitaires, y compris l'application ping y telnet il s'arrête au bout de 5 secondes :

% time telnet host.example.local
host.example.local: nodename nor servname provided, or not known
telnet host.example.local  0.01s user 0.01s system 0% cpu 5.018 total

Cela correspond au délai d'attente pour le fichier .local config dans le fichier scutil --dns .

Mais quand j'essaie de ssh à un tel nom d'hôte, il ne s'arrête jamais. (Je viens de Ctrl-C Il y en avait un qui attendait toujours après 16 minutes). Je n'arrive pas à trouver d'option existante dans l'une ou l'autre des ssh_config qui semblent affecter la résolution des noms d'hôtes. La seule option que je vois qui semble pertinente est " CanonicalizeHostname "Il n'est pas configuré dans un fichier de configuration, mais je l'ai défini manuellement sur "non" sans que le comportement ne change. Ajout de -v les drapeaux à ssh ne révèle pas d'informations supplémentaires sur la résolution du nom d'hôte en dehors du fait qu'il s'agit de "Connecting to host.example.local port 22", qui est la dernière ligne de débogage produite.

J'ai essayé de capturer les requêtes MDNS pour telnet y ssh . Il semble faire une première demande, puis attendre 1s et demander à nouveau, puis à nouveau 3s plus tard, etc., chaque nouvelle tentative attendant 3 fois plus longtemps que la précédente. telnet a abandonné après trois demandes (0s, 1s, et 3s), mais ssh est arrivé à la septième demande (0, 1, 3, 9, 27, 81, 243) avant que j'arrête de regarder.

Je peux contourner le problème en définissant ConnectTimeout 5 dans ssh_config (même en le limitant à *.local ), mais cela ne fonctionne pas si la résolution du nom est complète mais que le serveur ssh distant est lent à répondre.

Comment puis-je obtenir ssh pour retarder la résolution du nom de la même manière que les autres outils réseau ?

1voto

Oskar Points 1242

Plutôt que de faire un tas de commentaires, voici comment je commencerais à résoudre ce problème. Je ne peux pas reproduire ce oui, donc je peux me tromper complètement.

Tout d'abord, est-ce que ssh utilisant une mauvaise adresse IP locale connue perd son temps rapidement ou de manière compréhensible / fiable ?

Deuxièmement, la machine potentielle (ou toute autre) se présente-t-elle comme annoncée ?

 dns-sd -B _ssh._tcp local

Troisièmement, avez-vous un appareil Apple qui utilise un proxy pour le réveil de Bonjour ?

Si ce n'est pas le cas, pourquoi essayer de se connecter par ssh à quelque chose que mdns pourrait retrouver plus tard ou que le proxy de sommeil Bonjour essaie de réveiller en permanence ce périphérique. Je pourrais voir comment ce délai plus long est conçu pour permettre au WOL via le proxy de sommeil et à de multiples segments de réseau d'avoir une chance de réveiller votre beau Mac endormi.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X