Raising Elephants…

I wrote this post to continue with the sysadmining series asked by Ardian.

Sometimes I need cron scripts to email me the result of something and configuring sendmail or postfix to do that seems a little like killing a mosquito with a bazooka (it works, but it’s not very efficient).

So, what I do is use msmtp.

msmtp is very easy to use and configure. Just write a config file for it (.msmtprc in your $HOME) and make it point to the GMail smtp server.
Something like this works:

defaults
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt

account default
host smtp.gmail.com
port 587
auth on
user user_name@gmail.com
password H3Re_Goes_Y0ur_p@ssword

Then you $ chmod 600 ~/.msmtprc

And that’s pretty much it. Then to send an email what you do is pipe the mail to msmtp with the address of the person you want to email.

Something like this:

echo -e "Subject:test\nTo:foo@bar.com\nhello world" | msmtp foo@bar.com


That command would send an email to foo@bar.com with the subject “test” and the body “hello world”
The “Subject” and “To” fields are optional, but it’s nice to include them. The \n are new lines.

You can also make a text file and cat it and redirect the output with pipes.
More information for the email could be included, like the text encoding used, etc, but for the stuff I need to email, a subject and a body is usually more than enough.

Disclaimer: I don’t like using GMail (the default interface has a JavaScript trap, I don’t trust Google with my personal data, etc), but GMail (through Google Apps) is the mail server of choice at work. Using msmtp doesn’t mean you HAVE TO use GMail. I only put it as an example because it’s what we use at work. As a matter of fact, you’re better off NOT using GMail at all and using some other email provider that doesn’t spy on you and that respects your freedom.

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.

Leo@Vinci

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…).