More or less -- the PermitRootLogin without-password directive will disable password authentication for root. The strategy I would follow, then, is to allow Pubkey Authentication and disable all other authentication types in sshd_config. NB: if you leave ChallengeResponseAuthentication enabled, root can still login with his password, so be careful.

I'm not suggesting that you skimp on a layered security approach, BTW. Packet filtering rules, et al, still have their place in this strategy.

Thanks - for this last bit and for all the earlier discussion/advice too!

Portknocking may be another useful layer: http://www.portknocking.org/

Having said that, I have to say (call me cranky), that I never get threads like this. I'm racking my brain, but I can't think of a reason that it would be impossible to login as <insert_user_name_here> and then su to get root privileges. You can feel free to ignore this, obviously enough, but I'm genuinely curious: what situation would forbid the creation of a regular user?

Then again, I'm paranoid: I don't even let regular users log directly in via their password.

If you log in manually to the servers, then log in as your regular account and use "su" or "sudo". Use public key authentication, and have a strong passphrase. You can use ssh-agent & ssh-add so that you only need to enter in the passphrase once.

Also consider changing the port number that the ssh server uses. This will reduce the number of script kiddie brute force attempts. Then more serious (failed) attempts will probably stand out better in the logs.

If only a handful of people log in to ssh, a good method of control is to use "AllowUsers" which will disallow attempts to login against system accounts or common user names.

Also disable password based authentication so it isn't a fallback. If an allowed user has a week password, this could lead to a cracker getting into the system and start trying to gain root access.

Also, remember the Debian ssl mistake. A public key produced on a Debian or Ubuntu system in that 2 year time period will be in a set of only 32,000 keys. You may want to download this list of bad keys and check this list against the authorized_keys list.

A public key entry in authorized_keys can contain a field with a comma separated host= list of hosts that a user is allowed to connect to using that key. This can help protect against the possibility of a lost key. Also, you could restrict ssh logins to certain networks this way as well.

For me it's a combination of things.

If I really must allow remote root login, then I:

1.- use dsa keypairs and forbid pam authentication, and
2.- change the port to something less evident, and
3.- setup iptables, and
4.- setup fail2ban, and
5.- change root keypairs often, the more often, the higher security

This is really hard to beat. An attacker can't use the root password via ssh if you disable pam, and the ssh key pair can't be guessed either if you change it because fail2ban will allow the attacker only a few attempts before banning it.

Besides this, you can also prepare a honey pot on a chroot and all sort of funny things.

Sorry about the slow reply to this one Telemachos; I just got back from vacation.

The main reason is that I inherited a collection of systems that have a lot of their administrative functions all done automatically via a script that runs from a single machine. User addition, for instance, is done by a script on one machine which adds the user into all of the machines in it's group. (That doesn't mean there isn't a better way to do it though.)

wn