Longo atraso no SSH. Como corrigir o problema do resolv.conf

Question

Eu tenho um servidor Ubuntu 9.04. Estou enfrentando um longo atraso ao fazer o SSH para o servidor. Eu adicionei "UseDNS no" em sshd_conf e comentei "GSSAPIAuthentication yes" em ssh_conf, ainda assim o problema está lá.

Ao ver /etc/resolve.conf , parece que o problema está aí.

Conteúdo de /etc/resolve.conf :

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.xx.xx.xx
nameserver 10.xx.xxx.xx
search xyz.com

Eu li em algum lugar que várias entradas de nameserver aqui podem causar problemas. Estou usando um cliente VPN nesse servidor para conectar-me à rede da minha empresa e parece que as entradas são adicionadas automaticamente pelo cliente vpn.

Como corrijo esses longos atrasos sem interromper meus clientes / conexões VPN. Não me importo de não poder usar nomes / aliases de servidor da minha empresa enquanto estiver conectando via VPN a partir do meu servidor, mas gostaria de corrigir o atraso SSH longo ao conectar-se ao servidor.

===========================

1. Sim, eu quis dizer / etc / sshd_conf

2. Estou usando o endereço IP para se conectar diretamente

3. Eu não estou usando VPN para conectar ao meu servidor (onde há atraso). No entanto, um cliente VPN está sendo executado no servidor para se conectar ainda a outra rede. O login do meu servidor usando o cliente VPN é rápido o suficiente.

4. Desculpe, eu não entendi AddressFamily, inet e alguns outros comentários.

Aqui estão os registros de depuração no lado do cliente (com aproximadamente atrasos):

OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Connecting to ......
debug1: Connection established.
debug1: identity file ..... type -1
debug1: identity file ..... type -1
debug1: identity file ..... type -1
debug1: identity file ..... type -1

AGORA TEM 4 SEGUNDOS DE PAUSA

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

AGORA HÁ 15 A 20 SEGUNDOS DE PAUSA

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

AGORA HÁ 40-50 segundos de pausa

Em seguida, ele verifica a impressão digital, etc, e se conecta rapidamente.

    

Answer 1

sshd_conf

Só para ter certeza, você realmente quer dizer / etc / ssh / sshd_config , não sshd_conf, certo? Eu não acho que o sshd_conf ou o sshd.conf sejam arquivos válidos para o OpenSSH no Ubuntu, então editá-los não fará nada.

I read somewhere that multiple nameserver entries here can cause problems.

Vários servidores de nomes em /etc/resolv.conf não devem causar nenhum problema, embora se o primeiro servidor de nomes da lista for lento, isso afetará seu sistema. Na verdade, é uma boa prática listar servidores de nomes redundantes em /etc/resolv.conf no caso de um nameserver ficar inativo.

Antes de cavar muito fundo, tente determinar se esse problema está no lado do cliente ou no lado do servidor.

No lado do cliente, ative o modo detalhado do SSH. Isto irá dizer-lhe o progresso da conexão do cliente para o servidor. Se a conexão do cliente para o servidor for lenta, você poderá ver um atraso antes de linhas como "debug1: conexão estabelecida". ou "debug1: O servidor aceita a chave: pkalg ssh-dss blen 435".

No lado do servidor, siga os logs SSH em uma janela separada e observe os logs. Você pode querer aumentar o log para "VERBOSE".

Atualização:

Não use sshd_conf. Adicione o seguinte em / etc / ssh / sshd_config, reinicie o SSH e deixe-nos saber o que acontece.

UseDNS no

Mude uma coisa de cada vez. Se o UseDNS não funcionar, tente "GSSAPIAuthentication no".

    

Answer 2

Você deve ser capaz de criar seu próprio arquivo de configuração no nível do usuário em ~ / .ssh / config

A partir daqui, você pode mapear o host para o ip numérico e deve ignorar totalmente a pesquisa de DNS. Por exemplo, digamos que você quer ssh para "glitch.somewhere.net", no seu arquivo de configuração, faça algo como:

Host glitch

  HostName 192.168.0.1
  User JP19

Você pode inserir uma tonelada de opções aqui, conforme descrito na página do manual ssh_config (man ssh_config). A chave aqui é que o "HostName" é definido como um IP numérico em vez de um nome de host verdadeiro. Essencialmente, você está configurando vários atalhos. Então você pode ssh para glitch1, glitch2, goog, ...

Uma pegadinha em potencial é garantir que as permissões estejam configuradas corretamente para que o ssh não surte. Além disso, eu recomendo rodar ssh no modo verbose (ssh -vvv) para ter certeza de que ele está pendurado onde você pensa que está, mas eu suspeito que você esteja no caminho certo.

    

Answer 3

Primeiras perguntas, você está se conectando através de endereços IP aos servidores ou através de nomes de domínio?

Segunda pergunta, você consegue se conectar aos servidores externamente ou somente através da VPN?

A causa provável do atraso são as velocidades de VPN e conexão, não necessariamente o resultado de uma conexão SSH.

    

Answer 4

Você poderia tentar o AddressFamily inet? Ele desabilita o ipv6 que aciona um bug em alguns sistemas antigos (está no openssq faq).

Talvez um pouco bobo, mas você reiniciou o servidor ssh depois de fazer as alterações?

    

Answer 5

Problema

Eu tive um problema semelhante de logar em servidores CentOS / Fedora do meu laptop Fedora. Ao conectar-se a partir de uma rede externa, o processo foi rápido, com um atraso de dois, talvez três segundos antes que o prompt de senha fosse ativado. No entanto, conectando-se a partir da rede interna, levaria de 10 a 20 segundos para chegar ao prompt de senha.

Solução :

edite ~ / .ssh / config

Host 192.168.0... (your target ip)
GSSAPIAuthentication no
PasswordAuthentication yes
ChallengeResponseAuthentication no
ForwardX11 yes

Certifique-se de que as permissões ~ / .ssh / config são somente leitura para grupo / outros, somente para o usuário. (chmod para 644).

    

Answer 6

Um atraso de log ao usar o SSH também pode ser causado por processos bloqueados e / ou configuração incorreta de tarefas cron, portanto, verifique-os também (por exemplo, crontab -l)