Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #238825 > unrolled thread

deprecated options in openssh

Back to article view | Back to linux.debian.user

Contents

  deprecated options in openssh Adam Weremczuk <adamw@matrixscience.com> - 2021-08-16 16:40 +0200
    Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-08-16 16:40 +0200
      Re: deprecated options in openssh Adam Weremczuk <adamw@matrixscience.com> - 2021-08-16 18:10 +0200
        Re: deprecated options in openssh David Wright <deblis@lionunicorn.co.uk> - 2021-08-16 19:30 +0200
          Re: deprecated options in openssh Adam Weremczuk <adamw@matrixscience.com> - 2021-09-10 12:00 +0200
            Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-09-10 14:20 +0200
              Re: deprecated options in openssh David Wright <deblis@lionunicorn.co.uk> - 2021-09-10 16:20 +0200
              Re: deprecated options in openssh Adam Weremczuk <adamw@matrixscience.com> - 2021-09-10 17:30 +0200
                Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-09-10 18:50 +0200
                  Re: deprecated options in openssh Adam Weremczuk <adamw@matrixscience.com> - 2021-09-10 19:30 +0200
                    Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-09-10 19:40 +0200
                Re: deprecated options in openssh David Wright <deblis@lionunicorn.co.uk> - 2021-09-10 19:00 +0200
                  Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-09-10 19:20 +0200
                    Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-09-10 19:30 +0200
                    Re: deprecated options in openssh David Wright <deblis@lionunicorn.co.uk> - 2021-09-11 21:50 +0200
                      Re: deprecated options in openssh Greg Wooledge <greg@wooledge.org> - 2021-09-11 22:10 +0200
                        Re: deprecated options in openssh David Wright <deblis@lionunicorn.co.uk> - 2021-09-13 19:30 +0200
                  Re: deprecated options in openssh Adam Weremczuk <adamw@matrixscience.com> - 2021-09-10 19:30 +0200
                  Re: deprecated options in openssh Dan Ritter <dsr@randomstring.org> - 2021-09-10 21:00 +0200
                    Re: deprecated options in openssh rhkramer@gmail.com - 2021-09-11 00:00 +0200
                      Re: deprecated options in openssh David Wright <deblis@lionunicorn.co.uk> - 2021-09-11 21:50 +0200
        Re: deprecated options in openssh Anssi Saari <as@sci.fi> - 2021-08-17 10:50 +0200

Page 1 of 2  [1] 2  Next page →

#238825 — deprecated options in openssh

Hi all,

I run openssh 7.9p1-10+deb10u2 on Debian 10.10.

Logwatch, which runs daily, occasionally (maybe 2-3 times per month) 
reports the following:

--------------------- SSHD Begin ------------------------

  Deprecated options in SSH config:
     KeyRegenerationInterval - line 28
     RSAAuthentication - line 49
     RhostsRSAAuthentication - line 57
     ServerKeyBits - line 29
     UsePrivilegeSeparation - line 25

I've checked /etc/ssh/sshd_config and the options are there but:

- they are all commented out with ## (why should I be forced to delete 
commented out lines?)
- none of these options is mentioned in any other file under /etc
- the line numbers are shifted by 2 (e.g. line 25 is in fact line 27) 
because of 2 custom lines that I added at the very beginning of the file

I've definitely restarted ssh service since making the changes.

Why is logwatch still complaining and why is it getting the line numbers 
wrong?

Regards,
Adam

[toc] | [next] | [standalone]

#238826

On Mon, Aug 16, 2021 at 03:06:30PM +0100, Adam Weremczuk wrote:
> I run openssh 7.9p1-10+deb10u2 on Debian 10.10.
> 
> Logwatch, which runs daily, occasionally (maybe 2-3 times per month) reports
> the following:

Sometimes you get warnings, and sometimes you don't?  That's a red flag
right off the bat.

Is this "logwatch" thing run by a crontab entry, or by a systemd timer?

