sshguard-users — User questions and answers, bugs, and general support

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

On 2026/09/25 03:59, Kevin Zheng wrote:
> 
> Thanks for the investigation and writeup. It's good to know that there 
> was a reasonable explanation for those seemingly weird things happening. 
> If you found that SSHGuard was behaving in a way you didn't expect, that 
> might be an opportunity to improve the documentation or the program. 
> Always open to suggestions.
Given what I know now, Kevin, I don't think SSHGuard ever stood a chance
of doing what was expected.

It feels as though this is the opposite of having a rug pulled out from 
underneath, in that SSHGuard was standing on a rug, but then someone put
another rug between it and the floor, without it knowing - what fun!

Kevin

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin Z. <kev...@gm...>]

Hi Kevin,

Thanks for the investigation and writeup. It's good to know that there 
was a reasonable explanation for those seemingly weird things happening. 
If you found that SSHGuard was behaving in a way you didn't expect, that 
might be an opportunity to improve the documentation or the program. 
Always open to suggestions.

Regards,
Kevin

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

On 2026/09/21 16:26, Kevin Zheng wrote:
> 
> Could you check that /etc/sshguard.conf is the correct location for your 
> config file, that it is not being overriden somewhere else, and that 
> there is not a subsequent BACKEND= line that sets it back to firewalld?
Turned out that that was the issue, although it's taken a few trips down
a few rabbit holes in order to work out what has been going on.

So we have diskless nodes, onto which the OS images are pre-created and
then pushed out, ahead of the "boot".

However, we have recently changed the way in which the image, that I'll
refer to as the "deployed image", gets deployed, from an effectively
static, some would say overly monolithic, image build on the cluster 
manager, to a less-monolithic, some would say slimmed down, image, 
plus a swathe of ansible plays.

The last rabbit hole I ended up in showed me that, in the slimmed down
image, the /etc/sshguard.conf has

BACKEND="/usr/lib/sshg-fw-firewalld"

(presumably the default in the RPM file used to build that image)
but that the "deployed image", which is all that most people who haven't
yet gone down any rabbit-holes see, has the expected

BACKEND="/usr/lib/sshg-fw-iptables"


I still don't understand, fully, why, at the point that the SSHGuard service
starts, the epehmeral file contents appear to be visible, but I think it's a
good bet that they are, and so are giving rise to those "command not found"
messages, and furthermore, only doing so on the initial boot, as any restarts
don't ever see the epehmeral file contents poking through.

"When the going gets wierd: the wierd turn pro"

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

On 2026/09/22 09:32, Kevin Buckley wrote:
> On 2026/09/21 16:26, Kevin Zheng wrote:
>> 
>> ...
> and there's definitely only one BACKEND line in
> 
> /etc/sshguard.conf
> 
> so I have no idea what could be invoking that sshg-fw-firewalld.
> 
> We could just overwrite that script and make it a no-op, but, as
> I think of it, it should not be being invoked in the first place.
FWIW, if we stop the sshguard service, and then restart it, we don't
see the extraneous invocations of sshg-fw-firewalld, suggesting the
issue is tied in to the way the initial startup is performed.

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

On 2026/09/21 16:26, Kevin Zheng wrote:
> 
> Lines 8-16 sound like the commands for firewalld initialization. 
> sshg-fw-firewalld is just a shell script so you can take a look at what 
> it is trying to do.

I did look at the file, and saw that it has 

${FIREW_CMD} <args>

on each of the line numbers referred to in the output, however

> Could you check that /etc/sshguard.conf is the correct location for your 
> config file, that it is not being overriden somewhere else, and that 
> there is not a subsequent BACKEND= line that sets it back to firewalld?
the relevant lines in the systemd service file are:

EnvironmentFile=-/etc/sshguard.conf
ExecStart=/usr/sbin/sshguard -a $THRESHOLD -p $BLOCK_TIME -s $DETECTION_TIME -w $WHITELIST_FILE -b $BLACKLIST_FILE

and then, from a drop-in, these commands that stand up, and teardown,
the sshguard chain within the IPTables environment:

ExecStartPre=/usr/sbin/iptables -N sshguard
ExecStartPre=/usr/sbin/iptables -A INPUT -p tcp -m tcp -j sshguard
ExecStopPost=/usr/sbin/iptables -D INPUT -p tcp -m tcp -j sshguard
ExecStopPost=/usr/sbin/iptables -F sshguard
ExecStopPost=/usr/sbin/iptables -X sshguard

