Menu
▾
▴
sshguard-users — User questions and answers, bugs, and general support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: hvjunk <hv...@gm...> - 2018-07-23 12:44:26
|
> On 23 Jul. 2018, at 14:36 , hvjunk <hv...@gm...> wrote: > > Good day, > > Other than an update of the whitelist file, and restarting sshguard (with all the current blocks being removed), is there another mechanism to dynamically update whitelist IPs? > > The “challenge” is that I have dynamically assigned IPs, like mobile devices, that have (for various reasons) trigged the sshguard blocking. I could do the updates of the whitelist file in some way out of band, but the problem is the current blocks are then removed and “forgotten”, which I would prefer not to happen, and I don’t want to open up/whitelist /16 sized netblocks to not restart the sshguard process. > > Perhaps would the developers accept a “sshguard-control” type API/interface/program pull request? After I sent this, I saw the source code also makes use of ipset(s), and I wondered perhaps to change the sshguard rules, to also have a whitelist, together with the blacklist that would be bypassing the sshguard block chain? |
|
From: hvjunk <hv...@gm...> - 2018-07-23 12:36:30
|
Good day, Other than an update of the whitelist file, and restarting sshguard (with all the current blocks being removed), is there another mechanism to dynamically update whitelist IPs? The “challenge” is that I have dynamically assigned IPs, like mobile devices, that have (for various reasons) trigged the sshguard blocking. I could do the updates of the whitelist file in some way out of band, but the problem is the current blocks are then removed and “forgotten”, which I would prefer not to happen, and I don’t want to open up/whitelist /16 sized netblocks to not restart the sshguard process. Perhaps would the developers accept a “sshguard-control” type API/interface/program pull request? HEndrik |
|
From: Kevin Z. <kev...@gm...> - 2018-07-14 15:21:10
|
On 07/13/2018 05:37, Jos Chrispijn wrote: > Sometimes I change some setting in ipfw and have to also restart SSHGuard. > > I do this by commandline > > /letc/rc.d/sshguard restart > > At that very moment I don't get my prompt back but get a display line > like this: > > *me@kriti > added: 88.164.126.91/32 0* > > which obviously is a sshguard action > > What I then do is hit Ctrl-C to stop these displays (it is every time > another IP) and that works. > > My question is however: do I kill the running sshguard process with that > and do I need to start it after again (which brings me in the same loop > as described above)? I'd have to take a closer look. Quick inspection shows that the rc.d script calls `daemon` because SSHGuard temporarily dropped support for writing the PID file. Now that SSHGuard can take the -i option again, perhaps `daemon` is no longer needed. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Jos C. <ssh...@cl...> - 2018-07-13 10:38:11
|
Sometimes I change some setting in ipfw and have to also restart SSHGuard. I do this by commandline /letc/rc.d/sshguard restart At that very moment I don't get my prompt back but get a display line like this: *me@kriti > added: 88.164.126.91/32 0* which obviously is a sshguard action What I then do is hit Ctrl-C to stop these displays (it is every time another IP) and that works. My question is however: do I kill the running sshguard process with that and do I need to start it after again (which brings me in the same loop as described above)? thanks, Jos ** -- With both feed on the ground you will never make a step forward |
|
From: Kevin Z. <kev...@gm...> - 2018-07-11 17:19:09
|
Hi there, Since 2.x piping logs into SSHGuard via stdin gave a warning: # sshguard sshguard: Reading from stdin. You probably shouldn't be doing this. This behavior is being considered for removal because it prevents resolution of issue #90, where the driver script ignores signals sent to it. Note that killing the process indicated in the PID file set by '-i' continues to work, because that reports the PID of sshg-blocker. Does anyone still depend on this behavior? If so, please let me know why and what we can do to work around it. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-07-10 16:24:44
|
On 07/10/2018 11:02, Christos Chatzaras wrote: > Greylisting allows a mail server to resend the e-mail after 5 > minutes. So if a mail server retries in 4 minutes does it block it? > Or it only blocks if a mail server tries to send it multiple times > during the first 5 minutes? Early retries are detected as 'attacks' with score 10. Attacks are not blocked unless the cumulative score in a time interval exceeds a threshold (by default 30), so a conforming mail server should not trigger the block if you use the defaults. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Jos C. <ssh...@cl...> - 2018-07-10 16:11:20
|
On 10-7-2018 18:02, Christos Chatzaras wrote: > Greylisting allows a mail server to resend the e-mail after 5 minutes. So if a mail server retries in 4 minutes does it block it? Or it only blocks if a mail server tries to send it multiple times during the first 5 minutes? You can configure greylisting with any time interval. What I reported is excessive mail dropping behavior (every second by the same mailserver ip for the same email account) for multiple times. /Jos -- With both feed on the ground you will never make a step forward |
|
From: Christos C. <ch...@cr...> - 2018-07-10 16:02:31
|
Greylisting allows a mail server to resend the e-mail after 5 minutes. So if a mail server retries in 4 minutes does it block it? Or it only blocks if a mail server tries to send it multiple times during the first 5 minutes? > On 10 Jul 2018, at 18:29, Jos Chrispijn <ssh...@cl...> wrote: > > On 10-7-2018 14:15, Christos Chatzaras wrote: >> Can you explain how postfix greylist early retry works? >> > What I know about it: > > Normally first time connection with postgrey results in a greylisting message and time out. > > But lately there are mailservers that still try every second to drop the same email (although everyone knows what greylisting is about). > I reported this behavior to the author and he considered this as annoying behavior too, resulting in putting these kind of mailservers on the internal black list. > > -- With both feed on the ground you will never make a step forward |
|
From: Jos C. <ssh...@cl...> - 2018-07-10 15:29:53
|
On 10-7-2018 14:15, Christos Chatzaras wrote: > Can you explain how postfix greylist early retry works? > What I know about it: Normally first time connection with postgrey results in a greylisting message and time out. But lately there are mailservers that still try every second to drop the same email (although everyone knows what greylisting is about). I reported this behavior to the author and he considered this as annoying behavior too, resulting in putting these kind of mailservers on the internal black list. -- With both feed on the ground you will never make a step forward |
|
From: Christos C. <ch...@cr...> - 2018-07-10 12:33:30
|
Hello, Can you explain how postfix greylist early retry works? Kind regards, Christos Chatzaras |
|
From: Jos C. <ssh...@cl...> - 2018-07-10 11:45:24
|
On 9-7-2018 21:42, Kevin Zheng wrote: > Hi there, > > SSHGuard 2.2.0 is now available for download on SourceForge [1]. > Thanks, appreciate the support! Any donation link available? -- With both feed on the ground you will never make a step forward |
|
From: Kevin Z. <kev...@gm...> - 2018-07-09 19:42:20
|
Hi there, SSHGuard 2.2.0 is now available for download on SourceForge [1]. **Added** - Add '--disable-maintainer-mode' in configure for package maintainers - BusyBox log banner detection - Match Exim "auth mechanism not supported" - Match Exim "auth when not advertised" - Match Postfix greylist early retry - OpenSMTPD monitoring support - Recognize IPv6 addresses with interface name **Changed** - Ignore CR in addition to LF - Only log attacks if not already blocked or whitelisted **Fixed** - Use correct signal names in driver shell script [1] https://sourceforge.net/projects/sshguard/files/sshguard/ -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: jungle B. <jun...@gm...> - 2018-07-05 17:35:31
|
On 5 July 2018 at 10:27, Kevin Zheng <kev...@gm...> wrote: >> >> OpenBSD x64 -current with autoreconf-2.69. > > Thanks for the report on OpenBSD. > > This warning from autoconf is known, and you can safely ignore it for > now, unless of course, there's an error that I'm missing. > Probably not. the config and make went well. I've restarted the service > I'd be curious if pledge() support in the parser is still working? > Do you know how I would go about testing that? > -- > Kevin Zheng > kev...@gm... | ke...@be... | PGP: 0xC22E1090 -- ------- inum: 883510009027723 sip: jun...@si... |
|
From: Kevin Z. <kev...@gm...> - 2018-07-05 17:28:07
|
On 07/05/2018 12:26, jungle Boogie wrote: > On 5 July 2018 at 10:17, Kevin Zheng <kev...@gm...> wrote: >> Hi folks, >> >> >> - Use correct signal names in driver shell script >> >> The new release will be cut over the weekend. Git users, consider giving >> current master a whirl. >> > > I don't know the current version of sshugard I have, but it's from > master and fairly recent (+/- 1month is my guess). > > When I updated src and did autoreconf -i (per build instructions), I have this: > > $ autoreconf -i > configure.ac:19: installing './ar-lib' > configure.ac:13: installing './compile' > configure.ac:7: installing './install-sh' > configure.ac:7: installing './missing' > configure.ac:9: installing './tap-driver.sh' > src/blocker/Makefile.am:5: warning: source file '../common/simclist.c' > is in a subdirectory, > src/blocker/Makefile.am:5: but option 'subdir-objects' is disabled > automake-1.15: warning: possible forward-incompatibility. > automake-1.15: At least a source file is in a subdirectory, but the > 'subdir-objects' > automake-1.15: automake option hasn't been enabled. For now, the > corresponding output > automake-1.15: object file(s) will be placed in the top-level > directory. However, > automake-1.15: this behaviour will change in future Automake versions: they will > automake-1.15: unconditionally cause object files to be placed in the > same subdirectory > automake-1.15: of the corresponding sources. > automake-1.15: You are advised to start using 'subdir-objects' option > throughout your > automake-1.15: project, to avoid future incompatibilities. > src/blocker/Makefile.am: installing './depcomp' > src/fw/Makefile.am:26: warning: source file '../common/simclist.c' is > in a subdirectory, > src/fw/Makefile.am:26: but option 'subdir-objects' is disabled > configure.ac: installing './ylwrap' > parallel-tests: installing './test-driver' > > > OpenBSD x64 -current with autoreconf-2.69. Thanks for the report on OpenBSD. This warning from autoconf is known, and you can safely ignore it for now, unless of course, there's an error that I'm missing. I'd be curious if pledge() support in the parser is still working? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: jungle B. <jun...@gm...> - 2018-07-05 17:26:13
|
On 5 July 2018 at 10:17, Kevin Zheng <kev...@gm...> wrote: > Hi folks, > > > - Use correct signal names in driver shell script > > The new release will be cut over the weekend. Git users, consider giving > current master a whirl. > I don't know the current version of sshugard I have, but it's from master and fairly recent (+/- 1month is my guess). When I updated src and did autoreconf -i (per build instructions), I have this: $ autoreconf -i configure.ac:19: installing './ar-lib' configure.ac:13: installing './compile' configure.ac:7: installing './install-sh' configure.ac:7: installing './missing' configure.ac:9: installing './tap-driver.sh' src/blocker/Makefile.am:5: warning: source file '../common/simclist.c' is in a subdirectory, src/blocker/Makefile.am:5: but option 'subdir-objects' is disabled automake-1.15: warning: possible forward-incompatibility. automake-1.15: At least a source file is in a subdirectory, but the 'subdir-objects' automake-1.15: automake option hasn't been enabled. For now, the corresponding output automake-1.15: object file(s) will be placed in the top-level directory. However, automake-1.15: this behaviour will change in future Automake versions: they will automake-1.15: unconditionally cause object files to be placed in the same subdirectory automake-1.15: of the corresponding sources. automake-1.15: You are advised to start using 'subdir-objects' option throughout your automake-1.15: project, to avoid future incompatibilities. src/blocker/Makefile.am: installing './depcomp' src/fw/Makefile.am:26: warning: source file '../common/simclist.c' is in a subdirectory, src/fw/Makefile.am:26: but option 'subdir-objects' is disabled configure.ac: installing './ylwrap' parallel-tests: installing './test-driver' OpenBSD x64 -current with autoreconf-2.69. > -- > Kevin Zheng > kev...@gm... | ke...@be... | PGP: 0xC22E1090 -- ------- inum: 883510009027723 sip: jun...@si... |
|
From: Kevin Z. <kev...@gm...> - 2018-07-05 17:23:10
|
On 06/13/2018 16:55, George Wilder via sshguard-users wrote: > I am fairly new to sshguard. I installed the version that comes with > Ubuntu 18.04: > > ==> sshguard -v sshguard 1.7.1 > > And it’s protecting ssh just fine. I verified that by creating > multiple login failures. My IP was blocked. I recovered by removing > it from the black list. > > I recently set up an e-mail server using postfix and dovecot. > > My question is do I need to so anything special to enable sshguard > protection for e-mail (/var/log/mail.log)? Or is it enabled already? Sorry for the very late reply; hope this is still relevant. SSHGuard will look for any attacks it recognizes in the logs you give it. If your journalctl contains lines from /var/log/mail.log and your firewall is set up to block all ports instead of only 22, there's nothing more you need to do. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-07-05 17:17:55
|
Hi folks, After a hiatus from the old release schedule, SSHGuard 2.2.0 is finally around the corner. Only bug fixes were made to components outside of the parser, and the parser has a new suite of tests, so no new bugs are anticipated. **Added** - Add '--disable-maintainer-mode' in configure for package maintainers - BusyBox log banner detection - Match Exim "auth mechanism not supported" - Match Exim "auth when not advertised" - Match Postfix greylist early retry - OpenSMTPD monitoring support - Recognize IPv6 addresses with interface name **Changed** - Ignore CR in addition to LF - Only log attacks if not already blocked or whitelisted **Fixed** - Use correct signal names in driver shell script The new release will be cut over the weekend. Git users, consider giving current master a whirl. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-06-27 20:58:02
|
On 06/27/2018 12:54, Bob Wooldridge wrote: > I'm doing some testing with my firewall and I want to erase an IP from > sshguards memory so that I can start over. Is there a way to do this? Not currently, unless you restart SSHGuard. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Bob W. <bob...@ed...> - 2018-06-27 19:54:33
|
I'm doing some testing with my firewall and I want to erase an IP from sshguards memory so that I can start over. Is there a way to do this? -- Bob Wooldridge EDM Incorporated http://www.edm-inc.com |
|
From: Jos C. <ssh...@cl...> - 2018-06-26 09:24:22
|
Kev, I sent you my logfile a week ago - did you have time to check it or should I resend? On 20-6-2018 20:33, Kevin Zheng wrote: > On 06/20/2018 07:52, Jos Chrispijn wrote: >> Lately I see that there are more and more spam servers that are trying >> 30 times in 30 seconds to dump their email. >> Of course mankind found out greylisting for that too, but is there a way >> to block these ip's with sshguard as well? > What mail server are you using? Can you give some examples of the log > messages that you get? > -- With both feed on the ground you will never make a step forward |
|
From: Kevin Z. <kev...@gm...> - 2018-06-25 22:17:34
|
On 06/20/2018 07:56, Jos Chrispijn wrote: > Using 'sshguard -v' results in a > > SSHGuard 2.1.0 > Terminated > > What is the function of that 2nd line? Cannot remember I saw that earlier... I see this, too. I think it has to do with the recursive trap that now gets set in the sshguard driver script. I think it's harmless, but I'll investigate if there's an issue or a better way to do it. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-06-25 20:59:20
|
On 06/25/2018 13:24, Bob Wooldridge wrote: > I have sshguard version 2.1.0 installed on Devuan 2.0 (a debian variant > without systemd). I am running sshd under daemon tools and using > multilog, but auth.log also registers failed attempts. I have also set > up sshguard to run under daemontools. Here is my run script: > >> #!/bin/sh >> >> export SSHGUARD_DEBUG=1 >> exec 2>&1 >> exec /usr/local/sbin/sshguard > > I have tried configuring the sshgaurd.conf file to watch auth.log or the > sshd multilog which I put in /var/log/sshd/current. In the > /usr/local/etc/sshguard.conf file I set the FILE variable to > /var/log/sshd/current. When I run sshgaurd, the output is this: > But when I try to login with bad password sshguard does not seem to > recognize it. There is nothing in the sshguard log. > > What am I doing wrong?? Could you paste a few examples of lines from your /var/log/sshd/current that should be detected? I could be that it just doesn't recognize the log messages on your system. The "trap: SIGINT: bad trap" is a bug that has since been fixed but probably isn't the one causing issues for you. What did you run to generate that iptables output, or did that just show up by itself? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Bob W. <bob...@ed...> - 2018-06-25 20:53:05
|
I have sshguard version 2.1.0 installed on Devuan 2.0 (a debian variant without systemd). I am running sshd under daemon tools and using multilog, but auth.log also registers failed attempts. I have also set up sshguard to run under daemontools. Here is my run script: > #!/bin/sh > > export SSHGUARD_DEBUG=1 > exec 2>&1 > exec /usr/local/sbin/sshguard I have tried configuring the sshgaurd.conf file to watch auth.log or the sshd multilog which I put in /var/log/sshd/current. In the /usr/local/etc/sshguard.conf file I set the FILE variable to /var/log/sshd/current. When I run sshgaurd, the output is this: > trap: SIGINT: bad trap > sshguard[16082]: whitelist: add IPv4 block: 127.0.0.0 with mask 8. > sshguard[16082]: whitelist: add '127.0.0.1' as plain IPv4. > sshguard[16082]: whitelist: add plain IPv4 127.0.0.1. > sshguard[16082]: Now monitoring attacks. > Chain INPUT (policy DROP) > target prot opt source destination > sshguard all -- 0.0.0.0/0 0.0.0.0/0 > ACCEPT all -- 127.0.0.1 127.0.0.1 > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED > ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 3 > ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 11 > ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 > ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 0 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8095 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 > > Chain FORWARD (policy DROP) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Chain sshguard (1 references) > target prot opt source destination But when I try to login with bad password sshguard does not seem to recognize it. There is nothing in the sshguard log. What am I doing wrong?? -- Bob Wooldridge EDM Incorporated http://www.edm-inc.com |
|
From: Kevin Z. <kev...@gm...> - 2018-06-20 18:33:36
|
On 06/20/2018 07:52, Jos Chrispijn wrote: > Lately I see that there are more and more spam servers that are trying > 30 times in 30 seconds to dump their email. > Of course mankind found out greylisting for that too, but is there a way > to block these ip's with sshguard as well? What mail server are you using? Can you give some examples of the log messages that you get? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Jos C. <ssh...@cl...> - 2018-06-20 15:08:57
|
Using 'sshguard -v' results in a SSHGuard 2.1.0 Terminated What is the function of that 2nd line? Cannot remember I saw that earlier... Regards, Jos -- With both feed on the ground you will never make a step forward |
2 messages has been excluded from this view by a project administrator.
