That may be.
That may be better than the pam module, I don't know.

I've used sshdfilter in the past, which only keeps the rules for a host for a few days to help avert the bloated iptable rules but they still can get quite big. Of course with cpu's getting faster and faster it is becoming less of an issue (my first server was a 233MHz Beige G3 running Yellow Dog).

But I found changing the port (and configuring my ~/.ssh/config file so I don't have to constantly use the -p switch) to be extremely effective, as in weeks and even often months between brute force attempts.

PAM modules require PAM...

Yup - they sure do.
If you are not running PAM anyway it probably is not worth installing PAM just for the pam module, especially since changing the port is so effective anyway.

Easy defeat of SSH Brute force? fail2ban + pubkey auth (disable password auth)

I was using an abnormally high (for me) ammount of bandwidth for a few days in a row. Using ntop I found that 99% of it was HTTP so I check my Apache logs. Turned out 90% of my HTTP traffic was going to brazil. I don't know anyone in brazil and they really dont need to be donloading random files so I used IP tables and blocked most of the traffic from .br domains. Traffic immediately went down to normal.

Check your box. People usually don't just download random files. Don't be surprised if you find porn or warez on it, in which case someone got in.

Or the guy could have been mirroring his website for some reason.

That is a definite possibility that I would bet on or Framing it

_________________

Where "Thought Crime" is commited
http://www.rejecttheherd.net

denyhosts works well for ssh based attacks

Few different things to try really and it all depends on the level of security you want.

Honestly, key-based authentication is the best way to go for security. The only issue is if you lose this key for whatever reason you're screwed. Also, you would need to carry it with you if you went to many different places.

For what it's worth though, even if you went to a public terminal and used your SSH key you'd be in a much more secure situation. A person is sooner to install a keylogger than mirror a usb device or copy the files to the disk.

Disabling password authentication essentially completely removes anyone's ability to bruteforce the server. Particularly if you set the amount of fails to 1. (By this I mean the fact that bruteforcing the key would be significantly more difficult than bruteforcing hellomynameisbob for a password) For the time being, this also helps negate keyloggers. As far as that being a permanent solution, not really. As more people catch on to the SSL craze, undoubtedly someone out there is going to start writing a worm that tries to capture SSL private keys when you use them.

You could kick the number of failed attempts up and use something such as denyhosts or fail2ban to block further attempts. Not sure about f2b but deynhosts also houses a centralized server where you can either send hosts or download hosts to also block as poeple get blocked on other configurations.

Of course, it depends on what your needs are. Not a whole lot of people understand the whole public/private key thing nor how to use it in the context of SSH.

I kind of went into a longer post in this than I intended, but just to sum up for people in a few short words.

Change the default SSH port from 22. Random bots aren't going to scan other ports for SSH. Consider setting this to a port above 1024. For example, 43921.

Consider disabling password authentication altogether and using key-based authentication. This significantly reduces the ability of a bruteforce attack. And furthermore, in almost all cases since your private key is the same there's no chance of typos, so you can then lower the failed attempts count down to 1 or 2 which will disconnect users each time. This also for the time being allows you to get around keyloggers

Fail2ban or Denyhosts. Both allow you to block repeated attempts at logging into your sshd.

PortSentry. More of a port scanner detection tool, but you can run it on low ports so if someone scans 1-1024, your server can block their IP via iptables rules and they won't ever find any of your other services.

Excellent summary A-KO, just want to point out some issues I've run into in the course of my employment:

* People are lazy with key security
* People make their keys passwordless, which makes them more vulnerable
* Using keys on a public system is still bad, it requires a certain level of trust, albeit a compromise is somewhat less likely