Arch Linux

@redden0t8 yep, i also have "PermitRootLogin no" in sshd_config, and also uncommented the mentioned line in /etc/pam.d/sshd to disable remote root login.

Actually, the reason why i had that question is because i migrated to an updated pambase configuration. Mine looks like this now:

#%PAM-1.0
auth required pam_securetty.so #disable remote root
auth required pam_abl.so config=/etc/security/pam_abl.conf
auth include system-remote-login
account include system-remote-login
password include system-remote-login
session include system-remote-login

I figured i'd add the "disable remote root" line first, because i have excluded "root" account from blocking by pam_abl.

Just another thought: perhaps a wiki page have to be edited.

Kyak, personally I never bothered as I have "PermitRootLogin no" in my sshd_config, although more layers can never hurt. I think I'm going to add it right now :)

As a side note, an update to pambase changed the structure of the pam configuration files, there are now a few central files referenced by each package-specific file. You might want to look at sshd.pacnew and migrate over - although I don't know if there's really any advantage at this point anyways. Mine now looks like:

#%PAM-1.0
auth required pam_abl.so config=/etc/security/pam_abl.conf
auth include system-login
account include system-login
password include system-login
session include system-login

I'm just wondering, do you guys uncomment the line "auth required pam_securetty.so", which disables remote root and is commented by default in /etc/pam.d/sshd?

I should note that a less-serious but related issue remains, which is why upstream has not released a new version yet.

The issue is failure of the first attempt is not logged until a second attempt is made or the connection is closed. This means that long as the attacker only makes one attempt per connection, and never closes any connections, no failures are ever logged.

In practice, the sshd_config settings "MaxStartups" (default 10) and to a lesser degree "LoginGraceTime" (default 120s) limit the viability of this approach, but it still could be used to squeeze out more attempts then you specify.

In the meantime, the workaround is to set "MaxAuthTries" to 1 (or expect that an additional "MaxStartups" number of attempts could be made above and beyond what you specify in your pam_abl config).

Thanks for the warning buergi. I've updated the pkgbuild to patch in the fix until upstream releases a new version. I did some quick tests on the resulting build and it now appears to function correctly.

Another question would be -why won't they release an updated version IMMEDIATELY?

God damnit, i should've paid more attention to those messages in log.

Thank you buergi and thank myself for using several layers of protection (the second one being iptables rule to ban > 4 connect attempts in 60 seconds.

WARNING: this package is non-functional it does not block anything! The second try always succeeds even for blocked users/hosts. See bugreport BUG3564436 or the commit message of the fixing commit http://pam-abl.git.sourceforge.net/git/gitweb.cgi?p=pam-abl/pam-abl;a=commit;h=a7f04548a1e9d139e843a15e7c0cda785ffb6f61

I added a git version of the package to the AUR basing on this package, I recommend anyone to switch to pam_abl-git as long as no newer version than 0.5.0 is available!

Fixed, thanks kyak.

cmake needs to be added as a dependency