and there's definitely only one BACKEND line in

/etc/sshguard.conf

so I have no idea what could be invoking that sshg-fw-firewalld.

We could just overwrite that script and make it a no-op, but, as
I think of it, it should not be being invoked in the first place.

Kevin

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin Z. <kev...@gm...>]

Hi Kevin,

It sounds like SSHGuard is running sshg-fw-firewalld on a system without 
a `firewall-cmd` command.

Lines 8-16 sound like the commands for firewalld initialization. 
sshg-fw-firewalld is just a shell script so you can take a look at what 
it is trying to do.

Could you check that /etc/sshguard.conf is the correct location for your 
config file, that it is not being overriden somewhere else, and that 
there is not a subsequent BACKEND= line that sets it back to firewalld?

Regards,
Kevin

Re: [SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

On 2026/09/21 15:18, Kevin Buckley wrote:
> 
> We're running: sshguard-2.4.2-bp157.1.6.x86_64
> 
> In
> 
>  /etc/sshguard.conf
> 
> we have
> 
> BACKEND="/usr/lib/sshg-fw-iptables"
> 
> but, as the service (systemd invoked on a SLES 15 OS) starts,
> we see the following, in var/log/messages
> 
> 2026-09-01T14:53:34.634459+08:00 <hostname> sshguard[93330]: blacklist: blocking 0 addresses
> 2026-09-01T14:53:34.634526+08:00 <hostname> sshguard[93330]: Now monitoring attacks.
> 2026-09-01T14:53:34.634761+08:00 <hostname> sshguard[93335]: /usr/lib/sshg-fw-firewalld: line 8: firewall-cmd: command not found
> 2026-09-01T14:53:34.635433+08:00 <hostname> sshguard[93336]: /usr/lib/sshg-fw-firewalld: line 9: firewall-cmd: command not found
> 2026-09-01T14:53:34.636143+08:00 <hostname> sshguard[93337]: /usr/lib/sshg-fw-firewalld: line 10: firewall-cmd: command not found
> 2026-09-01T14:53:34.636807+08:00 <hostname> sshguard[93338]: /usr/lib/sshg-fw-firewalld: line 12: firewall-cmd: command not found
> 2026-09-01T14:53:34.637501+08:00 <hostname> sshguard[93339]: /usr/lib/sshg-fw-firewalld: line 13: firewall-cmd: command not found
> 2026-09-01T14:53:34.637614+08:00 <hostname> sshguard[93330]: Attack from "83.235.21.125" on service SSH with danger 10.
> 2026-09-01T14:53:34.638156+08:00 <hostname> sshguard[93340]: /usr/lib/sshg-fw-firewalld: line 14: firewall-cmd: command not found
> 2026-09-01T14:53:34.638849+08:00 <hostname> sshguard[93341]: /usr/lib/sshg-fw-firewalld: line 16: firewall-cmd: command not found
> 2026-09-01T14:53:34.640565+08:00 <hostname> sshguard[93332]: sshg-fw-firewalld: Could not initialize firewall
> 
> so why is SSHGuard even bothering to look for firewalld-related
> things, which we aren't running, hence the config file setting?
I suppose the thing I failed to mention is that the "Attack from" line
in the above comes from PID 93330, and so do all the others that are
observed afterwards.

So maybe the question should be: what are those other 7 processes,
93335-93341, that seem to be "doing SSHGuard stuff" whilst ignoring
the sshguard.conf file setting?

[SSHGuard-users] sshguard.conf dictates sshg-fw-iptables backend: still runs sshg-fw-firewalld?

[Kevin B. <kev...@gm...>]

We're running: sshguard-2.4.2-bp157.1.6.x86_64

In

 /etc/sshguard.conf

we have

BACKEND="/usr/lib/sshg-fw-iptables"

but, as the service (systemd invoked on a SLES 15 OS) starts,
we see the following, in var/log/messages

2026-09-01T14:53:34.634459+08:00 <hostname> sshguard[93330]: blacklist: blocking 0 addresses
2026-09-01T14:53:34.634526+08:00 <hostname> sshguard[93330]: Now monitoring attacks.
2026-09-01T14:53:34.634761+08:00 <hostname> sshguard[93335]: /usr/lib/sshg-fw-firewalld: line 8: firewall-cmd: command not found
2026-09-01T14:53:34.635433+08:00 <hostname> sshguard[93336]: /usr/lib/sshg-fw-firewalld: line 9: firewall-cmd: command not found
2026-09-01T14:53:34.636143+08:00 <hostname> sshguard[93337]: /usr/lib/sshg-fw-firewalld: line 10: firewall-cmd: command not found
2026-09-01T14:53:34.636807+08:00 <hostname> sshguard[93338]: /usr/lib/sshg-fw-firewalld: line 12: firewall-cmd: command not found
2026-09-01T14:53:34.637501+08:00 <hostname> sshguard[93339]: /usr/lib/sshg-fw-firewalld: line 13: firewall-cmd: command not found
2026-09-01T14:53:34.637614+08:00 <hostname> sshguard[93330]: Attack from "83.235.21.125" on service SSH with danger 10.
2026-09-01T14:53:34.638156+08:00 <hostname> sshguard[93340]: /usr/lib/sshg-fw-firewalld: line 14: firewall-cmd: command not found
2026-09-01T14:53:34.638849+08:00 <hostname> sshguard[93341]: /usr/lib/sshg-fw-firewalld: line 16: firewall-cmd: command not found
2026-09-01T14:53:34.640565+08:00 <hostname> sshguard[93332]: sshg-fw-firewalld: Could not initialize firewall

so why is SSHGuard even bothering to look for firewalld-related
things, which we aren't running, hence the config file setting?

>From what I can see, the "firewall-cmd: command not found" messages
stop after "line 16", however, given

# wc -l /usr/lib/sshg-fw-firewalld
65 /usr/lib/sshg-fw-firewalld

who knows which file the "line 16" is in?

(Not that) Kevin

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Jim S. <jse...@Li...>]

On Tue, 21 Apr 2026 22:20:41 -0700
Kevin Zheng <kev...@gm...> wrote:

> Jim,
> 
> Thanks for the release. Sorry I've been pretty busy and haven't had
> an opportunity to take a good look.

No worries, Kevin. We're all volunteers :)

> 
> You mentioned that you are tracking changes in a Git repository 
> somewhere? Is that publicly cloneable?

It's a private Git repo, but you're welcome to a cloneable bundle of
the repo with full history. I can:

    - email it to you as an attachment
    - upload it somewhere
    - put it on my FTP server
    - put it somewhere on my web server

your choice. It's ~87k.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Kevin Z. <kev...@gm...>]

Jim,

Thanks for the release. Sorry I've been pretty busy and haven't had an 
opportunity to take a good look.

You mentioned that you are tracking changes in a Git repository 
somewhere? Is that publicly cloneable?

I haven't gotten around to writing the multi-sshg-parser wrapper but I 
should probably try to get the ball rolling just by importing atre.

Regards,
Kevin

Re: [SSHGuard-users] MaxAuthTries

[Kevin Z. <kev...@gm...>]

Jos,

On 4/10/26 1:40 AM, Jos Chrispijn wrote:
> When I set in sshguard.conf
> 
> MaxAuthTries4

What you are likely looking for is:

THRESHOLD=40

Each auth attempt is counted with a score of 10, so 4 auth attempts 
would result in a block at THRESHOLD=40.

Regards,
Kevin

[SSHGuard-users] MaxAuthTries

[Jos C. <ssh...@cl...>]

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#060606" bgcolor="#FFFFFF">
    <font face="Courier New, Courier, monospace">[sshguard-2.5.1,1]<br>
      <br>
      Hi,<br>
      When I set in sshguard.conf<br>
      <span class="typ"><br>
        MaxAuthTries</span><span class="pln"> </span><span class="lit">4<br>
        <br>
        it results in:<br>
        <br>
        /usr/local/etc/sshguard.conf: MaxAuthTries: not found<br>
        <br>
        Can you tell what I overlook here?<br>
        <br>
        Thanks, <br>
        Jos</span></font>
  </body>
</html>

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Jim S. <jse...@Li...>]

On Sun, 22 Mar 2026 19:17:00 -0700
Kevin Zheng <kev...@gm...> wrote:

> Hi Jim,
> 
> Thanks for your comments. I had an opportunity to take a look at
> the code. Thank you for your extensive documentation and comments.
> It looks fairly easy to understand and review. (Of course, the
> devil is always in the details...)
[snip]

Hi Kevin,

As you’ll probably see, I've finally managed to get the next version
out the door. It would've been sooner, but a few things intervened.
The upside is that the current version had additional soak time on my
own server.

