Bash version 4.N has apparently the ability to write command-history to syslog, but I can't find information about how to configure this.

I have read several pages which offer hacks using the PROMPT_COMMAND, and trap, and I know that there's a patch available, but this should be unnecessary, as it is now built in.

I know I can use auditd to capture commands, but I'd like to use the bash/syslog combination.

  • see also unix.stackexchange.com/questions/422897/… Jul 19, 2018 at 4:32
  • 1
    Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert. Jul 19, 2018 at 4:38
  • The no frills way to subvert both is using another shell- Jul 19, 2018 at 5:28
  • Assuming that another shell is installed and available. Jul 19, 2018 at 22:53
  • You do not need special privileges to copy/install/compile an alternate shell. Jul 19, 2018 at 22:55

1 Answer 1


This approach seems to be what you're looking for. This article discusses it, titled: Improving Bash Forensics Capabilities.


While discussing with him about this topic, I realized that there are some ways to fine tune the history of commands to improve forensics investigations. In 2009, I also wrote a blog post about Bash which gave some ideas to send a Bash command history to a remote Syslog server. I checked my web logs and this blog post remains popular with more than 1000 visits for the last 30 days! Note that my blog post is outdated: Since the version 4.1, Bash supports Syslog natively but in most distribution, it is not enabled. To use this feature, you need to recompile your shell.

I found this not very convenient but the good point is that it cannot be disabled by the user (except if he switches his shell to another shell or another Bash binary). You just have to define "SYSLOG_HISTORY" in config-top.h:

$ vi config-top.h
#if defined (SYSLOG_HISTORY)

make install

So it would seem that though the feature is available in Bash 4.1+ it's likely not compiled by default with the Bash in most of the popular distros.

I haven't found a method for seeing what options a given Bash was compiled with, so to answer that question, you'll likely need to look to the upstream .spec file used when building the Bash RPM, for example, on Redhat distros, the same approach can be used for Debian based distros as well.

As confirmation I looked in the Bash .spec file for the Bash included with CentOS 7.2.1511 and it does not have this enabled:

$ grep configure bash.spec
%configure --with-bash-malloc=no --with-afs
- Use the configure macro instead of calling ./configure directly

Rolling your own RPM

Here are the steps that I used to build my own Bash using the gist of what the above details spelled out.

download & install source

To start I downloaded a source RPM (SRPM) of Bash that's available for CentOS 7.x. After downloading it I installed it into my rpmbuild directory:

$ rpmdev-setuptree
$ rpm -ivh bash-4.2.46-20.el7_2.src.rpm

This will unpack files into rpmbuild/SPEC & rpmbuild/SOURCES. Now we're going to make a copy of the contents of the unpacked Bash tar.gz file using these steps:

$ cd rpmbuild/SOURCES
$ tar zxf bash-4.2.tar.gz
$ cp -prf bash-4.2 bash-4.2-orig
$ cd bash-4.2

Edit rpmbuild/SOURCES/bash-4.2/config-top.h and make it look like this:

/* Define if you want each line saved to the history list in bashhist.c:
   bash_add_history() to be sent to syslog(). */
#if defined (SYSLOG_HISTORY)

Edit rpmbuild/SOURCES/bash-4.2/bashhist.c and make bash_syslog_history function look like this:

bash_syslog_history (line)
     const char *line;
  char trunc[SYSLOG_MAXLEN];

  if (strlen(line) < SYSLOG_MAXLEN)
    syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD=%s", getpid(), current_user.uid, current_user.user_name, line);
      strncpy (trunc, line, SYSLOG_MAXLEN);
      trunc[SYSLOG_MAXLEN - 1] = '\0';
      syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD(TRUNCATED)=%s", getpid(), current_user.uid, current_user.user_name, trunc);

Now generate a .patch file which includes our changes to these 2 files:

$ cd $HOME/rpmbuild/SOURCES
$ diff -Npru bash-4.2-orig bash-4.2 > bash_history_rsyslog.patch

Add these lines to $HOME/rpmbuid/SPEC/bash.spec. Put these lines into the appropriate places in the SPEC file:

# history syslog
Patch144: bash_history_rsyslog.patch
%patch144 -p1 -b .history_rsyslog

Now build it:

$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba bash.spec

The tail end of this build will look like this:

Processing files: bash-debuginfo-4.2.46-20.el7.centos.x86_64
Provides: bash-debuginfo = 4.2.46-20.el7.centos bash-debuginfo(x86-64) = 4.2.46-20.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-doc-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-debuginfo-4.2.46-20.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.nGworU
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd bash-4.2
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
+ exit 0

Once complete, we can install the resulting RPM:

$ sudo rpm -ivh --force $HOME/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:bash-4.2.46-20.el7.centos        ################################# [100%]
configure rsyslog

Now modify rsyslog's /etc/rsyslog.conf config:

$ sudo vim /etc/rsyslog.conf
$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514


$template IpTemplate,"/var/log/bash-log/%FROMHOST-IP%.log"
*.* ?IpTemplate
& ~


Then restart Rsyslog:

$ sudo systemctl restart rsyslog
test & confirm

Now run a new instance of Bash as root, and run a couple of commands:

$ sudo -Es
$ ls

And tail the log file, /var/log/bash-log/

$ tail /var/log/bash-log/
2018-07-19T23:23:37.568131-04:00 centos7 bash: HISTORY: PID=12511 UID=1000 USER=vagrant CMD=sudo -Es
2018-07-19T23:23:37.573825-04:00 centos7 sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant/rpmbuild/SOURCES ; USER=root ; COMMAND=/bin/bash
2018-07-19T23:23:37.589258-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4454 reply_cookie=0 error=n/a
2018-07-19T23:23:37.590633-04:00 centos7 dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.590806-04:00 centos7 dbus-daemon: dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.592160-04:00 centos7 dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.592311-04:00 centos7 dbus-daemon: dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.602174-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4455 reply_cookie=0 error=n/a
2018-07-19T23:23:38.520300-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=ls
2018-07-19T23:23:49.210406-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=tail /var/log/bash-log/

Notice the CMD=... lines in this log? These are the commands we just ran, a ls & tail.


To help people out with this I've taken the liberty to build the Bash RPM with the modifications made in Copr.

  • 1
    Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it. Jul 19, 2018 at 4:34
  • Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog. Jul 19, 2018 at 22:57
  • @slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly. Jul 19, 2018 at 23:07
  • 1
    @slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail. Jul 21, 2018 at 11:25
  • 1
    I guess that's how it's supposed to work - but I reckon you deserve a few more cherries! Anyway, thanks again. Aug 20, 2018 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.