Re: deprecated options in openssh
On Fri 10 Sep 2021 at 13:17:39 (-0400), Greg Wooledge wrote:
> On Fri, Sep 10, 2021 at 11:51:07AM -0500, David Wright wrote:
> > On Fri 10 Sep 2021 at 16:05:26 (+0100), Adam Weremczuk wrote:
> >
> > > Would it be possible for another host to log to syslog without a prior
> > > explicit manual configuration allowing that?
> >
> > If you make a telephone call on speaker, and you have a tape recorder
> > in the room recording the conversation, the speaker at the other end
> > of the call doesn't need to have permission for their words to be
> > recorded on /your/ tape.
> >
> > When you commence your call, both you and the person at the other end
> > probably exchange some pleasantries, which confirm that you're both
> > who you say you are. These all get recorded too.
> >
> > Ssh is no different.
>
> This analogy confuses me. The question is whether syslogd (the listening
> process) accepts remote syslog() requests by default. I'm pretty sure
> that some of the syslogd implementations don't. Maybe some do.
That's not a question /I/ was considering, because the OP had
mentioned having a "dozen of Debian (mostly older) machines",
which I assume the OP communicates with by means of ssh.¹
I'm assuming that one of those machines might still have a old
configuration file in place, probably originating from at least
jessie, on account of KeyRegenerationInterval and ServerKeyBits.
The OP admits to editing the ssh{d,} configuration files, and that
could lead to any Debian upgrade leaving them in place, unaltered,
depending on the replies to (or defaults for) APT's questions.
My aim in bringing up the analogy was to point out that, AIUI, ssh
clients and servers communicate information about each other's
configuration in order to determine how they're going to set up
the substantive session.
That preliminary communication corresponds to the exchanged
pleasantries on a phone call, and my point is that they occur through
the same port/channel as the eventual ssh session, not by some
separate process. So information about the remote client is available
for logging by the OP's local ssh server.²
What I've been expecting is that the OP would examine the local logs
in more detail to ascertain the precise time at which sshd bleated.
This could involve increasing the detail logged by logwatch and/or
increasing the verbosity of sshd. They would then examine the logs
on all the remote machines at corresponding times. That alone might
single out an offending machine.
> It's not clear which syslogd the OP is using. It's not even clear to me
> what *operating system* they're using, since their systemctl status output
> has at least one line that mine (bullseye) does not have.
>
> Also... it's not really important what the defaults are. What's important
> is how syslogd is actually configured on the OP's system.
As I understood the OP's first reply (to yourself), there are
remote logs available, not logged locally but sent by email:
"/usr/sbin/logwatch --detail low --mailto xxx@domain.com"
Again, more detail may be required. If it's possible, one might run
a second instance of logwatch, with detail=high but only covering ssh.
¹ I'm ignoring any external connection attempts for the time being.
² Speakerphone ssh
dialling TCP/IP connection
key exchange & encryption &
pleasantries authentication
& command execution
conversation user data exchange
------------ -------------
can be recorded can be logged
at one end at one end
Cheers,
David.
Reply to: