SSH em uma máquina local é lento com o servidor Mac os X

5

Eu tenho uma máquina local e um servidor mac osx (mavericks).

Eu posso abrir uma sessão ssh no servidor a partir da máquina local:

user> ssh [email protected]
serveruser@myserver>

No entanto, a conexão ssh é muito lenta. É tão lento quanto a minha conexão com a internet. Não há diferença entre uma conexão ssh remota com um servidor remoto e esta conexão ssh local. E a cada 10 a 20 segundos, tenho um pico de atraso de 1 a 2 segundos, em que o terminal não responde e, em seguida, vejo minhas ações após alguns segundos.

Como essa conexão local pode ser afetada pela minha velocidade de internet?

  • Nota: Ao usar o compartilhamento de tela, a qualidade e o atraso são realmente ruins, por isso posso ter o mesmo problema (a conexão passando pela Internet em vez de apenas localmente)
  • Nota2: As duas máquinas estão conectadas via Wi-Fi a um roteador. Se eu copiar arquivos de uma máquina para outra, a velocidade é de cerca de 20MB / s. Então a conexão local é muito boa.

Edit: Alguns dos testes sugeridos pelo @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

Não foi possível iniciar sudo /usr/sbin/ssd -Dd , o erro é:

Vincular à porta 22 em :: failed: Endereço já em uso. Não é possível vincular nenhum endereço.

$>  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...

E eu não sabia scp, diz: scp: /home/server_user/: Operation not supported (login remoto está habilitado no servidor)

    
por Benjamin Crouzier 07.01.2014 / 10:53

2 respostas

0

É difícil diagnosticar um problema com tão pouca informação. Aqui está uma lista de coisas que você pode fazer para melhorar suas chances de diagnosticar corretamente seu problema:

1) relógio uma transferência de um arquivo grande (digamos 1GB). Você pode fazer assim

  time scp largefile remore_user@remote_server:/home/remote_user

2) Você está fazendo mais alguma coisa nesse meio tempo? Fazendo o download de algo, usando uma conexão vnc , executando uma computação intensa, atualizando o sistema ou talvez outro sistema na mesma LAN? Seria útil olhar para uma imagem da saída de um dos vários monitores de sistema gráfico, que detalham o uso da CPU, tráfego e uso de memória, em qualquer máquina, como você está ssh'ing no servidor remoto.

3) Faça um traceroute do endereço IP do servidor da máquina local.

4) veja a tabela de roteamento de cada sistema para ter certeza de que eles estão na mesma sub-rede.

5) verifique a interferência de rádio. No Linux, você pode fazer isso com o comando:

  sudo iw dev wlan0 scan

que mostrará o canal e a força do sinal do seu wifi, bem como os das redes vizinhas.

6) verifique ping vezes entre cliente e servidor;

7) alterar o algoritmo de criptografia;

8) observe o processo de registro em detalhes. No servidor, você precisa iniciar ssh não no modo daemon, mas no modo de depuração:

   /usr/sbin/sshd -Dd

enquanto no cliente

   ssh -vvv remote_user@remote_server

para verificar se há algo incomum.

Qualquer uma das opções acima pode fornecer informações úteis. Tenho certeza de que pessoas mais inteligentes do que eu serão capazes de adicionar cheques à mesma lista.

    
por 07.01.2014 / 11:32
0

Isso pode ou não se aplicar, mas estou divulgando porque meu problema é semelhante e encontrei uma solução alternativa.

Para conexões indo para meu Mac (como SSH), eu estava passando por atraso / latência. Por exemplo, eu digitaria no shell (linha de comando), e meus pressionamentos de tecla não apareceriam até talvez 200 a 600 milissegundos depois, e todos apareceriam em uma explosão. Isso aconteceu o tempo todo e foi enfurecedor.

Em este tópico do fórum , eu leia isso

[Apple/OSX is] powering down the wireless between packets

Por fim, resolvi usar isso como uma solução (execute isso no mesmo computador cliente em que você está usando o SSHing ):

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

Isso estabelece um fluxo constante de bytes fluindo através da conexão de rede do cliente para o Mac, enganando o Mac para não colocar o wifi em suspensão.

    
por 03.03.2017 / 16:09