Time to add exponential backoff for SSH interactive login failures?

[Damien Miller]

Jay Libove wrote:
> Actually, this makes me suggest yet another feature - a deliberate delay
> before even the FIRST interactive login password prompt, in addition to
> exponential backoff thereafter.  

And this suggests another workaround for an attacker: speculatively open
multiple parallel connections ahead of time to be used once they pass
the initial delay.

Attackers can trivially work around most of these delay-based
techniques and it usually results in more server invocations. You might
have more luck playing with sshd_config's MaxStartups or implementing
restrictions at the TCP layer, e.g. rate-limiting connections. Again,
you need to be careful here too - it is easy to make it easy for an
attacker to DoS you out of your own system (though MaxStartups can be
tuned to reduce this risk).

> I am very open to other suggestions on how I can at once
> 1. allow myself to SSH in using a password from unpredictable locations,

Use s/key for this (this is exactly what it is intended for) or revive
one of the pubkey-before-password patches.

> 2. slow down anyone who would try to brute force (or even just run
> through a few hundred
> already-found-elsewhere-but-not-existing-on-my-machine user ID and
> password combinations)

Extra complexity in ssh won't save you if your passwords suck to begin
with, so either 1) don't use passwords or 2) enforce complexity
restrictions when the passwords are created or changed.

I don't believe that it is sshd's role to compensate for bad basic
management elsewhere.

-d