Tag Archives: Root

Email alerts whenever someone logs into root via SSH

Want to be notified instantly when someone logs into your server as root? No problem. there was recently a discussion over on the vps.net forums after an incident where a user had had several of there servers logged into as root by an unknown source (since resolved) a helpful user (R4Z0R49) posted this helpful guide and I have cleaned it up and added some further notes and caveats.

While I wouldn’t recommend allowing root logins over SSH and prefer to setup non root accounts with sudo access, sometimes for one reason or another, root over ssh is needed. This guide should also log su logins to root as well, because by using su you login to that users enviroment and it loads the users environment which then calls the same file that loads stuff like variables and paths when you login over ssh so you should also get an email in this instance too.

Check out this nice tutorial on email notification for root logins. Keeping track of who logs into your server and when is very important, especially when you’re dealing with the super user account. We recommend that you use an email address not hosted on the server your sending the alert from.

To carry out this tutorial you need to have root level access to your server in some form or another, I assume you have already logged in as root or otherwise escalated your privileges to root level, I will also assume you use the nano text editor, feel free to use any other editor you are comfortable with such as vi or otherwise.

It is recommended to have mailx installed to send the emails, depending on your system you can install it with either one of the following commands on debian/ubuntu (apt) or centos(yum) systems respectively.

apt-get install mailx
yum install mailx

Now we need to make sure we are in root’s home directory (this should be the same on all linux systems)

cd /root

We now want to edit the .bashrc file to add some code to do the emailing this file is the environment file and pretty much all servers use bash for the root user by default. This file will set local environment variables for the user and can also perform some other cool login tasks like we are going to do below – NOTE: .bashrc is a hidden file so you wont normally see this by doing a normal ls command in this directory, if you want to see it on ls you need to use the -a flag to view all files.

nano .bashrc

At the bottom of the file we want to add the following line, replacing YourserverName with a suitable name for your server (I find the system hostname is often the easiest to distinguish particularly if you have several servers) and change [email protected] to a suitable email address – I would recommend using an email address not hosted on the server as it could be intercepted by someone if they were aware of such a system being in place (now is a great time to use google apps!)

echo 'ALERT - Root Shell Access (YourserverName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" [email protected]

Save and exit the file by pressing Crtl + X and then Y, then hitting Enter

Now logout of SSH, close the connection and log back in! You should receive an email address of the root login alert a few minutes afterwards.


You can do this for any user you want to get email alerts on login for, assuming they are assigned the bash shell then edit there .bashrc file which should be found in /home/username/.bashrc.

If you want to do this for all users you have 2 options. either edit /etc/profile instead of .bashrc or install CSF & LFD and set it up as it has an SSH and SU login detection system that will email upon login without having to make these profile changes. I shall put up a post on how to install and setup CSF & LFD in a further blog post.

SSH Root Security Tips

ok so i thought i would shove a quick techy thing up while its fresh in my head. this post i think is great when you are in an environment where you have to compromise on security and ease of use. I have to admit though, this tip is not my own i read this originally on Jordan Bedwell’s (Envygeeks) site however the site no longer seems to be available and i havent yet found it anywhere else. So i am posting this up for all to benefit as far as i am aware Jordan should recieve credit for it – feel free to correct me if i am wrong.

This article follows the logic that normal users will want to use a password and do not use keys. The truth is folks, most Engineers and Admins have to put up with people who don’t understand key based authentication, and it’s our job to come up with creative ways to secure the server while not being obtrusive to their lives.

Recently we had a spur of clients ask us to enable root for them. Mostly because we don’t allow our clients to root into most of our dedicated servers, we force clients to login as a normal user and then sudo -i into root (root login is completely disabled, no password so no ability to login ~ no su). The problem was, even though we had fail2ban, this would not stop a large bot-net attack as fast as they could cycle, unless we got really strict, which we can’t because of a catch 22. Either be real strict and have to deal with abnormal amount of requests that we could not cover feasibly while keeping up our goal of being efficient or reduce security a tiny bit and come up with a user-name that would be as hard to guess as the password making it twice as hard to haxor up our stuff. The problem here is, as we saw more and more root requests come in and we rejected more and more unlocking (we always tell them they can enable it themselves but we will not cover it ~ if our investigation concludes a brute force into root) we started to take this as a challenge. Not really since we already knew how to do it.

The truth

We are not any different than your host, we generally deny any other way for the sake of sanity. Not really, we are very creative, we just like to keep things uniform too. The truth is, most hosting companies tell you it’s insecure to enable root, and they are right, and wrong. The problem is, we are not a hosting company, we are the company that teaches the engineers at the hosting company how to do their job and does their job when they fail to hard to do it. The real truth is enabling Root is only as secure as you make it and most engineers and admins or at least most that know how to do their job, know ways to enable root while keeping it rather secure from brute force attacks.

The How-To and FixThe dirty dirty, most of you already know it, add a key to root, and then switch the PermitRootLogin, now, before you talk, go on and say what you’re going to say, and then shut up and listen closely. We will not use yes or no for this variable. We will actually use a different value. Lets look at our decked out SSH_CONFIG and see if you can figure it out:

Port 22
ListenAddress IP.GO.HE.RE
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 8192
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 30
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
KerberosAuthentication no
KerberosTicketCleanup yes
GSSAPIAuthentication no
GSSAPICleanupCredentials yes
X11Forwarding no
X11DisplayOffset 0
PrintMotd no
PrintLastLog no
TCPKeepAlive yes
MaxStartups 1:5:10
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

That’s right boys and girls, we simply change PermitRootLogin to without-password and boom, we can now only login using our key. The good part about this is too, a flaw by design is it still shows a password dialog which can be a nice little trap for idiots who try to brute force into the server or idiots who just want to try and see if they can “guess” the password so they’ll still be caught by fail2ban but will never be able to get in, because interactive passwords have been disabled, unless they magically get in and add their key to root. Go on now, start generating your 8K RSA keys and enabling root only by key login.