leva muito tempo para se conectar ao servidor ssh

Question

Eu tenho duas VMs com arch linux e debian (em execução em virtual box ). Não muito tempo atrás, começou a levar muito tempo se conectando a arch VM sobre ssh . A primeira vez depois de um tempo, sucessivas tentativas acontecem rapidamente. Aqui está o que eu vejo no arch VM:

debug1: userauth-request for user yuri service ssh-connection method none
debug1: attempt 0 failures 0
debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line
debug2: parse_server_config: config reprocess config len 314
debug2: input_userauth_request: setting up authctxt for yuri
debug1: PAM: initializing for "yuri"
debug1: PAM: setting PAM_RHOST to "10.0.2.2"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: input_userauth_request: try method none
Failed none for yuri from 10.0.2.2 port 35786 ssh2

10.0.2.2 é o gateway padrão para as VMs. O que isso tudo significa?

P.S. Aqui está uma boa resposta , graças à qual consegui fazer algum progresso na pesquisa do assunto.

    

Answer 1

My guess is, that the problem are DNS requests timeouts. Try ... turning off the UseDNS option on the server you are connecting to.

O log do servidor praticamente confirmou isso (tão bem feito para postá-lo:).

debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line

Olhando para man sshd_config :

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Observe que isso é praticamente sem sentido . A verificação não mata a conexão. Se não passar, registra apenas uma mensagem de toque de dedo:

Jul 9 05:43:00 brick sshd[18971]: Address 200.41.233.234 maps to host234.advance.com.ar, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

que serve apenas para gerar falsos positivos assustadores para usuários com ISPs incompetentes.

OK, então como isso pode causar um atraso?

Se o servidor DNS não responder imediatamente, o cliente tenderá a esperar & tente novamente. (No caso de um pacote DNS foi atrasado ou perdido devido ao congestionamento da rede). Se o servidor DNS não estiver respondendo, o cliente acabará desistindo. Por exemplo. dig no meu sistema tenta novamente por 15 segundos. (Ele usa um código de biblioteca de DNS mais específico, mas o princípio é o mesmo).

$ time dig invalid @192.0.2.1

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> invalid @192.0.2.1
;; global options: +cmd
;; connection timed out; no servers could be reached

real    0m15.020s
user    0m0.010s
sys         0m0.011s

Portanto, o problema é que a pesquisa inversa não recebe uma resposta. Você pode executar a mesma pesquisa no servidor manualmente, e deverá ver o mesmo atraso que o ssh. getent hosts 10.0.2.2 .

    

Answer 2

Nesta fase, existem muitas possibilidades que podem estar causando uma conexão lenta. De este link, um problema que vejo está relacionado à criptografia.

Finally I know what is the issue.

my /home/user dir is encrypted and therefore ssh wasn't able to access it unless I am logged in.

Também há mais uma possibilidade de aqui relacionado ao serviço SELinux .

Yes, SELinux is likely the cause. The .ssh dir is probably mislabeled. Look at /var/log/audit/audit.log. It should be labeled ssh_home_t. Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.

Também em este link , também ver a autenticação do PAM pode ser uma razão para o SSH lento.

Edit your "/etc/ssh/ssh_config" and comment out these lines:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no