[BR]: tag <matches>'s value not well formatted (systemd journal only)

[wdzeng]

Environment:

• Fail2Ban version : 0.11.2
• OS, including release name/version : Fedora release 35 (Thirty Five)
• Fail2Ban installed via OS/distribution mechanisms : Yes, installed with dnf
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)

The issue:

The value of <matches> tag is not well formatted for sshd service. The value looks like:

2022-06-02T19:58:46.695370example.com sshd[1571006]: Failed password for ......

There should be a space between timestamp and hostname, e.g.:

2022-06-02T19:58:46.695370 example.com sshd[1571006]: Failed password for ......

Steps to reproduce

0. Install fail2ban.

1. Create following three files.

   # fail2ban.local
   [DEFAULT]
   loglevel = DEBUG
   

   # jail.local
   [sshd]
   enabled = true
   action = test
   

   # actions.d/test.conf
   [Definition]
   actionstart =
   actionstop =
   actioncheck =
   actionban = echo "<matches>" >&2
   actionunban =
   

2. Start fail2ban.

3. Wait until an IP is banned for sshd service.

4. View fail2ban.log and we could find that the logs contain message with improper format.

   2022-06-02 19:58:47,115 fail2ban.utils          [1570801]: DEBUG   7faaf3ed7cc0 -- stderr: '2022-06-02T19:58:44.523180example.com sshd[1571006]: ......
   

Expected behavior

There should be a space between timestamp and hostname.

Observed behavior

A space is missing between timestamp and hostname.

Any additional information

I have examined that if we modify the getMatches function in ticket.py at line 155:

def getMatches(self):
    return [(line if not isinstance(line, (list, tuple)) else " ".join(line).strip()) \
        for line in self._data.get('matches', ())]

then this issue can be fixed, but I am not sure if this edit may cause new problem.

[sebres]

Looks like this missing space affects systemd backend only (jails monitoring systemd journal).
I'll fix that soon, thanks for info.
FWIW, there is another similar issue with <matches> tag - #3275 (comment)