Description of problem: rkhunter is misreporting the SSH protocol choice ======================= Version-Release number of selected component (if applicable): ============================================================= 1.4.6 How reproducible: ================= Happens in every daily rkhunter run since upgrade to F28 Steps to Reproduce: =================== 1. Make sure that the 'Protocol' line in /etc/ssh/ssh_config that sets the protocol version is NOT commented out and sets it to 2 2. Allow the daily rkhunter cron job to run 3. Look at the report it sends to root Actual results: =============== If the Protocol is set to 2 and the line is NOT commented out, rkhunter reports: Warning: The SSH configuration option 'Protocol' has not been set. The default value may be '2,1', to allow the use of protocol version 1. If the Protocol is set to 2 and the line IS commented out, rkhunter does not report any warnings. Expected results: ================= If the Protocol is explicitly set to a legal value, 2, rkhunter should not be reporting this as a warning. Additional information: ======================= This warning started to appear after an in-situ upgrade of a Dual Athlon-based server from Fedora 27 to 28. The /etc/ssh/ssh_config file was not changed during or after the upgrade. This file explicitly sets Protocol to 2. Another machine (i5 based Lenovo T440) was also upgraded in exactly the same way a week earlier and is not showing these warnings. The only difference is that the Protocol line in /etc/ssh/ssh_config is commented out. Both rkhunter instances report themselves as being version 1.4.6
Could you provide: sudo grep ^ALLOW_SSH_PROT /etc/rkhunter.conf and sudo grep Protocol /etc/ssh/sshd_config from both machines (the one that shows the warning and the one that doesnt?)
The machine with no warning: $ sudo grep ^ALLOW_SSH_PROT /etc/rkhunter.conf ALLOW_SSH_PROT_V1=2 $ sudo grep Protocol /etc/ssh/sshd_config $ The machine with the warning: $ sudo grep ^ALLOW_SSH_PROT /etc/rkhunter.conf ALLOW_SSH_PROT_V1=2 $ sudo grep Protocol /etc/ssh/sshd_config $ As you can see, the results are the same. I've just rebooted the machine that reported the error, because I thought it was doing somewhat odd things, and re-run your greps - same result. Sorry that this is probably not a helpful result. I don't know what's going on: only that I've seen the Protocol not set warning on both nights since I did the F27->F28 upgrade on the Dual Athlon box machine and have never seen it on the i5-based laptop, which got the same upgrade two weeks earlier.
Just to confirm: exactly the same happened last night: a silent rkhunter run on the Lonovo T440 (i5) and a warning about a missing Protocol setting on the AMD desktop.
Do either of the machines have: /etc/rkhunter.conf.local or /etc/rkhunter.d/*.conf files?
Yes, both have them. Most lines in each would seem to be irrelevant. They all start with MAILONWARNING, ALLOWDEVFILE, ALLOWHIDDENDIR, ALLOWHIDDENFILE XINETD_ALLOWEDSVC but the file on the host that has been emitting warnings contains the line: ALLOW_SSH_PROT_V1=0 Is this the problem? The only mention of it I can find now is in the 1.4.6 changelog, but this doesn't explain why it should change its behaviour with the F287->F28 upgrade since /etc/ssh/ssh_config was last changed on 22 Dec 2017. Or, indeed why it would affect protocol 2, since it looks to be targetted on protocol 1. I thought there used to be a list of the ALLOW* parameters but I can't find it on the rkhunter website of in /usr/share/doc/rkhunter/*
(In reply to Martin Gregorie from comment #5) > but the file on the host that has been emitting warnings contains the line: > > ALLOW_SSH_PROT_V1=0 > > Is this the problem? > I thought that value was supposed to be set to '2' to suppress a warning message. If I recall correctly, '0' means ssh-1 is not allowed but when protocol is not specified in sshd_config, this will shout a warning. (In reply to Martin Gregorie from comment #2) > The machine with the warning: > > $ sudo grep ^ALLOW_SSH_PROT /etc/rkhunter.conf > ALLOW_SSH_PROT_V1=2 > $ sudo grep Protocol /etc/ssh/sshd_config > $ Based on this there should be no warning, but, presumably this is being overridden by the .local files. Perhpas, you can try changing the value to '2' and checking again?
Yeah, I just found this in the rkhunter conf file # # Set this option to '1' to allow the use of the SSH-1 protocol, but note # that theoretically it is weaker, and therefore less secure, than the # SSH-2 protocol. Do not modify this option unless you have good reasons # to use the SSH-1 protocol (for instance for AFS token passing or Kerberos4 # authentication). If the 'Protocol' option has not been set in the SSH # configuration file, then a value of '2' may be set here in order to # suppress a warning message. A value of '0' indicates that the use of # SSH-1 is not allowed. # # The default value is '0'. #
I've just done two runs: 1) with ALLOW_SSH_PROT_V1=2 in rkhunter.conf.local and 2) with the ALLOW_SSH_PROT_V1=0 line removed from rkhunter.conf.local Both suppress the "Protocol 2" warning, so I'll stick with the second solution. Thanks, guys.
Great. So, ok to close this out? Or is there anything further we can do from here?
I'm happy, thanks, now I know how to suppress that apparently erroneous warning. I think you are best placed to decide if ALLOW_SSH_PROT_V1 needs changes.
I think we are ok. Thanks!
This problem has emerged again: sudo grep ^ALLOW_SSH_PROT /etc/rkhunter.conf sudo grep Protocol /etc/ssh/sshd_config Protocol 2
Sorry I forgot to tell that this began for after the lates update of rkhunter 1.4.6 ---------------------- Start Rootkit Hunter Scan ---------------------- Warning: The file properties have changed: File: /usr/bin/rkhunter Current inode: 161470 Stored inode: 202339 Warning: The SSH configuration option 'Protocol' has not been set. The default value may be '2,1', to allow the use of protocol version 1. ----------------------- End Rootkit Hunter Scan ----------------------- rpm -qi rkhunter Name : rkhunter Version : 1.4.6 Release : 10.fc32 Architecture: noarch Install Date: man 25 jan 2021 06:38:59 CET Group : Unspecified Size : 868641 License : GPLv2+ Signature : RSA/SHA256, lør 16 jan 2021 20:36:29 CET, Key ID 6c13026d12c944d0 Source RPM : rkhunter-1.4.6-10.fc32.src.rpm Build Date : lør 16 jan 2021 20:29:18 CET Build Host : buildvm-ppc64le-20.iad2.fedoraproject.org Packager : Fedora Project Vendor : Fedora Project URL : http://rkhunter.sourceforge.net/ Bug URL : https://bugz.fedoraproject.org/rkhunter Summary : A host-based tool to scan for rootkits, backdoors and local exploits Description : Rootkit Hunter (RKH) is an easy-to-use tool which checks computers running UNIX (clones) for the presence of rootkits and other unwanted tools.
The culprit is this change. 17388a17382,17387 > if [ -d "${SSH_CONFIG_FILE}.d" ];then > SSH_CONFIG_FILE="${SSH_CONFIG_FILE} ${SSH_CONFIG_FILE}.d/*" > else > : > fi I have only this in /etc/ssh/sshd_config.d/ 50-redhat.conf with this content grep -v '^#' /etc/ssh/sshd_config.d/50-redhat.conf Include /etc/crypto-policies/back-ends/opensshserver.config SyslogFacility AUTHPRIV PasswordAuthentication yes ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials no UsePAM yes X11Forwarding yes PrintMotd no AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS
This line RKHTMPVAR=`grep -i '^[ ]*Protocol[ =]' "${SSH_CONFIG_FILE}" 2>/dev/null | tail ${TAIL_OPT}1` should be changed to RKHTMPVAR=`grep -i '^[ ]*Protocol[ =]' ${SSH_CONFIG_FILE} 2>/dev/null | tail ${TAIL_OPT}1` removing the surrounding ""s. With the quotes grep will take this new SSH_CONFIG_FILE as one path instead of several paths.
Good spotting. Can you try this scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=60784163
I can confirm that it works now. Thanks.
I'll update rawhide now, but I think upstream might have some activity soon, so will wait and push more things at once to stable releases...
FEDORA-2021-8d357c8b69 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d357c8b69
FEDORA-2021-c7e106338e has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c7e106338e
FEDORA-2021-c7e106338e has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c7e106338e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c7e106338e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8d357c8b69 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8d357c8b69` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d357c8b69 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8d357c8b69 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-c7e106338e has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-a645b33096 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a645b33096
FEDORA-2021-a645b33096 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a645b33096` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a645b33096 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a645b33096 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.