Come posso eliminare / etc / issue senza perdere i messaggi di errore?

È possibile dire al client ssh di non stampare le connessioni di /etc/issuea stdout quando si connette a un host remoto, ma di stampare qualsiasi altro messaggio diagnostico (ad es. Errore)?

Sia utilizzando ssh -qo che hanno LogLevel quietin ~/.ssh/configsopprime la /etc/issuestampa, ma anche disattivare i messaggi di errore. Ho provato touching ~/.hushlogin, come pure - che smette di /etc/motdessere stampato, ma non incide /etc/issue.

La soluzione più ovvia è solo quella di rimuoverla /etc/issue, ma la politica aziendale impone che il file sia presente con avvertimenti terribili sull'accesso non autorizzato. Questo non è negoziabile. Sfortunatamente, ho un sacco di script che attraversano parecchi host tramite ssh, e i file di registro sono a) molto grandi eb) pieni di legalese. Dato che molte cose vengono eseguite incustodite, non voglio perdere alcun messaggio di errore stampato.

Sì   Aggiungi un file ~/.ssh/configcontenente:

LogLevel ERROR

OpenSSH visualizza il contenuto del /etc/issueserver remoto. Quel parametro disabilita questo display. Molto utile quando il repository Git remoto dell'azienda è un fastidioso avviso di sicurezza.

La ssh configmanpage dice:

LogLevel

Fornisce il livello di verbosità utilizzato durante la registrazione dei messaggi da ssh (1). I valori possibili sono: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, e DEBUG3. L'impostazione predefinita è INFO. DEBUGe DEBUG1sono equivalenti. DEBUG2e DEBUG3ciascuno specifica livelli più alti di output dettagliato.

Trucco extra   Aggiungi anche nel tuo~/.ssh/config

Host *
#    StrictHostKeyChecking no
     StrictHostKeyChecking accept-new

Questo impedisce un altro messaggio fastidioso. Durante la connessione a un nuovo host, la seguente domanda di sicurezza blocca la connessione in corso. Il trucco di cui sopra presuppone sempre yes. Tuttavia, in pratica yes, rispondi sempre , no?

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)?

EDIT: come sottolineato da Chris Adams l' utilizzo StrictHostKeyChecking nopuò consentire un attacco Man-in-the-middle , un uso migliore StrictHostKeyChecking accept-newcome spiegato in https://man.openbsd.org/ssh_config.5#StrictHostKeyChecking .

Né il mio localhost OS X né il mio server Ubuntu stampano /etc/issuequando accedo (né con una shell né con l'esecuzione di un comando remoto), quindi non riesco a riprodurre il problema. Proverò questo dalla memoria.

Se non ti dispiace fare due connessioni, puoi farlo:

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

Il primo comando ssh verrà /etc/issuestampato due volte (una volta dal sistema, una volta da cat), quindi il numero di righe sarà il doppio di quello di /etc/issue. L'output del secondo comando mostrerà solo l'output di quel numero di righe più uno.

Se al tuo registro saranno aggiunte molte sessioni in un unico file, potresti fare in modo che lo script echo START LOGGINGesegua qualcosa di simile prima di eseguire qualsiasi altro comando, quindi echo END LOGGINGprima di disconnettersi e quindi utilizzare un semplice script di shell (usando sed o awk) rimuovi tutti i contenuti del file tra END e START (ovvero la piastra della caldaia prima di ogni accesso).

MODIFICARE:

Ora vedo che non stai registrando, ma invece cerchi messaggi nella finestra - ti consiglio di creare registri e scansionare i registri invece di fare affidamento solo sull'output della finestra del terminale - questo è molto più flessibile e consente di rimandare agli errori delle sessioni precedenti se necessario.

No.

Quando l'host restituisce righe di testo, come può il client SSH sapere quali righe provengono dal problema / etc / dell'host e quali sono i messaggi più interessanti? Non può.

Puoi impostarlo dalla riga di comando con:

ssh -o loglevel=ERROR

Se stai usando rsync (come è stato per me quando ho cercato su Google questo problema), puoi farlo specificando la riga di comando di connessione ssh a rsync come:

rsync -e 'ssh -o loglevel=ERROR'