O mais provável é que, quando executado sob cron , a conexão foi fechada antes que o servidor remoto tivesse a chance de emitir seu banner. Isso ocorre porque openssl s_client opera uma conexão bidirecional entre seu stdio e o soquete para o servidor remoto:
- Copia stdin para o soquete
- Copia dados recebidos no soquete para stdout
Quando executado em cron , a primeira cópia é finalizada imediatamente, porque stdin está conectado a /dev/null . Isso fez com que openssl fosse encerrado imediatamente.
Você poderia mitigar isso redirecionando a entrada de openssl para algo que bloqueia para sempre, ou melhor ainda, algo como sleep 1 , o que eliminará a necessidade de timeout .
Ainda assim, esperar um segundo é uma forma particularmente frágil de se conectar e esperar por um banner. Não só é um tempo limite curto, mas também não faz com que o comando saia antes da expiração do tempo limite quando o banner é recebido. Para algo assim, você está procurando expect .
A propósito:
Outros provavelmente discordarão, mas acredito que seu uso do termo "console" nesta questão seja inexato. Na verdade, você obteria o comportamento descrito pela primeira vez em qualquer sessão de terminal, o que poderia ser, entre outras coisas:
- uma sessão de terminal ssh,
- um emulador de terminal (como
xtermou as substituições modernas) na sua GUI - janela
screen, - uma conexão de modem serial,
- ou o console do sistema real.
Eu acredito que o termo "console" deve referir-se exclusivamente ao último, mas todas essas são sessões de terminal.