Fwd: Re: sshd exponential backoff patch

[Sam Watkins]

> This is a really nice idea. However, I'm not so hot on making a core
> utility such as OpenSSH reliant on a library that isn't by default
> available on most platforms.

It could be done differently.

I'm surprised that you think berkeley db would not be available on most
platforms by default. Anyway it should be a compile-time (and run time)
configurable option, so if the library is really not available the
feature would not be included. Openssh packages for debian already rely
on a variety of libraries.  In Debian, libdb4.7 is marked with priority
"required", so I guess it is an essential / core package at least for
Debian. Well known packages that depend on it include libpam-modules,
bind9, evolution, xemacs, squid, postfix. So it seems to be a pretty
"core" package especially for a server. It is portable to at least
"Linux, Windows, BSD UNIX, Solaris, Mac OS/X, VxWorks and any POSIX-
compliant operating system".

> > I think this problem might be better solved outside of sshd
>
> I agree. For example by using the firewall.

I think the problem with running "tail" on the logs or whatever and then
feeding that data to the firewall is that an attacker would have time
for probably a couple hundred attacks before that system would notice
what's going on. or maybe there's a better way to do that which I don't
know about. Also it would be non standard and complicated to configure
it.

The fact that the vast majority of ssh servers do not have any such
protection (I don't have a source for this but I'll bet it's true)
suggests to me that some solution should be available within sshd, that
doesn't require a week for an expert sysadmin to set it up and test it.

I don't consider my code a very good solution, but it's better than no
solution, so I am using it.  If anyone else would come up with a better
solution I'd like to see it or use it instead.

Attackers can now only make 20 attacks per year per IP address on my
server. Previously they could have made millions of attacks or more. I
think this is a worthwhile improvement even though the implementation is
not ideal yet. This is particularly suitable for my server which is a
shell server, there might be some users with poor passwords. So this is
one part of a solution for me.

Sam