The only way to prevent a bruteforce attack is to count the number of login attempts and ban the user after so many, how ever this becomes cumbersome when a user has legitimately forgotten their password and therefore is forced to go through an entire password recovery process. Sometimes, I'll set the number somewhat high so I can avoid this ( like 10 attempts ).
The connection is closed by their IP because they're the ones trying to connect. And on failure they'll close the connection and retry a login.
Regarding what I said before, I see now it's shell access, so I would suggest simply doubling up the complexity of your password ( an un-caged ssh password should be complex already but just to make sure ) and banning that IP
It's a bruteforce attack, they are running the attack from a server hosted on http://www.rapidswitch.com/ ... contact them explain what has happened and give them the log information you have and I'm sure their they will disable this idiots server.
As for the attacks is this a hosted server or your own personal machine?
If it is your own machine you could just simple disable remote access to the shell if it is your own machine.
If it is a hosted server my recommendations are to disable access to the root login if it is not already done so until this is handled and update passwords for any users with access to any vulnerable areas.
Thanks for your response everyone. I was quite nervous about this yesterday.
I have a complex password and always disable direct root access. On all my boxes, home & dedicated. Some people have recommended changing the ssh port, is this worth it?
I found out it is one of RapidSwitch's monitoring servers, so I have now unblocked it from my firewall. They should publish this information to their clients so we know to ignore anything from their IPs.
While looking through my secure logs I have noticed an other IP which seems to be going to town with quite a few attempts at logging in per minute, and I have confirmed with RapidSwitch it is not any of theirs - so I might post back a bit of the log file, as the log file show something slightly different in reference to their log in attemp.