On 18/01/2016 12:08 AM, "Christian Seiler" <christ...@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 >