Are the ones that give warnings run by a *different* crontab entry, or
a *different* systemd timer?

> Why is logwatch still complaining and why is it getting the line numbers
> wrong?

My first guess is that there's another sshd_config file somewhere else
that it's reading, on the occasions where you get the warnings, possibly
due to a second crontab entry or whatever.

Or maybe logwatch has a configuration file that defines different tasks
depending on the day, and one of the tasks is set to read the wrong file?

[toc] | [prev] | [next] | [standalone]

#238830

Installation and configuration was straightforward:

sudo apt install logwatch

/etc/cron.daily/00logwatch
#execute
/usr/sbin/logwatch --detail low --mailto xxx@domain.com

The master config file /usr/share/logwatch/default.conf/logwatch.conf 
left with defaults.

Only one report per day arrives. Same as for the other dozen of Debian 
(mostly older) machines it's installed on and which don't show this issue.

I've run a recursive search across the entire file system but no other 
occurrences of the problematic options have been found:

sudo find / -type f -exec grep -l UsePrivilegeSeparation {} \;

Still puzzled...

On 16/08/2021 15:34, Greg Wooledge wrote:
> On Mon, Aug 16, 2021 at 03:06:30PM +0100, Adam Weremczuk wrote:
>> I run openssh 7.9p1-10+deb10u2 on Debian 10.10.
>>
>> Logwatch, which runs daily, occasionally (maybe 2-3 times per month) reports
>> the following:
> Sometimes you get warnings, and sometimes you don't?  That's a red flag
> right off the bat.
>
> Is this "logwatch" thing run by a crontab entry, or by a systemd timer?
>
> Are the ones that give warnings run by a *different* crontab entry, or
> a *different* systemd timer?
>
>> Why is logwatch still complaining and why is it getting the line numbers
>> wrong?
> My first guess is that there's another sshd_config file somewhere else
> that it's reading, on the occasions where you get the warnings, possibly
> due to a second crontab entry or whatever.
>
> Or maybe logwatch has a configuration file that defines different tasks
> depending on the day, and one of the tasks is set to read the wrong file?
>

[toc] | [prev] | [next] | [standalone]

#238833

On Mon 16 Aug 2021 at 16:49:16 (+0100), Adam Weremczuk wrote:
> Installation and configuration was straightforward:
> 
> sudo apt install logwatch
> 
> /etc/cron.daily/00logwatch
> #execute
> /usr/sbin/logwatch --detail low --mailto xxx@domain.com
> 
> The master config file /usr/share/logwatch/default.conf/logwatch.conf
> left with defaults.
> 
> Only one report per day arrives. Same as for the other dozen of Debian
> (mostly older) machines it's installed on and which don't show this
> issue.

I presume logwatch is watching your logs, so the first place to check
is the actual logs themselves.