I've exercised this version pretty thoroughly in a variety of
scenarios and haven’t been able to break it beyond expected failure
modes, all of which were handled cleanly.

Looking forward to your feedback and suggestions.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

[SSHGuard-users] A Regular Expression Attack Parser Addition/Replacement For SSHGuard: v0.1.0 Beta Released

[Jim S. <jse...@Li...>]

Hi All,

Attack Parser RE v0.1.0 has been released. This is a Beta release
that supersedes the prior, un-versioned release from 2022.

    NOTE: Please update any bookmarks or feed subscriptions. The
    project page and download URLs have moved from Jimsun to Athena,
    and the Atom feed URL has changed accordingly.

>From the ChangeLog:    

rel-0.1.0       2026-04-07

    First formal release under Git.

    Code has been in production use for several years but was
    previously maintained outside a formal version control system.

    - Improved robustness in edge cases

    - Improved resource cleanup on configuration errors

    - Fixed potential crash when removing a faulty regexp entry

    - Improved type safety and compiler warning coverage

    - Corrected regression test expectations

    - Refactored two large, complex functions into smaller, focused
      helpers to improve readability and maintainability

    - Removed PCRE POSIX compatibility build option as superfluous

    - General build cleanups and portability improvements

    - Added embedded version information -- visible via `atre-parser
      -V` and `strings attack_parser_re.o`

    - Added PCRE guard rails (match and recursion limits) to prevent
      pathological input from DoS’ing the system (verified graceful
      handling when limits are exceeded)

    - Added PCRE2 build-time support

    - Relicensed from GPL to ISC for compatibility with SSHGuard

    - Added LICENSE file to distribution

    No functional changes in normal operation. Behavior is consistent
    with the prior release.

Feedback and suggestions are welcome.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Jim S. <jse...@Li...>]

On Sun, 22 Mar 2026 20:00:37 -0700
Kevin Zheng <kev...@gm...> wrote:

> It sounds like there is a need to maintain context over multiple
> lines.
[snip]
> 
> I'm open to adding this functionality to sshg-parser. I will be
> taking a look at some point, unless someone wants to beat me to it.

My first reaction is that once you cross into multi-line matching,
the challenge becomes less “pattern matching” and more “stateful
inspection.”

I would expect the rule language would need some additional way to
express:

    • that a rule is stateful,
    • which step in a sequence a given pattern represents,
    • how steps are correlated with one another,
    • and when an incomplete match should expire.

For example, something along the lines of:

    <rule part> <g1:s1:t2>
    <rule part> <g1:s2:t2>

where g is a rule group, s is the sequence number, and t is the total
number of steps.

That's the easy part. The bigger challenge is correlation.

If multiple partial matches can be in flight at once, the parser
needs some reliable way to determine that a later log entry belongs
to a particular prior partial match. If the log format provides a
reliable, unique correlation token—such as Postfix's queue ID—that may
be doable. Without such a token, interleaved activity would make
matching ambiguous.

Even with a reliable means of positive correlation, there is still
the problem of devising rule syntax—and the underlying parser
logic—to express and manage state for arbitrary logging formats. That
strikes me as a likely significant increase in both syntactic and
implementation complexity.

There also has to be some mechanism to terminate stale state when an
expected follow-on log entry never shows up.

In short, this seems doable in principle, but I can see it getting
tricky very quickly.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] Regexp Attack Parser (was: Re: OpenSMTPD compatibility script)

[Jim S. <jse...@Li...>]

Hi Kevin,

Thanks for taking the time to review it, and for the kind words about
the documentation. I’m currently in the middle of a
cleanup/refactoring pass, and the next release should be
substantially easier to read, so you may wish to wait for that
version before spending much review effort.

That administrator-extensible rule capability was the primary impetus
for the project. Because of that, a lot of the effort went into
making rule loading, validation, matching, and reload behavior as
robust and defensive as I knew how.

That said, I expect there’s more I can do on the hardening front, and
I’ll take a closer look there.

To your enumerated points:

1. The ISC license is acceptable. I'll add it to the next release.

2. For integration, my instinct is to keep the initial path simple:
   Let sshg-parser run first, and if it finds no attack, pass the line
   to a secondary parser.

   Longer term, there may be value in a clean, extensible, pluggable
   parser architecture, but I don’t think that needs to block an
   initial integration.

   It’s always been my expectation that sshg-parser would remain the
   out-of-box default. My aim hasn’t been to replace it, but to
   complement it by covering signatures that are difficult or
   impractical to express in the existing yacc/lex-based parser.

