[ale] any suggestions on an automated method for blocking repeated failed ssh login attempts?

[Michael Trausch]

Not sure what his reply is going to be, but I can say that if there is a
delay, it should be inherent to the method of key generation.  For example,
if using a strong password as input to a KDF that runs a million rounds,
there will be a noticable delay to the key generation.  Sadly, there is no
way to pick a universally applicable number of rounds, though; very old
systems won't be able to reasonably generate keys if there are more than
several tens of thousands of iterations, while very new systems may not
delay at all.

I have one system-in-progress that is setup to generate keys with 10,000,000
rounds, making the delay on my system around three seconds to generate the
key.  In the target environment it takes ~10 seconds.  The only purpose is
to reduce the feasibility of brute forcing by increasing the time it takes
to generate a key.

It seems that 1,000 to 10,000 iterations is the common value, but on my
systems this provides nearly no delay whatsoever.  Certainly not one which
is perceptable to me.  Given a 3 second delay to generate a key that would
mean that it my system can only brute 120 keys per minute, if those keys all
pass through the algorithm.  It also means that invalid passwords will take
some time, even locally, to find that they are invalid, which is the point
with something like this where there may not be a client/server interaction.

--
Sent from my G2 running CyanogenMod!
That is, a phone. :)
On Dec 23, 2010 6:34 PM, "Matty" <matty91 at gmail.com> wrote:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20101223/3057238a/attachment.html