Live data from Hacker News

Bug in widely used OpenSSH opens servers to password cracking

arstechnica.com

61–62 of 62 posts

Re: Bug in widely used OpenSSH opens servers to password cracking

#61

Some quick tips for securing SSH: 1. Disable password authentication altogether 2. Create and use keypairs 3. Add an "AllowUsers foo" line to /etc/ssh/sshd_config so that only your user is allowed to SSH 4. Install sshguard or fail2ban and set the ban limit to a week There are other things you can do, but I find this to be the lowest hanging fruit for the best security.

I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.

The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being checked into.

Re: Bug in widely used OpenSSH opens servers to password cracking

#62

Earlier quoted context omitted.

I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.

The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being check…

I would say auditability is still security-related, but yes, this is good practice too. You should probably also make sure root has a locked password, so that things other than SSH won't allow root login.
Post reply on HN