3. I’m not (yet) familiar with Capsicum/pledge(), and don’t currently
   have a *BSD system available. (Though I am considering a new build
   for an experimental box, so that may change.) I appreciate the
   offer to help there.

4. I'll leave the CUSTOM_RULES question entirely in your hands, but
   it seems like a reasonable approach.

Btw: I’m considering renaming the project to something like "logreap"
("LOG Regular Expression Attack Parser"). Typing
"attack_parser_re.[ch]" every time I need to refer to or edit those
files has become a bit unwieldy.

I’m currently thinking along the lines of:

    • logreap (from logreap.c — currently atre_parser.c / atre-parser)
    • logreap_core.c and logreap_core.h (currently
      attack_parser_re.[ch])

I may or may not leave the internal structure and variable names
as-is.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] [SPAM] Directly rate limiting

[<gi1...@gm...>]

Thanks Kevin. It may be good to post this on the sshguard website.

For simple use cases the not-smart algorithm may suffice for many users.
In my case I have 3 computers. I need sshguard's "smartness" on one, and
it looks like the simple rate limiting algorithm works well on my other
two computers.

Thanks again,

GI

-- 
'School' -- Place where people learn how to copy textbooks, for that
common situation in later life when the photocopier breaks and you
really need part of a book you aren't allowed to borrow.

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Pietro C. <ga...@ga...>]

> On 23 Mar 2026, at 04:01, Kevin Zheng <kev...@gm...> wrote:
> 
> It sounds like there is a need to maintain context over multiple lines. While OpenSMTPD seems like the current most popular culprit, I'm sure there will be other examples as well.

Since I started this thread, there's been progress on OpenSMTP's side to restore single-line context:
https://github.com/OpenSMTPD/OpenSMTPD/pull/1303

If (when?) this lands, we can get back to a usable state wrt OpenSMTPD with a simple fix to the lexer/parser.

-- 
Pietro Cerutti
I've pledged to give 10% of income to effective charities and invite you to join me.
https://givingwhatwecan.org

Sent from a small device - please excuse brevity and typos.

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Kevin Z. <kev...@gm...>]

It sounds like there is a need to maintain context over multiple lines. 
While OpenSMTPD seems like the current most popular culprit, I'm sure 
there will be other examples as well.

I'm open to adding this functionality to sshg-parser. I will be taking a 
look at some point, unless someone wants to beat me to it.

Regards,
Kevin

Re: [SSHGuard-users] [SPAM] Directly rate limiting

[Kevin Z. <kev...@gm...>]

GI,

Thank you for your question. I should post something to the website 
answering it, but for now, here is my answer:

1. Legitimate users sometimes exceed the rate limit, e.g. when doing
    something involving multiple connections with rsync. SSHGuard does
    not block legitimate users.

2. Rate limiting is not particularly smart. The example  given in the
    linked article is "6 or more connections in the last 30 seconds", or
    720 attempts per hour. SSHGuard uses a geometrically-increasing
    factor of 2. So after 3 failed attempts, the wait time is 2 minutes,
    then 4, 8, 16, 32... or about 5x3=15 attempts per hour.

Regards,
Kevin

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Kevin Z. <kev...@gm...>]

Hi Jim,

Thanks for your comments. I had an opportunity to take a look at the 
code. Thank you for your extensive documentation and comments. It looks 
fairly easy to understand and review. (Of course, the devil is always in 
the details...)

Of course, I would like to keep sshg-parser as the out-of-box default. 
It is faster and theoretically more secure because it doesn't use PCRE 
(though I noted that there is a POSIX-regex-only version). This, I 
think, differentiates SSHGuard from other tools, e.g. fail2ban.

On the other hand there is a clear and obvious improvement for an 
administrator to be able to add their own attack signatures and have 
them update on-the-fly without recompiling and restarting SSHGuard.

So, if you are interested in integrating your work into SSHGuard, that 
would be welcome. A path forward would roughly be:

1. Clarify license terms. SSHGuard is currently available under the ISC
    License. I don't know how many SSHGuard users care about this
    license, but I would like to keep the main tarball licensed this way
    for now. Would you be willing to relicense your work under these
    terms? If not, there are still other options.

2. Either sshg-parser would need to be modified, or a new parser wrapper
    that distributes attack signatures to multiple parser processes needs
    to be written. The idea is that sshg-parser is run first, and then if
    no attack is found it passes it to subsequent parsers. This helps
    avoid duplicates. And, in theory, it is faster, but computers are
    pretty fast these days.

