Neal Murphy wrote:
The point is to reduce brute-forace attacks to the point of nearly total ineffectiveness.
I use OpenSSH public/private key authentication to achieve this. Based on needs one could also use two factor authentication (e.g. one time password tokens) or even a combination of methods. These are standard tools you can use to defeat the "weak" password solution. It is always better to eliminate problems at their root, which in that case are accounts with weak passwords.
The point is to obscure the ssh server from everyone, including those who are authorized to access it remotely.
I only see you add an obscuring (and encrypting) shield around your service. I'd say that implementing such a "complex" solution will bring more problems than it will solve (another layer to debug ;) ). I would rather go the KISS way: key auth, non standard ports, fail2ban. As an admin I would rather stick with a hardened SSH gateway, using strong authentication and "end user education", than adding an UDP layer. Another example: We have to run a CVS server that is reachable from the outside, so that some external devs can upload their changes. I got two SSH instances running on that box, one on port 22 that is only reachable from our internal network and one on a non standard port reachable worldwide. The worldwide SSH only accepts logins for a certain group of CVS users, key authentication is enforced and a restricted shell is used that only allows CVS. Up to now (running for approx one year) no automated SSH attack was logged on the non standard port. Full port scans with service identification are seldom and if so, indicate a more detemined attacker. Regards, Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
