Some semi-serious sysadmin scholastic statements

Asked by my friend Ardian, I’m writing these tips for sysadmin-wannabes hoping that it will be useful.

Securing SSH

SSH is one of the best friends of any sysadmin (because everybody knows that sysadmins don’t have real friends). Because SSH is one of our true few friends, we need to make sure that it stays our friend and to do that we have to defend it.
Here are some ways to achieve that:

Security through obscurity

It is a general consensus that securing something through obscurity is not a good idea. Security through obscurity is not real security, but sometimes it helps stop annoying script kiddies. You can’t make your whole security scheme rely on people not knowing your secret, particularly when the secret is easily discovered.
I’m talking here about moving your SSH port to something different than 22 (which is the default port). It’s very easy to find out which ports are open in a server (you just need to use nmap), but there are people who don’t know that and have automated scripts constantly trying to gain access through that port. Usually higher ports is a good idea.
Just don’t rely on this as your only means of securing SSH.

Hello, Mr. John Doe

Don’t let users with very common usernames have SSH access. Particularly, don’t let root have SSH access. Other usernames that shouldn’t be allowed are admin, superadmin, backup, cron, etc. Automated attempts to gain access use dictionaries of common users, so it’s better if we don’t give them a chance to guess what users we have in the system.

Stop knocking at my door!

If we receive many failed login attempts from the same IP, then that person probably isn’t someone with a valid password. There are many ways to tell that person to get off: IPTables rules, fail2ban, denyhosts, etc. Some people may even prefer their own solutions, but having these available, that’s probably not necessary.
The idea is that if a user keeps trying to gain access to our server, we can lock them out for a certain period of time.


Sometimes we have users that connect always from the same host. The host can then be specified in the sshd configuration file so that user can’t connect from anywhere else. In that way, we close the door to yet another possible intruder trying to spoof our user from some other location.

Password? What password?

Relying on passwords might not be a great idea because passwords can be weak (although that can be solved with PAM magic, which I may talk about at a different time). Generating SSH keys and disabling password authentication is usually a good idea. SSH keys are unique (unless you use certain versions of Debian…).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: