Is it possible to tell the ssh client to not print the connects of /etc/issue to stdout when connecting to a remote host, but to print out any other diagnostic (e.g. error) messages?

Either using ssh -q or having LogLevel quiet in ~/.ssh/config suppresses the /etc/issue printing, but also turn off error messages. I've tried touching ~/.hushlogin as well - that stops /etc/motd being printed, but doesn't affect /etc/issue.

The most obvious solution is just to remove /etc/issue, but company policy dictates the file be there with dire warnings about unauthorised access. This is non-negotiable. Unfortunately, I've got a bunch of scripts that run across quite a few hosts via ssh, and the log files are a) very large and b) full of legalese. Since quite a lot of stuff runs unattended, I don't want to lose any error messages that are printed.

  • Thoses legalses must be static. I suggest an automated removal from log using awk or sed. I ll come with a solution tomorrow. – Archemar Oct 28 '15 at 18:25

Yes   Add a file ~/.ssh/config containing:

LogLevel ERROR

OpenSSH displays the content of /etc/issue from the remote server. That parameter disables this display. Very useful when the company remote Git repo as an annoying security warning.

The ssh config manpage says:


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.

Extra trick   Add also in your ~/.ssh/config

Host *
#    StrictHostKeyChecking no
     StrictHostKeyChecking accept-new

This prevents another annoying message. When connecting to a new host, the following security question blocks the ongoing connection. The above trick always assumes yes. Nevertheless in practice you always answer yes, isn't it?

The authenticity of host 'newhostname (' 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: As pointed out by Chris Adams using StrictHostKeyChecking no may allow a Man-in-the-middle attack, better use StrictHostKeyChecking accept-new as explained in https://man.openbsd.org/ssh_config.5#StrictHostKeyChecking.

  • It's very dangerous to run with StrictHostKeyChecking no as that allows an attacker to MITM your connection. If you want to accept new keys automatically, use accept-new as per: man.openbsd.org/ssh_config.5#StrictHostKeyChecking – Chris Adams Jul 17 at 20:11
  • Thank you @ChrisAdams for your feedback. 👍 Have fun 😎 – olibre Aug 27 at 23:32

Neither my OS X localhost or my Ubuntu server print /etc/issue when I ssh in (neither with a shell nor with executing a remote command), so I cannot reproduce your problem. I will try this from memory.

If you do not mind making two connections, you could do this:

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

The first ssh command will cause /etc/issue to be printed twice (once by the system, once by cat), so the number of lines will be twice that of /etc/issue. The second command's output will only show the output from that number of lines plus one.


If your log will have a bunch of sessions appended in one file, you could have your script do something like echo START LOGGING before running any other commands, and then echo END LOGGING before disconnecting, and then use a simple shell script (using sed or awk) strip out all contents of the file between END and START (ie. the boilerplate before each login).


Now I see that you are not logging, but instead looking for messages in the window - I recommend creating logs and scanning the logs instead of relying on terminal window output alone - this is much more flexible, and allows referring back to errors from previous sessions if needed.



When the host sends back lines of text, how can the SSH client know which lines came from the host's /etc/issue, and which ones are more interesting messages? It can't.

  • it can know because /etc/issue is printed before you run any commands, it won't show up in the middle of a session, ever – Justin Smith Feb 21 '10 at 15:13

You can set this from the commandline with:

ssh -o loglevel=ERROR

If you are using rsync (as was the case for me when Googling this problem), you can do it by specifying the ssh connection commandline to rsync as:

rsync -e 'ssh -o loglevel=ERROR'

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.