My guess (it's no more than that) is that one of the other dozen
machines that you occasionally log into has a slightly different
configuration from this one, perhaps older, with options that are
now considered less secure (but no extra lines inserted).

The options that are commented out in each machine's config file are
the defaults being used by the server, so they /are/ in force.
When you connect to a remote machine's server, I'm assuming it gets
told what the remote's options are, and it's remonstrating about them.
(The fact that options are commented will be irrelevant, therefore.)

Note that I may have all this in reverse: the remote machine could be
complaining about yours, and sending you the log by email. So, as I say,
the first step is to find the log entries that logwatch has watched for.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239825

Hi all,

Weeks later it happened again and I'm not any less puzzled:

/var/log/syslog

Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 25: 
Deprecated option UsePrivilegeSeparation
Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 28: 
Deprecated option KeyRegenerationInterval
Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 29: 
Deprecated option ServerKeyBits
Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 49: 
Deprecated option RSAAuthentication
Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 57: 
Deprecated option RhostsRSAAuthentication
Aug 28 10:12:31 deb10 sshd[207]: /etc/ssh/sshd_config line 25: 
Deprecated option UsePrivilegeSeparation
Aug 28 10:12:31 deb10 sshd[207]: /etc/ssh/sshd_config line 28: 
Deprecated option KeyRegenerationInterval
Aug 28 10:12:31 deb10 sshd[207]: /etc/ssh/sshd_config line 29: 
Deprecated option ServerKeyBits
Aug 28 10:12:31 deb10 sshd[207]: /etc/ssh/sshd_config line 49: 
Deprecated option RSAAuthentication
Aug 28 10:12:31 deb10 sshd[207]: /etc/ssh/sshd_config line 57: 
Deprecated option RhostsRSAAuthentication

Not matching what's in the file:

awk 'NR==25' /etc/ssh/sshd_config

awk 'NR==28' /etc/ssh/sshd_config

awk 'NR==29' /etc/ssh/sshd_config
# Lifetime and size of ephemeral version 1 server key

etc.

The service hasn't been restarted around that time and the file hasn't 
been modified for even longer:

systemctl status ssh.service | grep running
    Active: active (running) since Wed 2021-08-18 17:36:45 UTC; 3 weeks 
1 days ago

stat /etc/ssh/sshd_config
   File: /etc/ssh/sshd_config
   Size: 3864            Blocks: 9          IO Block: 4096 regular file
Device: 34h/52d Inode: 94834       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2021-09-10 06:48:08.449310637 +0000
Modify: 2021-07-06 07:15:34.222154544 +0000
Change: 2021-07-06 07:15:34.222154544 +0000
  Birth: -

This is a Proxmox LXC container and I thought that maybe the syslog 
entries were for some reason referring to the master host, but not!

awk 'NR==25' /etc/ssh/sshd_config
# Logging
awk 'NR==28' /etc/ssh/sshd_config

awk 'NR==29' /etc/ssh/sshd_config
# Authentication:

What's going on here? :)

Regards,
Adam

On 16/08/2021 18:27, David Wright wrote:
> On Mon 16 Aug 2021 at 16:49:16 (+0100), Adam Weremczuk wrote:
>> Installation and configuration was straightforward:
>>
>> sudo apt install logwatch
>>
>> /etc/cron.daily/00logwatch
>> #execute
>> /usr/sbin/logwatch --detail low --mailto xxx@domain.com
>>
>> The master config file /usr/share/logwatch/default.conf/logwatch.conf
>> left with defaults.
>>
>> Only one report per day arrives. Same as for the other dozen of Debian
>> (mostly older) machines it's installed on and which don't show this
>> issue.
> I presume logwatch is watching your logs, so the first place to check
> is the actual logs themselves.
>
> My guess (it's no more than that) is that one of the other dozen
> machines that you occasionally log into has a slightly different
> configuration from this one, perhaps older, with options that are
> now considered less secure (but no extra lines inserted).
>
> The options that are commented out in each machine's config file are
> the defaults being used by the server, so they /are/ in force.
> When you connect to a remote machine's server, I'm assuming it gets
> told what the remote's options are, and it's remonstrating about them.
> (The fact that options are commented will be irrelevant, therefore.)
>
> Note that I may have all this in reverse: the remote machine could be
> complaining about yours, and sending you the log by email. So, as I say,
> the first step is to find the log entries that logwatch has watched for.
>
> Cheers,
> David.
>

[toc] | [prev] | [next] | [standalone]

#239831

On Fri, Sep 10, 2021 at 10:33:47AM +0100, Adam Weremczuk wrote:
> Weeks later it happened again and I'm not any less puzzled:

What's "it"?

> /var/log/syslog
> 
> Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 25: Deprecated
> option UsePrivilegeSeparation

Fine, just comment out the offending lines....

> Not matching what's in the file:
> 
> awk 'NR==25' /etc/ssh/sshd_config
> 
> awk 'NR==28' /etc/ssh/sshd_config
> 
> awk 'NR==29' /etc/ssh/sshd_config
> # Lifetime and size of ephemeral version 1 server key

OK, so "it" is in fact "The warnings in syslog contain line numbers which
do not align with the line numbers of the file that I see"?

Seems harmless enough -- just comment out the offending options wherever
they are, ignoring the line numbers in the warnings.

> The service hasn't been restarted around that time and the file hasn't been
> modified for even longer:
> 
> systemctl status ssh.service | grep running
>    Active: active (running) since Wed 2021-08-18 17:36:45 UTC; 3 weeks 1
> days ago

All right, now we're getting somewhere.

Is it possible that these lines are being remotely syslogged to you from
another host?

It's unfortunate that you omitted most of the systemctl output.  It would
have been nice to see whether PID 145 is actually sshd on this host.  You
could also check by hand, of course:  ps -fp 145   and   ps -ef | grep sshd

You might also want to double-check "journalctl -u ssh" against the
contents of the syslog file.  As far as I know, the systemd journal
cannot accept input from a foreign host, so it should always show
info that comes from services running on localhost.

[toc] | [prev] | [next] | [standalone]

#239839

On Fri 10 Sep 2021 at 08:11:02 (-0400), Greg Wooledge wrote:
> On Fri, Sep 10, 2021 at 10:33:47AM +0100, Adam Weremczuk wrote:

> > Weeks later it happened again and I'm not any less puzzled:
> 
> All right, now we're getting somewhere.
> 
> Is it possible that these lines are being remotely syslogged to you from
> another host?

… as I suggested Aug 16¹, and I haven't changed my view. In fact, the
OP stated that they were running openssh 7.9p1-10+deb10u2 on Debian 10.10,
but the objectionable configuration options as defaults were last seen
in stretch, and even jessie (KeyRegenerationInterval and ServerKeyBits).

Presumably, this other host is contacted "maybe 2-3 times per month",
hence the frequency of being logged by logwatch.

¹
https://lists.debian.org/debian-user/2021/08/msg00882.html

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239842

On 10/09/2021 13:11, Greg Wooledge wrote:

>> Not matching what's in the file:
>>
>> awk 'NR==25' /etc/ssh/sshd_config
>>
>> awk 'NR==28' /etc/ssh/sshd_config
>>
>> awk 'NR==29' /etc/ssh/sshd_config
>> # Lifetime and size of ephemeral version 1 server key
> OK, so "it" is in fact "The warnings in syslog contain line numbers which
> do not align with the line numbers of the file that I see"?
>
> Seems harmless enough -- just comment out the offending options wherever
> they are, ignoring the line numbers in the warnings.
All these lines have been commented out but, as David Wright pointed 
out, commenting out isn't enough to stop them being the defaults.
Ssh doesn't seem to be reading the local /etc/ssh/sshd_config as the 
line numbers mismatch.
>> The service hasn't been restarted around that time and the file hasn't been
>> modified for even longer:
>>
>> systemctl status ssh.service | grep running
>>     Active: active (running) since Wed 2021-08-18 17:36:45 UTC; 3 weeks 1
>> days ago
> All right, now we're getting somewhere.
>
> Is it possible that these lines are being remotely syslogged to you from
> another host?
>
> It's unfortunate that you omitted most of the systemctl output.  It would
> have been nice to see whether PID 145 is actually sshd on this host.  You
> could also check by hand, of course:  ps -fp 145   and   ps -ef | grep sshd

PID 145 doesn't match anything that I could identify.

This container:
openssh-server 7.9p1-10+deb10u2

systemctl status ssh.service
* ssh.service - OpenBSD Secure Shell server
    Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor 
preset: enabled)
    Active: active (running) since Wed 2021-08-18 17:36:45 UTC; 3 weeks 
1 days ago
      Docs: man:sshd(8)
            man:sshd_config(5)
   Process: 137 ExecStartPre=/usr/sbin/sshd -t (code=exited, 
status=0/SUCCESS)
  Main PID: 165 (sshd)
     Tasks: 1 (limit: 4915)
    Memory: 11.1M
    CGroup: /system.slice/ssh.service
            `-165 /usr/sbin/sshd -D

LXC parent:
openssh-server 7.9p1-10+deb10u2

systemctl status sshd.service

● ssh.service - OpenBSD Secure Shell server
    Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor 
preset: enabled)
    Active: active (running) since Wed 2021-08-18 18:31:24 BST; 3 weeks 
1 days ago
      Docs: man:sshd(8)
            man:sshd_config(5)
   Process: 1659 ExecStartPre=/usr/sbin/sshd -t (code=exited, 
status=0/SUCCESS)
  Main PID: 1910 (sshd)
     Tasks: 1 (limit: 4915)
    Memory: 34.3M
    CGroup: /system.slice/ssh.service
            └─1910 /usr/sbin/sshd -D
>
> You might also want to double-check "journalctl -u ssh" against the
> contents of the syslog file.  As far as I know, the systemd journal
> cannot accept input from a foreign host, so it should always show
> info that comes from services running on localhost.
None of the deprecated options can be found in journalctl:

journalctl -u ssh | grep UsePrivilegeSeparation
journalctl -u ssh | grep KeyRegenerationInterval
etc.

There is actually a gap when the warnings are logged:

Aug 28 10:10:22 deb10 sshd[16443]: Did not receive identification string 
from...
Aug 28 10:14:05 deb10 sshd[16444]: Connection from...

The mysterious warnings arrive in 2 waves at:

Aug 28 10:12:30
Aug 28 10:12:31

Would it be possible for another host to log to syslog without a prior 
explicit manual configuration allowing that?

[toc] | [prev] | [next] | [standalone]

#239843

On Fri, Sep 10, 2021 at 04:05:26PM +0100, Adam Weremczuk wrote:
> Would it be possible for another host to log to syslog without a prior
> explicit manual configuration allowing that?

Depends on which syslog daemon implementation you're using, I think.

[toc] | [prev] | [next] | [standalone]

#239848

On 10/09/2021 17:46, Greg Wooledge wrote:

> Depends on which syslog daemon implementation you're using, I think.

My environment: Linux deb10 5.4.44-1-pve #1 SMP PVE 5.4.44-1 (Fri, 12 
Jun 2020 08:18:46 +0200) x86_64 GNU/Linux

Pretty minimalistic set up.

Rsyslog 8.1901.0-1 out of the box, no customisation at all.

Not sure what else to say.

[toc] | [prev] | [next] | [standalone]

#239849

On Fri, Sep 10, 2021 at 06:10:59PM +0100, Adam Weremczuk wrote:
> On 10/09/2021 17:46, Greg Wooledge wrote:
> 
> > Depends on which syslog daemon implementation you're using, I think.
> 
> My environment: Linux deb10 5.4.44-1-pve #1 SMP PVE 5.4.44-1 (Fri, 12 Jun
> 2020 08:18:46 +0200) x86_64 GNU/Linux
> 
> Pretty minimalistic set up.
> 
> Rsyslog 8.1901.0-1 out of the box, no customisation at all.

It's not a buster kernel, but that's OK.

That is buster's version of rsyslog, so that checks out.

The top page of /etc/rsyslog.conf has (by default) commented-out lines
like:

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

If these are still commented out on your system, then this mystery just
got a lot more mysterious.

Um...

Is your /var/log directory being shared with any other hosts, in any
way?  NFS, Samba, sshfs, who knows what else.  I'm wondering *WHICH HOST*
is writing these syslog entries to your file.

Hmm...

A piece of your original email says:

Aug 28 10:12:30 deb10 sshd[145]: /etc/ssh/sshd_config line 25: Deprecated option UsePrivilegeSeparation

So, it *claims* that it's being written by the host "deb10".  (You're
not reusing this hostname on any other instances, are you?)

I wonder if it's tcpdump time yet.  Try to capture the syslog traffic
from the network, and see where it's coming from?

[toc] | [prev] | [next] | [standalone]

#239844

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239845

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.

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.

[toc] | [prev] | [next] | [standalone]

#239846

On Fri, Sep 10, 2021 at 01:17:39PM -0400, Greg Wooledge wrote:
> 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.

I just checked on a buster system, and buster's output *does* have the
"Process:" line.  Looks like that was removed between buster and bullseye.

[toc] | [prev] | [next] | [standalone]

#239884

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.

[toc] | [prev] | [next] | [standalone]

#239885

On Sat, Sep 11, 2021 at 02:44:13PM -0500, David Wright wrote:
> 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"

I don't know anything about logwatch.  But if your premise is correct,
and logs are being collected onto a central machine and then processed
and ending up in the central machine's /var/log/syslog file, that
would be equivalent to having syslog() and syslogd set up for remote
logging -- just with extra steps and delays.

This would certainly explain how sshd startup complaints from machine X
are ending up in the /var/log/syslog file on machine Y.

You'd think the OP would know about this, if they did in fact set up
such a thing.

[toc] | [prev] | [next] | [standalone]

#239952

On Sat 11 Sep 2021 at 16:02:30 (-0400), Greg Wooledge wrote:
> On Sat, Sep 11, 2021 at 02:44:13PM -0500, David Wright wrote:
> > 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"
> 
> I don't know anything about logwatch.  But if your premise is correct,
> and logs are being collected onto a central machine and then processed
> and ending up in the central machine's /var/log/syslog file, that
> would be equivalent to having syslog() and syslogd set up for remote
> logging -- just with extra steps and delays.

Yes, I don't know whether that's possible or not.

> This would certainly explain how sshd startup complaints from machine X
> are ending up in the /var/log/syslog file on machine Y.
> 
> You'd think the OP would know about this, if they did in fact set up
> such a thing.

If that's what's happening, I'd agree. But after a gap of a month,
a /var/log/syslog extract from who knows where, and the introduction
of containers into the mix, I haven't really bothered to follow how
their machine(s) is/are configured. The info is too piecemeal.
Are X and Y parts of the same machine?

I was under the impression that some information about a client's
configuration might be read by the server (a lot with DEBUG3), and
logged. It is, but those configuration options are not amongst it.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239847

On 10/09/2021 17:51, David Wright wrote:

> 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.
Are you saying these entries could belong to an ssh client trying to 
connect as part of ssh handshake?

My messages are stamped 10:12:30 and 10:12:31. I run ntp across all 
hosts on the LAN. In auth.log there are no connection attempts logged 
between 10:10:07 and 10:14:05.

Could syslog also take time stamps from a client?

[toc] | [prev] | [next] | [standalone]

#239851

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.

Please don't consider that analogy true in the real world.

Various jurisdictions will demand:

one-party consent: Anyone clearly on the call can consent to
record all of it

two-party consent: Everyone on the call must consent or else
recordings are not legal

zero-party consent: The NSA, FBI, or vague equivalent will
record your call without your knowledge

Other laws might apply, such as the requirement to take calls
without recording when a party objects, or the requirement to
delete or redact calls after the fact.

-dsr-

[toc] | [prev] | [next] | [standalone]

#239857

On Friday, September 10, 2021 02:52:42 PM Dan Ritter wrote:
> David Wright wrote:
> > 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.
> 
> Please don't consider that analogy true in the real world.
> 
> Various jurisdictions will demand:
> 
> one-party consent: Anyone clearly on the call can consent to
> record all of it
> 
> two-party consent: Everyone on the call must consent or else
> recordings are not legal
> 
> zero-party consent: The NSA, FBI, or vague equivalent will
> record your call without your knowledge
> 
> Other laws might apply, such as the requirement to take calls
> without recording when a party objects, or the requirement to
> delete or redact calls after the fact.

+1

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web