Give Me Strength

A common error I often describe to junior sys admins (and one that I still somehow manage to make every few months) is being trigger happy and entering a password into the command line by accident.

As I have just discussed, Bash, in all its prescience, wisely accommodates the ability to directly edit the .bash_history file in your favorite editor and remove this password (which, for example, could be as sensitive as a root password if entered near to an su - command).

You might be wondering if you can configure the Bash history to ignore commands that match a given pattern. As you might expect, the answer is a resounding "yes."

For example, I prefer to have the Bash history ignore any command I enter with a space at the start. (Note: Ignoring a command in the Bash history should not be confused with ignoring it for execution.) Simply add the following to your ~/.bashrc file. The space might be a little confusing, but you can replace it with any character within reason.

export HISTIGNORE="[ ]*"

This entry ensures that any command prepended with a space will not be written to Bash history. I tend to use this feature when a remote service (that's not especially sensitive) requires a password on the command line. For example, you might be pulling a web page down to a server that is password protected at the other end of the connection:

wget --user=chris -password=nastyplain \
  texthttp://domainname.com/page.php

By the way, if you are executing this command interactively, a better option is to use the -ask-password switch rather than -password. -ask-password will let you enter the password through a prompt, so it isn't stored on the command line.

Save for Later

Suppose you are at a point in a Bash session where you might want to compose a command to use later in the session. Can you enter a command at the command prompt just to save it in the history for later – without executing it? Yes, and actually, this trick doesn't require any config options at all.

Simply prepend your commands with a hash symbol # to stop Bash from executing the command. Flick the cursor arrows up later on and delete the hash symbol in order to execute the command.

Profile Style

According to the header, the /etc/profile file is a "system-wide .profile file for the Bourne shell (sh(1)) and Bourne compatible shells (bash(1), ksh(1), ash(1), …)."

It's never a bad thing to have additional login information from your servers. That might resonate more strongly with sys admins who have (tried to) recover compromised systems in the past. Further information is very welcome, as long as it doesn't fill up your disks to the breaking point with inordinate number of sizeable log files.

I've been responsible for servers that only have one or two users logging in periodically, and I find it useful to have an idea when customers or colleagues are using those servers. It might mean, for example, that after I've seen a particular user login, I know to expect high server load for an hour afterwards, as they always run the same application shortly after logging in.

Assuming you're not going to cause your servers to suffer a denial of service due to countless logins, if you carefully append this config entry to the bottom of your /etc/profile file, you should be able to generate a useful email at each login:

(who -m |awk -v q="$(date +"%k:%M:%S %Z on %e %B")" \
  '{print "User " $1 " logged in at " q " from IP "$5 }' | \
  mail -s "Logged user on $(uname -n)" chris@binnie.tld &)

Obviously, your server needs to have an MTA like Postfix installed (or a conduit such as ssmtp forwarding mails to a relay) to understand the mail part of the command.

I like this command for two reasons: First, all the auditing is by mail, which means I don't need to check a Syslog server but, instead, I get told via an Unread E-mail label about a login event, even when I'm not near a terminal.

Second – and trust me when I say that I appreciate that this is far from a rock-solid security practice – if I'm one of just a few people logging into a server, an email alert after a login can tell me pretty quickly if someone is logging in illegally.

Clearly, it is possible to gain access to a server without spawning a shell that calls the file /etc/profile, but at least an additional level of access is logged, and, importantly, it is logged away from your server (remotely, in your email inbox), so should that server be compromised, you can check on the IP address that triggered an alert even if the logs are tampered with or deleted.