Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
    
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

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.

share|improve this answer

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.

share|improve this answer

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

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)?
share|improve this answer

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.

share|improve this answer
    
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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