3. Add Capsicum/pledge() sandboxing to atre-parser. If you are not
    familiar with these or don't have FreeBSD/OpenBSD available, I can
    help with this part.

4. Finally, add something to sshguard.conf, e.g. CUSTOM_RULES that turns
    launches atre-parser when configured.

Let me know your thoughts.

Regards,
Kevin

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Jim S. <jse...@Li...>]

On Thu, 5 Mar 2026 13:58:25 -0800
Kevin Zheng <kev...@gm...> wrote:

> Hi Pietro, Jim:
> 
[snip]
> 
> There is already a mechanism in sshguard.conf by which you can
> elect to run a filter that isn't the default "sshg-parser". One can
> imagine an "octopus" parser that gives attacks to atre,
> sshg-parser, and others in parallel and collects the detected
> attacks. Is that of interest?

Hi Kevin,

I meant to mention this before...

There's a solution to the above: Run-time-loadable modules—perhaps
with an associated config file that tells sshguard whether to run
them sequentially, and in what order, or in parallel.

Though ISTM running multiple parsers in parallel could be a recipe
for confusion, but ICBW.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

[SSHGuard-users] [SPAM] Directly rate limiting

[<gi1...@gm...>]

Hi All,

I've been using SSHGuard for some 10 years now; thanks a lot.

Recently when upgrading my config I noticed that my firewall (ufw,
backend nftables) supports rate limiting SSH connections. It's explained
nicely here:

    https://wiki.archlinux.org/title/Uncomplicated_Firewall#Rate_limiting_with_ufw

Does doing this have any advantages / disadvantages over sshguard?

Thanks and best,

GI

-- 
I have a few jokes about unemployed people but it doesn't matter.
None of them work.

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Jim S. <jse...@Li...>]

On Thu, 5 Mar 2026 13:58:25 -0800
Kevin Zheng <kev...@gm...> wrote:

> Hi Pietro, Jim:
> 
[snip]
> 
> I have been slow to integrate contributions like these into the
> SSHGuard distribution proper. I think it's because I feel like I
> want a well-integrated core in SSHGuard that fits together well and
> has certain security guarantees.
> 
> But I'm also aware that folks want faster attack signature updates,
> and maybe even the ability to add their own without mucking around
> in flex/yacc.
[snip]

Hi Kevin,

I can understand your reluctance to integrate something the size and
complexity of the regular-expression-based attack parser I wrote. It
is, admittedly, a fairly involved piece of code.

It ended up that way because I was trying to satisfy two specific
goals:

    • To be as robust as possible
    • Tolerant of misconfiguration—even actively broken user input

That led to some of the added complexity—particularly around careful
processing of RE configuration files, disabling faulty expressions at
runtime, and very defensive memory management.

For what it’s worth:

    • It has been running without incident for several years on four
      Internet-facing systems I administer
    • After revisiting the code in light of your comments and
      conducting a fresh review with AI assistance, I identified and
      fixed a few weaknesses

The new code has been regression-tested and is currently deployed on
three of those systems, with the fourth scheduled shortly. Assuming no
issues arise, I plan to publish a 0.1.0 release soon.

I completely understand the desire to keep SSHGuard’s core tight and
well-integrated. My intent here isn’t *necessarily* to push for
inclusion as-is, but to offer an approach that might help address the
“custom signatures without touching flex/yacc” problem space you
mentioned.

If you think it would be useful, I’d be happy to walk through the
design or discuss how something like this could be adapted to better
fit SSHGuard’s architecture.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.

Re: [SSHGuard-users] OpenSMTPD compatibility script

[Pietro C. <ga...@ga...>]

> On 5 Mar 2026, at 22:58, Kevin Zheng <kev...@gm...> wrote:
> 
> There is already a mechanism in sshguard.conf by which you can elect to run a filter that isn't the default "sshg-parser". One can imagine an "octopus" parser that gives attacks to atre, sshg-parser, and others in parallel and collects the detected attacks. Is that of interest?

Hi Kevin,

yeah, I'd like to think of a protocol that could be implemented by 3rd party parsers.

Perhaps sshguard would launch the provided program which would simply emit one offending address per line.

Pietro

-- 
Pietro Cerutti
I've pledged to give 10% of income to effective charities and invite you to join me.
https://givingwhatwecan.org

Sent from a small device - please excuse brevity and typos.