Bug 13762 - ssh logins not in the system log
Summary: ssh logins not in the system log
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 Linux
: - Unknown - - Unknown -
Assignee: Adolf Belka
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-26 16:08 UTC by Sammy-Bulldog
Modified: 2024-08-28 10:10 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sammy-Bulldog 2024-08-26 16:08:51 UTC
when you start IPFire there are entries in the system log under SSH

13:02:22	sshd[5987]: 	Server listening on 0.0.0.0 port 222.
13:00:10	sshd[5987]: 	Received signal 15; terminating.

If a user login, there are no entries

IPFire 2.29 (x86_64) - Core-Update 187
Comment 1 Adolf Belka 2024-08-26 17:12:01 UTC
I just tried logging in with ssh and I got entries in the messages log both when I accessed via ssh and then when I exited from the ssh terminal

Aug 26 19:04:04 ipfire sshd-session[25681]: Accepted publickey for root from 192.168.222.132 port 34958 ssh2: ED25519 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Aug 26 19:04:08 ipfire sshd-session[25683]: Received disconnect from 192.168.222.132 port 34958:11: disconnected by user
Aug 26 19:04:08 ipfire sshd-session[25683]: Disconnected from user root 192.168.222.132 port 34958

If you run the command

tail -f /var/log/messages | grep sshd

and then access via an ssh terminal do you see any message being created in the log?
Comment 2 Sammy-Bulldog 2024-08-26 20:08:37 UTC
I manage five ipfire firewalls, all have the same error since 09.08.24 after the update
Comment 3 Sammy-Bulldog 2024-08-26 20:11:24 UTC
after entering the command, the login and logout are displayed
the login and logout are not in the system log
Comment 4 Adolf Belka 2024-08-26 21:25:56 UTC
Okay, I now see what you mean.

Looking back through the logs to before 9th August then the name that was searched for in the system logs was sshd[ followed by a process number.

In Core Update 187 ssh was updated and the update included the separation of the ssh daemon into a listener and session daemon to have a smaller attack vector since the listener does not need to implement the SSH protocol.

This has resulted in the program identifier in the logs changing from sshd[ to sshd-session[ which is therefore not found by the code that has a regex looking for sshd[.

As well as fixing the code for the system logs the code for the summary logs will also need to be modified.
Comment 5 Adolf Belka 2024-08-26 21:32:56 UTC
The challenge will be figuring out the regex that will pick up both sshd[xxxx] and sshd-session[xxxx] to be able show the data both prior and post the change to the daemon name.
Comment 6 Adolf Belka 2024-08-27 12:47:46 UTC
Figured out how to adjust the regex for sshd in log.dat. It turned out to be easier than I at first thought to include both the old and the new definitions.

For the summary.dat file this requires an update of the logwatch program and the application of a patch from the logwatch developer that will be included in the following logwatch release. However the patch can be applied to the existing latest release version.
I will build the latest logwatch with the patch applied and test it out on my vm system. This will only work from the point at which it is put into IPFire as the summary data comes from the daily logwatch files and currently they don't include sshd as the daemon is now called sshd-session.
So when I install it in my vm system, I will need to run it for a couple of days so that data is collected.
Comment 7 Sammy-Bulldog 2024-08-27 13:09:21 UTC
👍
Comment 8 Adolf Belka 2024-08-28 10:10:59 UTC
Patch set has been created and installed on my vm testbed. Confirmed that both the ssh System Log and the Summary Log both work again.

Patch set submitted

https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/J4N74UYJSCVIOSRBTMZPC3LRL4EK5RDR/

https://patchwork.ipfire.org/project/ipfire/list/?series=4474

It should end up being in CU189.