The correct way to address this is not to rely on fail2ban or start moving ports around (although these will remove noise from your logs, they shouldn't be solely relied upon) but to use public key authentication. It's not hard to set up and once you disable password authentication support on OpenSSH then the scans can try all they like, but they're not getting anywhere.
A botnet found one of my computers. Most likely through IRC. They have been trying relentlessly to get my computer added.
They have no chance of getting in - using public key authentication - but it still takes quite a toll on my network speed.
That said, I have a file containing about 366 IPs belonging to this botnet, as well as a half-meg file containing nmap scans of all these IPs. What should I do with it?
With the places you access the computer from do you use dynamic or static IP addresses?
If they're all static IP addresses, try to block everything on port 22 except for your static IPs.
If it's dynamic you should have a pool address block, you can add the block in but there's a risk that if your block is in an ISPs home user pool that the botnet could infect people in your block.
If you can't use upstream filtering then I'd suggest you configure a firewall to do the same thing, either in hardware (preferable) or software.
I have a somewhat unique situation which I think stops me from using this.
I access my servers from a shared (Windows) computer. I trust the other users enough not to install keyloggers, but not enough to put the private keys on the computer.
From some experimentation with putty, I can't find a reasonable workflow that lets me save the server configs, but prompts for the private key every time I log in, so I can load them (from a USB key for eg).
The best thing I've come up with is using long random, machine generated passwords with a password manager.
If you password protect the keys it's essentially the same at your end as if you were using a password. The only difference being that they need to copy the keys if after compromising the password they want to log on elsewhere.
http://wiki.centos.org/HowTos/Network/SecuringSSH