7

I often have multiple sessions running at any given time. This sometimes leads to issues when trying to reconstruct work using history. As a result, I was thinking it would be useful to include the $BASHPID somehow so that I could sort by shell and then time. My naive attempt at this was to try

export HISTTIMEFORMAT="$BASHPID %Y %m %d - %H:%M:%S| "

But all this does is add the current shell's $BASHPID to the output of 'history'.

A search for HISTTIMEFORMAT and $BASHPID returned nothing. ANy suggestions on how to get this kind of behavior?

7
  • How about adding tty? Commented Jul 3, 2017 at 20:59
  • @RuiFRibeiro could you be more explicit? Commented Jul 3, 2017 at 21:03
  • if running multiple windows in a graphical shell, tty is also useful to keep an idea of what is done in several screens; or to keep a notion of what is being done by different remote users when root is being (ab)used. man tty Commented Jul 3, 2017 at 21:09
  • @RuiFRibeiro Yes, but I don't see how that information can be stored in the .bash_history file. Commented Jul 3, 2017 at 21:27
  • Indeed, the more I understand the more I think I'll have to have multiple history files (one for each BASHPID 'cause that's more granular than tty) and then somehow process them together to make the default .bash_history file. Commented Jul 3, 2017 at 21:27

2 Answers 2

6

You need something like "bash eternal history".
There is a good description in here to get it working.

That solution is still lacking the PID, which could be added with the ideas from here.

Mainly:

export HISTTIMEFORMAT="%s "
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"' \
               echo $$ $USER "$(history 1)" >> ~/.bash_eternal_history'

Which is using the $PROMPT_COMMAND to generate a:

$PID $USER $LAST_COMMAND

output per command executed.

5

My strategy is to add to /etc/bash.bashrc the following line:

readonly PROMPT_COMMAND='history -a >(logger -t "cmdline $USER[$PWD] $SSH_TTY $SSH_CONNECTION")'

Then in /etc/rsyslog.conf:

*.* @syslogserver:514

I prefer this approach than logging to a single file, as:

  • files are rotated (i.e. do not grow too much)
  • the user is not able to delete his "history"
  • it creates a remote log trail resistant to tampering/hacking of a server
  • The rotation log in the remote syslog server can be changed to keep some months of logging
  • syslog-ng allows you to have separe file logs per logging IP address
  • it is all in a central point, and you do not need to be entering multiple servers to understand what is happening
  • when the remote bash session is aborted, the local history is lost, and it is not lost with this method
  • also when several sessions are opened by the same user, once again all the commands do not get in history, and I get them with this method.
6
  • Thanks for the help. I understand now that the process substitution >(…) is treated as the filename used to append the history to, thus: storing it. Commented Jul 5, 2017 at 18:28
  • To really improve security you need to also set as read only HISTCONTROL. If the option ignorespace, a command that start with an space will not be logged. And keep HISTIGNORE empty to prevent that some commands are not stored. Commented Jul 6, 2017 at 0:12
  • Also, if someone executes the command nano shtest, that is what will be logged, only a perfectly innocuous nano editor, but inside the file, a simple exec sh, or exec badprogram will allow an user to avoid detection. Commented Jul 6, 2017 at 0:25
  • And, also, as the logging takes place after a command has returned to the shell (not before), the process may take actions to change the name of the process or some other mischief. Commented Jul 6, 2017 at 0:28
  • 1
    Indeed it is not full proof ; it is just another tool. Commented Jul 6, 2017 at 13:24

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.