Systems such as port knocking are based around the idea that sshd might somehow fail. If you make that assumption then it’s best not to have sshd be part of the solution.

Olad@12: Yes. But in many cases this is an acceptable trade-off.

And get locked out of your own server if for whatever reason you get assigned an address out of this range?

Hmm, wouldn’t that allow me to deny *you* access to your own server if I knew your IP address (and are able to spoof it)?
All additional security issues are kinda nice, but what’s really needed is a good default configuration. Most administrators and users will not apply additional security measures.

Port knocking is effectively just a shared secret. Can’t the SSH protocol be improved to incorporate something like that?

And thanks for mentioning randomsound. I’m running audio-entropyd on one of my machines and have had good experiences with it:

http://www.vanheusden.com/aed/

I’m using a dynamic ip, too, and bypassed the problem restarting the connection at some hour during the night, if hosts.deny reached a certain number of entry (well, one could do it every night regardless hosts.deny…): after changing ip I can safely wipe hosts.deny and all added iptables rules

obviously portsentry cannot block brute force attack to the port 22, so you should move ssh to some other port in order to make it useful in this sense

on a static ip, I don’t think portsentry could be a valuable solution: one could scan a certain number of ports before being blocked, then change ip and restart scanning, or one could sniff some traffic and see which ports are used

regards
tindal