17

My company requires that any time a user logs into a production server the reason that person logged in and the changes the user intends to make must be logged. My team wants to do this, but its easy to forget. I'd like to help them remember. I considered an motd, but want something a little stronger.

My first thought was to change the user's shell to a script that does something like

vim /logs/logindate.txt 
bash -l

Is there a better or more standard technique?

Note: The idea is that these users are sysadmins and would like to make the log entry without subverting the system- they just frequently forget to do so. So, if they can ctrl-c it, well...we're assuming they won't.

5 Answers5

19

Look at pam_exec.so. You can run a script on login in the session interface of PAM's system-auth. The script runs as root before the user gets a shell, so it may not capture input with read? You can try, though, and use read to get a reason from the user and log it to syslog with a logger statement. (I've omitted below, but you can trap CTRL+C to prevent anyone from exiting without reason.) $PAM_USER will be set to the person logging in, so you can include that in the logger statement.

Example:

At the top of session in /etc/pam.d/system-auth:

session required pam_exec.so /usr/local/sbin/getreason

And /usr/local/sbin/getreason:

#!/bin/bash
read -p "Reason for logging into production: " reason
logger -t $(basename $0) "$PAM_USER logged in with reason: ${reason}"

Apologies if this doesn't work perfectly. I did not test it, but have recently done something similar. (It did not capture input.)

Edit: The more I think about this, the more I don't think it will work because of the stage in which it runs. The same getreason script should work after you replace $PAM_USER with $(logname), but it may need to be executed in /etc/profile. (Test for interactive shell, first.)

I'll leave both options up since it should at least get you thinking in the right direction if nothing else.

Aaron Copley
  • 12,954
7

The alternative is a privileged account management solution, where rather than giving administrators access with their own account, admin accounts are held in escrow by a third party and the mandatory procedures Have to be followed before administrators can access production systems http://en.m.wikipedia.org/wiki/Privileged_Identity_Management

HBruijn
  • 84,206
  • 24
  • 145
  • 224
0

Another way to accomplish this would be to have your centralized-logging facility (I'm thinking Logstash, but you can do this in other ways) take your auth.log on production systems, feed that into an app where people can log their justifications.

gWaldo
  • 12,027
0

The way I've seen this implemented at customers who run HP Server Automation* is that they rely on the tool's innate logging with a combination of approval steps (I've been to several customers where there are no sudo or root privs except in Dev).

Approvals can be done via something like Remedy and Operations Orchestration, or administrative login inside SA, etc.

That all being said, outside of enterprise automation and management tools, @Aaron Copley's answer is an excellent choice.

* I am a senior HPSA, HPOO, and other aspects of the HP automation suite consultant

Community
  • 1
warren
  • 19,297
0

While looking for a solution, I read Aaron Copley's answer and thought: "What if I change my user's shell?"

I did it successfully on my Ubuntu 14.04 machine:

# usermod -s /usr/bin/loginScript username

On your script you can capture the login's reason simply. Mine is like this:

#!/bin/bash
read -p "Tell me why you logged in:" reason
echo "You told me: $reason" >> /var/log/reasonLogin.log
/bin/bash

One thing you should note: the script is not run as root, so you may have to give the user some permissions to make this work.

William Monteiro
  • 9