Como posso suprimir o / etc / issue sem perder as mensagens de erro?

Question

É possível dizer ao cliente ssh para não imprimir as conexões de /etc/issue para stdout ao se conectar a um host remoto, mas para imprimir qualquer outra mensagem de diagnóstico (por exemplo, erro)?

Usar ssh -q ou ter LogLevel quiet em ~/.ssh/config suprime a impressão /etc/issue , mas também desativa as mensagens de erro. Eu também tentei touch ing ~/.hushlogin - isso impede que /etc/motd seja impresso, mas não afeta /etc/issue .

A solução mais óbvia é apenas remover /etc/issue , mas a política da empresa determina que o arquivo esteja lá com avisos terríveis sobre o acesso não autorizado. Isso não é negociável. Infelizmente, eu tenho um monte de scripts que são executados em alguns hosts via ssh, e os arquivos de log são a) muito grandes eb) cheios de legalês. Como muitas coisas são executadas sem supervisão, não quero perder nenhuma mensagem de erro impressa.

    

Answer 1

Sim Adicione um arquivo ~/.ssh/config contendo:

LogLevel ERROR

O OpenSSH exibe o conteúdo de /etc/issue do servidor remoto. Esse parâmetro desabilita essa exibição. Muito útil quando a empresa remota Git repo como um aviso de segurança irritante.

A ssh config manpage diz:

LogLevel

Gives the verbosity level that is used when logging messages from ssh(1). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of verbose output.

Truque extra Adicione também no seu ~/.ssh/config

Host *
     StrictHostKeyChecking no

Isso evita outra mensagem irritante. Ao se conectar a um novo host, a seguinte pergunta de segurança bloqueia a conexão em andamento. O truque acima sempre assume yes . No entanto, na prática você sempre responde yes , não é?

The authenticity of host 'newhostname (11.222.33.44)' can't be established.
RSA key fingerprint is aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00.
Are you sure you want to continue connecting (yes/no)?

    

Answer 2

Nem meu host local do OS X nem meu servidor Ubuntu imprimem /etc/issue quando eu o ssh in (nem com um shell nem com a execução de um comando remoto), portanto não consigo reproduzir seu problema. Vou tentar isso da memória.

Se você não se importar em fazer duas conexões, poderá fazer isso:

num_lines="$(ssh yourhost 'cat /etc/issue' | wc -l)";
ssh yourhost 'your real command here' | tail +$(($num_lines / 2 + 1));

O primeiro comando ssh fará com que /etc/issue seja impresso duas vezes (uma vez pelo sistema, uma vez por cat ), então o número de linhas será o dobro de /etc/issue . A saída do segundo comando mostrará apenas a saída daquele número de linhas mais uma.

    

Answer 3

Se o seu log tiver várias sessões anexadas em um arquivo, você pode fazer com que o script faça algo como echo START LOGGING antes de executar qualquer outro comando, e echo END LOGGING antes de desconectar e usar um script de shell simples ( usando sed ou awk) retire todo o conteúdo do arquivo entre END e START (ou seja, o clichê antes de cada login).

EDITAR:

Agora vejo que você não está registrando, mas procurando mensagens na janela - eu recomendo criar logs e verificar os logs em vez de confiar apenas na saída da janela do terminal - isso é muito mais flexível e permite a consulta de erros de sessões anteriores, se necessário.

    

Answer 4

Não.

Quando o host envia de volta linhas de texto, como o cliente SSH pode saber quais linhas vieram do arquivo / etc / issue do host, e quais são as mensagens mais interessantes? Não pode.

    

Answer 5

Você pode definir isso na linha de comando com:

ssh -o loglevel=ERROR

Se você estiver usando rsync (como foi o caso para mim quando pesquisando este problema), você pode fazer isso especificando a linha de comando de conexão ssh para rsync como:

rsync -e 'ssh -o loglevel=ERROR'