Secure existing OpenSSH installation
July 13, 2009 4:20 AM Subscribe
Secure existing OpenSSH installation This post provides you with the instructions how to make your OpenSSH daemon secure and usable as possible.
This post was deleted for the following reason: Same user posting this link on digg and redditt. Possible self-link. Weak anyways. -- vacapinta
Why wait for three unsuccessful logins? I like denyhosts, which preemptively bans known bad IP addresses using a shared list.
posted by caution live frogs at 4:36 AM on July 13, 2009
posted by caution live frogs at 4:36 AM on July 13, 2009
Um. As much as I appreciate this and just bookmarked it for later reading... why is this FPP material, exactly?
posted by rokusan at 4:36 AM on July 13, 2009 [1 favorite]
posted by rokusan at 4:36 AM on July 13, 2009 [1 favorite]
denyhosts is working fantastically here, and as a bonus, it doesn't mess with your firewall like fail2ban did (back when fail2ban actually worked, that is). Instead, denyhosts uses /etc/hosts.deny, which sshd reads directly on its own without going through inetd/tcpd.
posted by SteelyDuran at 4:36 AM on July 13, 2009
posted by SteelyDuran at 4:36 AM on July 13, 2009
denyhosts is great, but disabling password authentication is a must as well. In that regard, the article misses one configuration directive:
UsePAM no
posted by DreamerFi at 4:47 AM on July 13, 2009
UsePAM no
posted by DreamerFi at 4:47 AM on July 13, 2009
Once you've got the ssh key authentication working, it's best to just disable password authentication altogether. What I do on my machines is this:
PermitRootLogin no
PasswordAuthentication no
You'll sometimes see brute force attempts against ssh demons on the net. It's just sort of the way of things. If you don't even allow password authentication, you're largely (completely?) immune, even if a user or service account on your system has a weak password.
Disabling root login means you need a user account on the machine to log into, and then you can su to root to do maintenance. To break into the machine, an attacker would need A) the SSH private key and the passphrase that unlocks it, plus B) the password on the remote machine. The only way that's likely to be compromised is if SSH itself has a hole, or if your local box gets hacked.
There's no such thing as perfect security, but this is fairly robust, if you watch your installation carefully. If you're paranoid, run Linux on your management machine. If you're SUPER paranoid, run Linux from a USB key that you carry with you, and keep it write-protected most of the time. As lesser protection, you can store just the keys on USB, but that doesn't protect against trojaned binaries. I've seen that recently on a hacked Windows box.... a replaced SSH client. Sticking Putty and your keys on a USB stick will protect against trojans, but of course will do nothing about a keylogger.
Oh, one final note: the MaxStartups setting in the article will indeed slow down brute-force attempts, but if you're under heavy attack, it may also prevent YOU from logging into the box.
posted by Malor at 4:50 AM on July 13, 2009
PermitRootLogin no
PasswordAuthentication no
You'll sometimes see brute force attempts against ssh demons on the net. It's just sort of the way of things. If you don't even allow password authentication, you're largely (completely?) immune, even if a user or service account on your system has a weak password.
Disabling root login means you need a user account on the machine to log into, and then you can su to root to do maintenance. To break into the machine, an attacker would need A) the SSH private key and the passphrase that unlocks it, plus B) the password on the remote machine. The only way that's likely to be compromised is if SSH itself has a hole, or if your local box gets hacked.
There's no such thing as perfect security, but this is fairly robust, if you watch your installation carefully. If you're paranoid, run Linux on your management machine. If you're SUPER paranoid, run Linux from a USB key that you carry with you, and keep it write-protected most of the time. As lesser protection, you can store just the keys on USB, but that doesn't protect against trojaned binaries. I've seen that recently on a hacked Windows box.... a replaced SSH client. Sticking Putty and your keys on a USB stick will protect against trojans, but of course will do nothing about a keylogger.
Oh, one final note: the MaxStartups setting in the article will indeed slow down brute-force attempts, but if you're under heavy attack, it may also prevent YOU from logging into the box.
posted by Malor at 4:50 AM on July 13, 2009
DreamerFi, PAM does a lot of work on a Linux box, like setting user limits and other environment variables, and denying it altogether is probably not a very good idea. PasswordAuthentication No should do the same thing, without giving up the other benefits of PAM.
posted by Malor at 4:52 AM on July 13, 2009
posted by Malor at 4:52 AM on July 13, 2009
« Older To sleep, perchance to dream | Land, Eagle, Land Newer »
This thread has been archived and is closed to new comments
Personally I prefer port knocking to avoid port scans. That plus public key for root or no login for root and use of sudo for the non-obviously named user account seems easily enough IMO.
posted by jaduncan at 4:32 AM on July 13, 2009