On 18/01/2016 12:08 AM, "Christian Seiler" <christian@iwakd.de> wrote:
>
> On 01/16/2016 10:57 AM, Reco wrote:
> > - anyone can connect up to 16 times via ssh.
> > - anyone exceeding the connection limit is tarpitted, and must wait
> > for an hour to try again.
>
> Note that while this may be adequate for your use case, I would
> caution that 16 connections / hour can easily (!) be exceeded
> by regular SSH usage.
>
> If you have pubkey authentication (with an agent that remembers
> the key's passphrase) and have command line completion on the
> shell that also works with SSH, tabbing through scp options can
> easily produce more than 16 new SSH connections within a few
> minutes only.
>
> Example:
>
> scp host:/srv/d<TAB>
> scp host:/srv/data/w<TAB>
> scp host:/srv/data/website/ex<TAB>
> scp host:/srv/data/website/example.com/...
> (you get the picture)
>
> On my system with something like that I got more than 5 new
> SSH connections within just a few seconds - and while most
> shell completion implementations cache this data to a certain
> extent, 16 / hour seems really low for such a use case.
>
Or just use multiplexing and not worry about it
https://en.m.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing
> Also, if you use modern desktop environments (e.g. GNOME, KDE),
> they can directly access e.g. SFTP from many programs (such as
> text editors etc.) - but those may close connections when they
> are idle for a time and re-open them - so directly editing a
> file via SFTP from a program might lead to a LOT of new SSH
> connections over the course of a short period of time.
>
> As I said: for your use case this might not be relevant, so I
> don't want to say that the solution presented here is wrong,
> it will be perfectly fine for a good many situations; I just
> wanted to illustrate that there are legitimate use cases where
> it is possible to exceed that limit easily. Obviously, you
> could increase the limit by a bit - because even if you allow
> let's say 10000 connections per hour and IP, that would still
> make brute force rather difficult... OTOH, I haven't put any
> thought into the best trade-off between security and usability
> here, and I just made up the number 10000, so please don't
> just use that number unconditionally either.
>
> Regards,
> Christian
>