7

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.

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

5 Answers 5

9

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:

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.


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 (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: 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.

2
  • 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 Commented Jul 17, 2019 at 20:11
  • Thank you @ChrisAdams for your feedback. 👍 Have fun 😎
    – oHo
    Commented Aug 27, 2019 at 23:32
3

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.

3

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

EDIT:

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.

2

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'

2
  • 1
    Thank goodness I don't need to file a ticket with my sysadmin guys to change /etc/issue which would have taken weeks. Commented Feb 3, 2022 at 7:53
  • 1
    Yay! Glad to help. Commented Feb 4, 2022 at 18:24
-1

No.

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.

1
  • 1
    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 Commented Feb 21, 2010 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .