Comment puis-je supprimer /etc/issue sans perdre les messages d'erreur ?

Oui   Ajouter un fichier ~/.ssh/config contenant :

LogLevel ERROR

OpenSSH affiche le contenu de /etc/issue du serveur distant. Ce paramètre permet de désactiver cet affichage. Très utile lorsque l'entreprise repo Git à distance comme un avertissement de sécurité ennuyeux.

Le site ssh config page d'accueil dit :

LogLevel

Donne le niveau de verbosité qui est utilisé lors de l'enregistrement des messages. de ssh(1). Les valeurs possibles sont : QUIET , FATAL , ERROR , INFO , VERBOSE , DEBUG , DEBUG1 , DEBUG2 y DEBUG3 . La valeur par défaut est INFO . DEBUG y DEBUG1 sont équivalentes. DEBUG2 y DEBUG3 spécifient chacun des niveaux plus élevés de sortie verbeuse.

Astuce supplémentaire   Ajoutez également dans votre ~/.ssh/config

Host *
#    StrictHostKeyChecking no
     StrictHostKeyChecking accept-new

Cela évite un autre message ennuyeux. Lors de la connexion à un nouvel hôte, la question de sécurité suivante bloque la connexion en cours. L'astuce ci-dessus suppose toujours que yes . Néanmoins, dans la pratique, vous répondez toujours yes n'est-ce pas ?

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: Comme l'a souligné Chris Adams en utilisant StrictHostKeyChecking no peut permettre à un Attaque de type "Man-in-the-middle une meilleure utilisation StrictHostKeyChecking accept-new comme expliqué dans https://man.openbsd.org/ssh_config.5#StrictHostKeyChecking .

Ni mon serveur local OS X, ni mon serveur Ubuntu n'impriment. /etc/issue lorsque je me connecte (ni avec un Shell ni avec l'exécution d'une commande à distance), je ne peux donc pas reproduire votre problème. Je vais essayer ceci de mémoire.

Si cela ne vous dérange pas de faire deux connexions, vous pouvez le faire :

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

La première commande ssh provoquera /etc/issue à être imprimé deux fois (une fois par le système, une fois par cat ), donc le nombre de lignes sera le double de celui de /etc/issue . La sortie de la deuxième commande ne montrera que la sortie de ce nombre de lignes plus une.

Si votre journal contient plusieurs sessions dans un seul fichier, vous pouvez demander à votre script de faire quelque chose comme suit echo START LOGGING avant d'exécuter toute autre commande, et ensuite echo END LOGGING avant de se déconnecter, et ensuite utiliser un simple Shell Shell (en utilisant sed ou awk) dépouiller tout le contenu du fichier entre END et START (c'est-à-dire le boilerplate avant chaque login).

EDIT:

Je vois maintenant que vous ne créez pas de logs, mais que vous recherchez plutôt les messages dans la fenêtre - je recommande de créer des logs et de les analyser au lieu de se fier uniquement à la sortie de la fenêtre du terminal - c'est beaucoup plus flexible, et cela permet de se référer aux erreurs des sessions précédentes si nécessaire.

Vous pouvez le définir à partir de la ligne de commande avec :

ssh -o loglevel=ERROR

Si vous utilisez rsync (comme ce fut le cas pour moi lorsque j'ai cherché ce problème sur Google), vous pouvez le faire en spécifiant la ligne de commande de connexion ssh à rsync comme :

rsync -e 'ssh -o loglevel=ERROR'

Non.

Lorsque l'hôte renvoie des lignes de texte, comment le client SSH peut-il savoir quelles lignes proviennent du /etc/issue de l'hôte, et lesquelles sont des messages plus intéressants ? Il ne le peut pas.