Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

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

The monitoring tool of my hoster is making regular connections with ssh on port 22 to see or the service is up.

This is cluttering my /var/log/messages with this kind of messages:

Dec 13 22:20:17  sshd[29487]: Did not receive identification string from 80.xx.xx.xx

Is there an easy way of muting this message "Did not receive identification string from" for that specific ip?

share|improve this question
up vote 1 down vote accepted

I think there's no way to do this easily with sshd.

I suspect that this is a design choice on the part of the authors (the OpenBSD folks, usually) because they almost always "err" on the side of security -- in this case, by not providing a knob for us that could suppress important messages.

You did said "easily", so this may be all the answer you need.

But if you might be considering less-easy options, my advice is: don't do it, and here's why.

If you're like me, your underlying motivation for this question is to make actionable items stand out in your logs, and to reduce noise. You're not alone. :-)

In practice, so many types of messages are:

  • well-known,
  • difficult to turn off, and
  • never actionable

... that what you really want is to filter it. Do that instead.

For example, I wrote a script that filters out "uninteresting" items in my previous day's logs, and sends me a daily report. You have to be very careful with your filters, but if done right, it's a real time saver -- and it will make the stuff that really needs your attention stand out.

I do occasionally review my raw logs, of course, and have other methods for catching really urgent stuff. But there aren't enough hours in the day to pore over your logs manually every day, especially when you have multiple boxes to herd, but you're not a big enough shop to warrant large-scale log processing.

All that being said, just in case you have a really compelling reason to do this (and MaxMackie's solution doesn't match your use case, such that you really need to make these messages vanish before they get to syslog), I think you have two options:

.1. Modify the source.

But don't do this, either. Too much overhead and risk -- too much delay between the announcement of a vulnerability and your ability to upgrade.

.2. Make sshd sent its output somewhere else, and send it to syslog yourself.

FreeBSD allows you to specify what parameters should be passed to sshd on startup in /etc/rc.conf or /etc/rc.conf.local, using the sshd_flags value. Tell sshd to run with the -d option (debug) and the -e option (log to standard error):

sshd_flags="-d -e"

You can then pipe the output to logger or Perl's Sys::Syslog (with a wrapper to clean up any oddities). This is non-trivial, as telling a daemon to be un-daemonlike means that you have to recreate a lot of that functionality yourself. I can provide more detail if needed.

But your best bet is to filter.

share|improve this answer
Definitely do not modify the source, as it is probably against the provider's terms and can result in some very bad things (maybe the provider has applications which depend on the feature you're trying to modify). Also, assuming he is in a typical hosting environment, he probably doesn't have much control over the services run (my hosting providers do not give me sufficient privileges to modify system configuration files or services). – n0pe Dec 14 '11 at 6:37
Fair points, all! – Royce Williams Dec 14 '11 at 6:46
I do like your syslog solution though, and it could probably be used with a little hacking (we still haven't heard back from the op). Cheers for the nice comment :) – n0pe Dec 14 '11 at 6:54
@MaxMackie It is my own VPS, so I can do what I want. The only thing I can't adjust is how the providers monitor server does the monitoring (and like their monitoring service). – Peter Smit Dec 14 '11 at 7:30
Thanks to you both for such a good answers! – Peter Smit Dec 14 '11 at 7:30

Without writing a script to parse through /var/log/messages and remove those lines (which is a possibility, you could even run it through cron), you'll be disabling or redirecting all of ssh's output. This isn't the best idea seeing you might get some relevant logs that you'll want to see.

What I would do is write something like this:

#! /bin/bash
sed "/$search/d" /var/log/messages >/var/log/tmp
mv /var/log/tmp /var/log/messages

Save this somewhere safe and have cron run it every day or so. I don't know the frequency at which your provider runs sshd so you can adjust the run time to suit your needs. For more information on adding a rule to cron (cronjob), see this very good tutorial.

Conversely, if you have access to the script that launches ssh (which I doubt you do) and you're able to edit it (which I doubt you can), you can invoke ssh using ssh -q. The q argument makes ssh run "quietly", which means nothing gets logged. This is risky and should be avoided. If you're able to edit the file, I would check with your hosting provider to make sure it is within your agreement.

Alternatively, you could contact your provider, explain your issue and ask them if there is something they can do (or let you do) to modify the ssh daemon.

TL;DR As far as I know, it isn't possible to stop only one message from ssh. However, you can parse your message file at specific intervals to clean up those lines, or if you can find where your provider launches sshd, you can send it the quiet command.

share|improve this answer

Have you looked at the documentation?

There is a LogLevel QUIET|FATAL|ERROR|INFO which defaults to info.

LogLevel ERROR turned off these spammy login messages.

share|improve this answer

Your Answer


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.