|
From: Kevin Z. <kev...@gm...> - 2015-05-14 16:32:35
|
On 05/11/2015 12:06, Laurence Perkins (OE) wrote: > The CPU penalty comes primarily from doing all the calculations to set up the > encrypted channel and secondarily from hashing the password for verification. > (The order of those two subject to change depending on encryption settings) > Setting SSH to block certain usernames eliminates the latter, but you still have > the first one. On my old C3 machine (roughly equivalent power to a Raspberry Pi) > setting up the encrypted channel took it about 2-3 seconds. (I like large keys) > I started using SSHguard because the rapid-fire login attempts were redlining my > CPU and making the machine more-or-less useless (except, maybe, as a toaster...) Makes sense; this is one of the things SSHGuard was designed to prevent. >> Having the option of scoring certain usernames as high danger attempts, >> or perhaps as danger 1+fractional multipliers, could be a clean way to >> implement such a feature. > > I hadn't thought of doing it that way, but that would likely be more useful as you could > use it to set up multiple, different levels of paranoia for different users. Especially > if you can use a fractional multiplier to effectively raise the threshold for guest accounts > and the like. How would this work? Raise the danger of the attack so that two attempted logins with 'root' or similar usernames would be blocked? How would SSHGuard know which usernames to do this for? Would it be built into the binary, or added as a configuration at run-time? (With your use case, why not just lower the blocking threshold?) Thanks, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |