Right, so if I can only SSH into my box by having the appropriate RSA keys configured, is there any point in using Denyhosts for SSH as well? Or is Denyhosts only looking at keyboard-interactive / password logins for SSH?
Don't get me wrong, Denyhosts is the absolute mac-daddy, but I've recently switched off keyboard-interactive logins altogether and wondered if it was worth still keeping Denyhosts running.
(If you don't know Denyhosts, it basically maintains - and uses - an IP blacklist of people who keep trying to get into SSH but with the wrong username / password etc.)
By my read of it, there are two reasons to continue using DenyHosts:
If either of those don't really matter to you, then DenyHosts isn't doing anything for you.
It minimizes the "bad actor/person" from slamming additional resources.
Depends on the other services running on that box. If it's a webserver with an online store, you might be losing business because of an incorrectly denied host - though this seems unlikely, especially if you're only using your own denyhost data.
On the other hand, if you're running other services that might be less secure than your locked down ssh server - it may be worth keeping the deny to protect your other services if the attacker tires of your ssh, or indeed if you ARE using shared data.
Long and the short, if you have no worry about false positives (eg. the people who might fail to access the server have another way to contact you, and it won't harm any relationship with them!) then there's no reason not to keep denying hosts. Also its fun ;)
To add to the other answers, there is one word of caution I have encountered (in the form of a notice on the ArchWiki) when reading about tools like denyhosts (e.g. Fail2ban):
So especially if you're only allowing public-key authentication it may be worth considering just using a non-standard port (to avoid blind attacks on port 22) and intentionally not using denyhosts.