Eu tenho um servidor que tem o OpenSSH em execução. Quando eu faço o log da rede local (existem algumas interfaces de rede e isso é verdade para todos eles), então o login é relativamente rápido - alguns segundos normalmente.
Eu também tenho uma VPN em ponte na rede local em que o servidor está usando o OpenVPN, e quando tento acessar o servidor pela VPN, há um atraso de 40 segundos no login - o número de 40 segundos é bastante exato e é sempre o mesmo atraso.
Olhando nos logs de depuração do sshd, vejo que um processo normal de login tem estas linhas:
Oct 18 10:05:07 server sshd[7745]: debug1: KEX done
Oct 18 10:05:07 server sshd[7745]: debug1: userauth-request for user root service ssh-connection method none
Oct 18 10:05:07 server sshd[7745]: debug1: attempt 0 failures 0
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: initializing for "root"
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: setting PAM_RHOST to "192.168.xx.xx"
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: setting PAM_TTY to "ssh"
Oct 18 10:05:10 server sshd[7745]: debug1: userauth-request for user root service ssh-connection method publickey
Oct 18 10:05:10 server sshd[7745]: debug1: attempt 1 failures 1
Oct 18 10:05:10 server sshd[7744]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Oct 18 10:05:10 server sshd[7744]: debug1: trying public key file /root/.ssh/authorized_keys
Oct 18 10:05:10 server sshd[7744]: debug1: matching key found: file /root/.ssh/authorized_keys, line 13
Quando ocorre uma conexão através da VPN, recebo linhas semelhantes com esta aparência (observe os carimbos de hora):
Oct 18 10:01:14 server sshd[31438]: debug1: KEX done
Oct 18 10:01:14 server sshd[31438]: debug1: userauth-request for user root service ssh-connection method none
Oct 18 10:01:14 server sshd[31438]: debug1: attempt 0 failures 0
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: initializing for "root"
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: setting PAM_RHOST to "192.168.xx.xx"
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: setting PAM_TTY to "ssh"
Oct 18 10:01:54 server sshd[31438]: debug1: userauth-request for user root service ssh-connection method publickey
Oct 18 10:01:54 server sshd[31438]: debug1: attempt 1 failures 1
Oct 18 10:01:54 server sshd[31438]: debug1: test whether pkalg/pkblob are acceptable
Oct 18 10:01:54 server sshd[31437]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Oct 18 10:01:54 server sshd[31437]: debug1: trying public key file /root/.ssh/authorized_keys
Oct 18 10:01:54 server sshd[31437]: debug1: matching key found: file /root/.ssh/authorized_keys, line 13
Como você pode ver, o segundo log tem uma lacuna de 40 segundos no meio - isso acontece toda vez que eu tento fazer o login através da VPN para qualquer servidor na LAN, mas nunca da rede local ou da rede pública, e estou usando a mesma chave SSH.
Os servidores são os CentOS 5 e 6, o cliente é OpenSSH no Fedora, Ubuntu e Putty no MS-Windows.
Quaisquer sugestões serão apreciadas.
Eu finalmente encontrei o problema - é a autenticação GSSAPIA.
eu configurei
GSSAPIAuthentication no
em /etc/ssh/sshd_config e agora funciona bem. Eu não tenho certeza do que o GSSAPIAuthentication (algo a ver com o Kerberos), mas como não estou usando isso, eu não me importo muito, e aparentemente quando está no OpenSSH tenta fazer a autenticação GSS e expira após 40 segundos - ou algo assim.
Provavelmente, ele está tentando fazer uma pesquisa reversa de DNS no seu endereço IP e falhando com um tempo limite eventual.
Certifique-se de que o DNS reverso para o endereço IP atribuído a você pela VPN esteja funcionando - ele não precisa necessariamente fornecer uma resposta, mas você quer ter certeza de que ela possa pelo menos fornecer uma resposta "não encontrada". responda rapidamente, em vez de ter que expirar.
Concordo com o TomH, a pesquisa inversa deve ser o primeiro lugar a procurar. Você pode desativar rapidamente a pesquisa inversa:
nano /etc/ssh/sshd_config
UseDNS pode ter um # antes, se assim remover o # e configurá-lo para:
UseDNS No
Salve o arquivo de configuração e reinicie o serviço ssh.