include-config-dir from sshd not recognized

Bug #1911014 reported by Stefan Jakl
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
rkhunter (Debian)
Confirmed
Unknown
rkhunter (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

1)
lsb_release -rd
Description: Ubuntu 20.04.1 LTS
Release: 20.04

2)
apt-cache policy rkhunter
rkhunter:
  Installiert: 1.4.6-8
  Installationskandidat: 1.4.6-8
  Versionstabelle:
 *** 1.4.6-8 500
        500 http://ch.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        100 /var/lib/dpkg/status

3)
If I run rkhunter, it checks some of the sshd_config settings. Now there's a option to add our own config for sshd in /etc/sshd_config.d/
If I do so, rkhunter does not recoginze them and they'll be ignored.

If we put in more than 1 (one) configfile in /etc/sshd_config.d/ rkhunter will only take the first location and it expects that the file is called "sshd_config" -> ~ line #17372 /usr/bin/rkhunter :

17373 SSH_CONFIG_FILE=""
17374
17375 if [ -n "${SSH_CONFIG_DIR}" ]; then
17376 RKHTMPVAR="${SSH_CONFIG_DIR}"
17377 else
17378 RKHTMPVAR="/etc /etc/ssh /usr/local/etc /usr/local/etc/ssh"
17379 fi
17380
17381 for DIR in ${RKHTMPVAR}; do
17382 if [ -f "${DIR}/sshd_config" ]; then
17383 SSH_CONFIG_FILE="${DIR}/sshd_config"
17384 break
17385 fi
17386 done

4)
Only the default-location is accepted with the hardcoded sshd_config-filename.

Would it be possible to enhance that script, so that :
- it can handle more than one configfile ?
- it reads the settings that are applied to sshd like "sshd -T"

Thank you.
Kind regards

Changed in rkhunter (Debian):
status: Unknown → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in rkhunter (Ubuntu):
status: New → Confirmed
Revision history for this message
Jeff Abrahamson (jeff-purple) wrote :

Running sshd with the -ddd flags to get a bit more information, I can see that the server is including the requested file. Indeed, server behaviour is almost identical between the two scenarios (included or inline) until it executes the Match statement that is the contents of my included file or else is inlined into sshd_config.

Here is where it diverges:

On both sides, I see this in the lead-up to the divergence:

debug3: Trying to reverse map address 1.2.3.4.
debug2: parse_server_config_depth: config reprocess config len 1208
debug2: parse_server_config_depth: config /etc/ssh/sshd_config.d/sftp_users.conf len 182
debug3: checking match for 'Group sftp_users' user user1 host ...
debug1: user user1 matched group list sftp_users at line 1
debug3: match found

(the line number and length are different in the two cases)
At this point they diverge. In the version that has inlined the file contents, I see

debug3: reprocess config:54 setting ...
debug3: reprocess config:55 setting ...
debug3: reprocess config:56 setting ...
debug3: reprocess config:57 setting ...
debug3: reprocess config:58 setting PasswordAuthentication yes
debug3: reprocess config:59 setting ...

Those config statements correspond to the contents of my Match block. They are only processed in the inline version. Then both versions say

debug3: auth2_setup_methods_lists: checking methods

and then again, they differ:

(include) debug1: authentication methods list 0: publickey
(inline) debug1: authentication methods list 0: password

And this is the point: the Match (which was found) is supposed to say that for this class of user connecting, we should accept passwords rather than public keys and only permit sftp.

So the result is that both versions recognise the Match condition, but only the inlined version actually executes the Match block.

Revision history for this message
Mitsuya Shibata (cosmos-door) wrote :

It seems that this bug has fixed in upstream.

https://sourceforge.net/p/rkhunter/rkh_code/ci/f6816fbf06711191698f4eb4091a1fcd5e0836cc/

However there is no new release yet.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.