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.
Best Answer
Yes, there is a kernel facility: the audit subsystem. The
auditd
daemon does the logging, and the commandauditctl
sets up the logging rules. You can log all calls to a specific system alls, with some filtering. If you want to log all commands executed and their arguments, log theexecve
system call:To specifically trace the invocation of a specific program, add a filter on the program executable:
The logs show up in
/var/log/audit.log
, or wherever your distribution puts them. You need to be root to control the audit subsystem.Once you're done investigating, use the same command line with
-d
instead of-a
to delete a logging rule, or runauditctl -D
to delete all audit rules.For debugging purposes, replacing the program by a wrapper script gives you more flexibility to log things like the environment, information about the parent process, etc.