SSH sur un ordinateur local est lent avec Mac OS X Server

J'ai une machine locale et un serveur Mac OSX (Mavericks).

Je peux ouvrir une session SSH sur le serveur à partir de la machine locale:

user> ssh serveruser@myserver.local
serveruser@myserver>

Cependant, la connexion SSH est très lente. C'est aussi lent que ma connexion internet. Il n'y a pas de différence entre une connexion ssh distante à un serveur distant et cette connexion ssh locale. Et toutes les 10 à 20 secondes, j'ai un pic de décalage de 1 à 2 secondes, où le terminal ne répond pas, puis je vois mes actions au bout de quelques secondes.

Comment cette connexion locale peut-elle être affectée par ma vitesse Internet?

• Remarque: lors de l'utilisation du partage d'écran, la qualité et les délais sont vraiment mauvais. Je risque donc d'avoir le même problème (la connexion passe par Internet plutôt que localement).
• Note2: Les 2 machines sont connectées via wifi à un routeur. Si je copie des fichiers d’une machine à une autre, la vitesse est d’environ 20 Mo / s. Donc, la connexion locale est assez bonne.

Edit: Une partie du test suggéré par @MariusMatutiae:

# very inconsistent ping times.
➜  ~  ping 10.0.0.34
PING 10.0.0.34 (10.0.0.34): 56 data bytes
64 bytes from 10.0.0.34: icmp_seq=0 ttl=64 time=142.699 ms
64 bytes from 10.0.0.34: icmp_seq=1 ttl=64 time=571.248 ms
64 bytes from 10.0.0.34: icmp_seq=2 ttl=64 time=193.275 ms
64 bytes from 10.0.0.34: icmp_seq=3 ttl=64 time=211.617 ms
64 bytes from 10.0.0.34: icmp_seq=4 ttl=64 time=28.381 ms
64 bytes from 10.0.0.34: icmp_seq=5 ttl=64 time=337.638 ms
64 bytes from 10.0.0.34: icmp_seq=6 ttl=64 time=78.221 ms
64 bytes from 10.0.0.34: icmp_seq=7 ttl=64 time=100.819 ms
64 bytes from 10.0.0.34: icmp_seq=8 ttl=64 time=11.514 ms
64 bytes from 10.0.0.34: icmp_seq=9 ttl=64 time=141.167 ms
64 bytes from 10.0.0.34: icmp_seq=10 ttl=64 time=166.168 ms
^C
--- 10.0.0.34 ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.514/180.250/571.248/150.814 ms

# trying google for comparison
➜  ~  ping www.google.com
PING www.google.com (173.194.113.176): 56 data bytes
64 bytes from 173.194.113.176: icmp_seq=0 ttl=52 time=28.173 ms
64 bytes from 173.194.113.176: icmp_seq=1 ttl=52 time=65.306 ms
64 bytes from 173.194.113.176: icmp_seq=2 ttl=52 time=33.831 ms
64 bytes from 173.194.113.176: icmp_seq=3 ttl=52 time=24.287 ms
64 bytes from 173.194.113.176: icmp_seq=4 ttl=52 time=24.642 ms
64 bytes from 173.194.113.176: icmp_seq=5 ttl=52 time=36.327 ms
64 bytes from 173.194.113.176: icmp_seq=6 ttl=52 time=26.143 ms
64 bytes from 173.194.113.176: icmp_seq=7 ttl=52 time=25.572 ms
^C
--- www.google.com ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 24.287/33.035/65.306/12.878 ms

# traceroute seems direct
➜  ~  traceroute 10.0.0.34
traceroute to 10.0.0.34 (10.0.0.34), 64 hops max, 52 byte packets
 1  10.0.0.34 (10.0.0.34)  150.568 ms  4.263 ms  2.603 ms

Je ne pouvais pas commencer sudo /usr/sbin/ssd -Dd, l'erreur est:

Lier au port 22 sur :: échec: adresse déjà utilisée. Ne peut lier aucune adresse.

$>  sudo lsof -i :22
COMMAND     PID      USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
launchd       1      root   34u  IPv6 0xb1ed5bcf5a84....      0t0  TCP *:ssh (LISTEN)
launchd       1      root   35u  IPv4 0xb1ed5bcf5a84....      0t0  TCP *:ssh (LISTEN)
$> sudo kill 1 # machine restarts. I'm not a smart man...

Et je ne pouvais pas scp, il dit: scp: /home/server_user/: Operation not supported(la connexion à distance est activée sur le serveur)

Cela peut ou non s'appliquer, mais je le publie parce que mon problème est similaire et j'ai trouvé une solution de contournement.

Pour les connexions allant sur mon Mac (tel que SSH), je connaissais un décalage / latence. Par exemple, je tapais dans le shell (ligne de commande) et mes frappes au clavier n'apparaissaient pas avant 200 à 600 millisecondes peut-être, et elles étaient toutes passées en rafale. Cela arrivait tout le temps et était exaspérant.

Dans ce fil de discussion , j'ai lu que

[Apple / OSX] met le réseau sans fil hors tension entre les paquets

Finalement, je suis venu à l’utiliser comme solution (exécutez-le sur le même ordinateur client que vous utilisez depuis SSH ):

ssh username@macservername 'while true; do echo -n .; sleep 0.1; done' > /dev/null

Ceci établit un flux constant d'octets traversant la connexion réseau du client au Mac, incitant le Mac à ne pas mettre le wifi en veille.

Il est difficile de diagnostiquer un problème avec si peu d’informations. Voici une liste de choses que vous pourriez faire pour améliorer vos chances de diagnostiquer correctement votre problème:

1. horloge un transfert d'un fichier volumineux (disons 1 Go). Tu peux le faire comme ça

   time scp largefile remore_user@remote_server:/home/remote_user
   

2. Fais-tu autre chose entre-temps? Télécharger quelque chose, utiliser une connexion vnc , effectuer un calcul intense, mettre à jour un système ou un autre système sur le même réseau local? Il serait utile de regarder une image de la sortie de l'un des nombreux moniteurs système graphiques, qui détaillent l'utilisation du processeur, du trafic et de la mémoire, sur les deux machines, au fur et à mesure que vous vous connectez au serveur distant.

3. Effectuez une traceroute de l'adresse IP du serveur à partir de la machine locale.

4. Examinez la table de routage de chaque système pour vous assurer qu'ils se trouvent sur le même sous-réseau.

5. vérifier les interférences radio. Sous Linux, vous pouvez le faire avec la commande:

   sudo iw dev wlan0 scan
   

   qui montrera le canal et la force du signal de votre wifi, ainsi que ceux des réseaux voisins.

6. vérifier les temps de ping entre le client et le serveur;

7. changer l'algorithme de chiffrement;

8. observez le processus de journalisation en détail. Sur le serveur, vous devez démarrer ssh non pas en mode démon, mais en mode débogage:

    /usr/sbin/sshd -Dd
   

   tandis que sur le client

    ssh -vvv remote_user@remote_server
   

   pour vérifier s'il y a quelque chose d'inhabituel.

N'importe lequel de ces éléments pourrait fournir des informations utiles. Je suis sûr que les gens plus intelligents que je serai en mesure d'ajouter des chèques à cette même liste.