Re: deprecated options in openssh
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 x...@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.
Re: deprecated options in openssh
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 x...@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.
Re: deprecated options in openssh
On Fri 10 Sep 2021 at 17:55:59 (-0400), rhkra...@gmail.com wrote: > 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 There is no analogy above: you snipped the paragraph that contained it: "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." IOW before the substantive conversation takes place, information is exchanged along the same channel, and can be recorded along with it. Similarly, ssh clients and servers exchange information about each other, and information that is about one end can be captured at the other end in the logs, all before the user's own data starts to flow. Legality has nothing to do with it, as telephones, tape recorders and computers aren't human beings. (Debian-user is a technical list.) Cheers, David.
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 x...@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.
² Speakerphonessh
diallingTCP/IP connection
key exchange & encryption &
pleasantriesauthentication
& command execution
conversationuser data exchange
-
can be recorded can be logged
at one end at one end
Cheers,
David.
Re: deprecated options in openssh
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
Re: deprecated options in openssh
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-
Re: deprecated options in openssh
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?
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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?
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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?
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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.
Re: deprecated options in openssh
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 + Modify: 2021-07-06 07:15:34.222154544 + Change: 2021-07-06 07:15:34.222154544 + 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 x...@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.
Re: deprecated options in openssh
Adam Weremczuk writes: > Installation and configuration was straightforward: > > sudo apt install logwatch > > /etc/cron.daily/00logwatch > #execute > /usr/sbin/logwatch --detail low --mailto x...@domain.com Maybe run logwatch manually and with different options? Like with --detail high or something like that to get more information as to what it's actually doing?
Re: deprecated options in openssh
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 x...@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.
Re: deprecated options in openssh
Installation and configuration was straightforward:
sudo apt install logwatch
/etc/cron.daily/00logwatch
#execute
/usr/sbin/logwatch --detail low --mailto x...@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?
Re: deprecated options in openssh
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?
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
