hello.
if the passwords are as weak as roland's seems to be the 'PermitRootLogin no'-option is only a little barrier. instead of one pw the attacker has to get two passwords.
use the mentioned public-key authentification, only protocol 2 and (if possible) use a non-standard port for ssh (many scripts only check for 22).
I allow root logins on some machines, I don't think that's a great problem.
Howewver, I do not allow root to login with a password, and in some cases nobody can get in using a password.
Instead, I create a key with ssh-keygen and distribute the public key to machines where I need to login.
Mostly, I use sudo (not su) to administer machines, and I configure sudo to require the user's password.
My own password is reasonably long, easy to remember and in no dictionary.
At work I've tried using a password generator for users' passwords. It's a nice idea. but the staff are completely unable to cope with them. In practice, either I need to know them too or I forever need to reset them.
One thing I learned after one user's account was cracked (I didn't assign that password) is to have incoming ssh on a box that doesn't host mail and other user services. If someone uses (assuming it's possible) ftp, email or http to enumerate users, the users they find mostly don't have user accounts on the machine running sshd.
Users not having login rights have /bin/true, /bin/false, /bin/nologin or similar for their login shell.
I personally don't see the merit on changing the ssh port; if it's configured sensibly that gains inconvenience, nothing else.
--
Cheers John
-- spambait 1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
