Conexão SSH com chave não é confiável

2

Sou um administrador de sistemas para uma pequena empresa. Não há sysadmin real no lugar para eu perguntar quando encontro problemas. Obrigado pela ajuda

A empresa usa o Nagios para monitorar seu servidor web. Eles usam o connect_by_ssh para fazer isso com chaves públicas e privadas. O problema é que às vezes funciona, às vezes não funciona. Alguém pode sempre fazer login usando nome e senha. É apenas as chaves que nem sempre funcionam.

Alguns log para você:

Jan 16 13:23:10 localhost nagios3: SERVICE ALERT:
Server02;SSH;CRITICAL;SOFT;1;Connection timed out

Jan 16 13:24:10 localhost nagios3: SERVICE ALERT:
Server02;SSH;CRITICAL;SOFT;2;Connection timed out

Jan 16 13:24:50 localhost nagios3: SERVICE ALERT:
Server02;SSH;OK;SOFT;3;SSH OK - OpenSSH_5.3 (protocol 2.0)

Jan 16 14:15:10 localhost nagios3: SERVICE ALERT:
Server02;SSH;CRITICAL;SOFT;1;Connection timed out

Jan 16 14:15:50 localhost nagios3: SERVICE ALERT:
Server02;SSH;OK;SOFT;2;SSH OK - OpenSSH_5.3 (protocol 2.0)

Só para ter certeza, mesmo que o ssh trabalhe com usuário / senha

nmap server02.8p-hosting.com

Starting Nmap 5.00 ( http://nmap.org ) at 2014-01-16 14:16 EST
Interesting ports on abc.domain.com (xxx.xxx.xxx.xxx):
Not shown: 971 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh

Heres como parece em uma semana normal:

O que poderia ser?

Log / Debug

ssh -vvv [email protected] OpenSSH_5.5p1 Debian-6+squeeze4, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to abc.domain.com [xxx.xxx.xxx.xxx] port 22. debug1: connect to address xxx.xxx.xxx.xxx port 22: Connection timed out ssh: connect to host abc.domain.com port 22: Connection timed out 
    
por littleadmin 16.01.2014 / 20:36

3 respostas

0

Isso se parece mais com um problema de tempo limite do que com o próprio SSH.

Dê uma olhada nos seus testes de nagios.

Você provavelmente deseja adicionar uma opção -t ao check_by_ssh:

 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)

Você provavelmente também deve verificar service_check_timeout em seu nagios.cfg.

A mina está definida para 60s.

link

    
por 16.01.2014 / 20:46
0

Infelizmente, pode haver várias coisas, a primeira coisa que eu faço é ativar o registro ssh no servidor ssh para 'DEBUG'.

Além disso, suponho que você esteja usando o check_ssh para monitorar o servidor ssh nas caixas. Dentro de nagios, existem algumas coisas que você pode fazer para ver qual comando está sendo executado exatamente. Se você tiver acesso ssh ao servidor nagios, você pode apenas fazer o login e olhar para o nagios services.cfg, para encontrar exatamente o que o plugin nagios está sendo chamado, com exatamente quais switches.

Então olhe para commands.cfg para ver o que está sendo executado. Em seguida, tente usar esse comando para testar o servidor ssh manualmente a partir da linha de comando.

A outra maneira é usar a interface do nagios. Na barra de navegação à esquerda, na parte inferior há um link de configuração. Clique nele, em seguida, usando o menu suspenso, vá para serviços e encontre exatamente qual plug-in está sendo chamado para esse serviço. Em seguida, usando a expansão do comando dropdown goto e obtenha o comando dessa forma. Em seguida, verifique manualmente.

Por fim, verifique se o SELinux está habilitado. Nesse caso, o contexto do selinux provavelmente precisa ser alterado no arquivo. Se você estiver usando algo como fantoche ou chef, é possível que ele esteja brigando pelo arquivo sendo consertado e depois quebrado. Etc.

ATUALIZAÇÃO:

Eu tentaria adicionar -E e / ou -S ao comando check_by_ssh. Às vezes a saída ssh estranha pode atrapalhar a conexão se ela acha que deveria estar esperando. Além disso, adicionar -v dará uma indicação do que está acontecendo.

    
por 16.01.2014 / 20:43
0

Eu já vi isso antes como um problema de DNS.

Talvez a pesquisa do rDNS atinja o tempo limite (conforme observado nos comentários acima) ou talvez o servidor seja, na verdade, vários servidores que usam round-robin O DNS (vários registros A para um nome de domínio) e apenas um subconjunto dos servidores está offline, não está executando o SSH ou falha no teste.

    
por 15.02.2014 / 01:31