ssh opção de tempo limite que leva mais tempo do que o especificado

Question

Tentando executar um script que confirma a configuração de data em um grande número de servidores na rede local. Os servidores são todos locais e se saudável, eu esperaria um < 1 segundo tempo de resposta. Para fazer com que o script seja executado em velocidades úteis, quero que o tempo limite da conexão seja o mais baixo possível.

Então eu tento isso como meu teste principal em um loop. (O endereço IP seria variável)

ssh -v -o ConnectTimeout=1 -o ConnectionAttempts=1 10.x.x.x date

Para servidores íntegros isso funciona bem, mas estou vendo algumas caixas que travam e parecem ignorar os valores de tempo limite. Pendurado 1 a 2 minutos em vez do 1 segundo eu esperaria. A saída detalhada parece com isso.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Applying options for *10.x.x.x*
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to *10.x.x.x* [*10.x.x.x*] port 22.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/aws_rsa type -1
debug1: identity file /root/.ssh/aws_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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

(aqui é onde fica por um a dois minutos)

Connection to *10.x.x.x* timed out while waiting to read

Um detalhe que estou percebendo é que há algum tipo de conexão, que está ocorrendo, mas é uma falha de conexão. O servidor não está íntegro e não está respondendo da maneira esperada. Existe outra opção que eu possa escolher para detectar isso e falhar mais rapidamente quando houver um problema de protocolo?

    

Answer 1

Da página de manual de ssh_config :

ConnectTimeout

Specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default system TCP timeout. This value is used only when the target is down or really unreachable, not when it refuses the connection.

Pode não estar absolutamente claro a partir dessas linhas, mas o tempo limite é usado apenas para a chamada de sistema connect() , basicamente antes da linha

debug1: Connection established.

e não para todas as outras respostas do servidor. Para isso, existe a opção ServerAliveInterval , que ping s servidor após cada X segundos para garantir que o servidor está respondendo após a conexão (por padrão, desativado). Mas você está atingindo o caso quando seu TCPKeepAlive expira, o que é outro capítulo.