Temos uma ferramenta de automação que tenta efetuar login através de comandos ssh e send, o que funciona bem quando o servidor está em execução. Por outro lado, enquanto o servidor está sendo inicializado, nossa ferramenta verifica se a porta ssh (22) está aberta e, se estiver aberta, tenta se conectar ao servidor e enviar comandos.
No entanto, quando o servidor está na seqüência de inicialização e nossa ferramenta de automação verifica se a porta 22 está aberta, ele tenta se conectar ao servidor usando o cliente ssh mas rejeições do servidor ou o cliente ssh retorna o erro "porta ssh não está aberta".
Nós tentamos investigar este problema com o telnet e vimos que, enquanto na seqüência de inicialização, o sshd inicia e abre a porta 22 e começa a escutar, mas de alguma forma fecha novamente a porta e a abre novamente em algum momento. E é exatamente nesse momento que nossa ferramenta de automação tenta fazer o login.
Minha pergunta é; Como podemos ter certeza de que a porta ssh está aberta com sucesso e pronta para receber comandos?
Obrigado pelo seu tempo para responder Melhores cumprimentos
Primeiro, parece que a ferramenta de automação não está verificando o status de saída do ssh. Eu tentaria consertar o problema lá.
Uma solução é tentar preencher um bug para a equipe que criou a ferramenta.
Outra solução seria envolver o comando ssh em um script que faria isso de forma transparente. Por exemplo. crie um script em /opt/myproject/ssh_wraper.sh
Aqui você pode ter algo como:
SSH_EXIT_STATUS=255
while [[ $SSH_EXIT_STATUS -eq 255 ]];do
ssh ....
SSH_EXIT_STATUS=$?
done
Você pode colocar um loop à frente do login para aguardar até que a porta esteja aberta.
until nc -zvw 1 $host 22; do
sleep 2
done
ssh $host $cmd
Se você não quer o risco de um loop infinito se a condição nunca chegar a ser verdadeira, você pode definir um 'ou' valor de alguma forma. Exercício é deixado para o leitor. :)
A solução easist seria que a ferramenta de automação tentasse fazer login, se falhar, aguardar x minutos e tentar novamente?
Enquanto o servidor está inicializando, coisas estranhas como essa podem acontecer.
Você pode experimentar o status de saída obtido de algo como ssh user@host "echo 0 > /dev/zero"
Se o comando for concluído com êxito, você receberá um 0 (indicando que o sistema estava pronto). Uma tentativa malsucedida resultaria em um código de saída de 255 .
Você também pode considerar usar -o ConnectTimeout= e -o ConnectionAttempts= .
Eu também concordaria com o Steve. Talvez apenas espere um pouco mais. Dependendo de quão agressivamente sua ferramenta tenta investigar a porta, aumente o atraso antes de tentar um login.
Algo que você pode tentar é adicionar um script à sequência de inicialização do seu servidor (em /etc/rc.local, por exemplo) que desativará o firewall na porta 22. Esse script (como declarado nos comentários do /etc/rc.local) será executado após todos os outros scripts de inicialização. Assim, desde que o seu servidor não tenha terminado a sequência de inicialização, a porta 22 ainda está inacessível, atrás do firewall. Tem a vantagem de deixar a ferramenta de automação sem modificações.
Baseado em um sistema operacional RHEL6. Talvez os scripts de inicialização sejam diferentes em sua distribuição.
Isso é o que eu faço quando inicio um servidor na AWS e quero que ele esteja disponível para conectividade SSH, estou usando o bash para fazer isso:
status="notknown"
until [[ $status == "running" ]]; do
status=$(EC2 tools command to get the status)
if [[ $status != "running" ]]; then sleep 3; fi