How to Configure PAM to Audit Logging Shell User Activity

This is our ongoing series on Linux Auditing, in this fourth part of this article, we will explain how to configure PAM for auditing of Linux TTY input (Logging Shell User Activity) for specific users using pam_tty_audit tool.

Linux PAM (Pluggable Authentication Modules) is a highly flexible method for implementing authentication services in applications and various system services; it emerged from the original Unix PAM.

It divides authentication functions into four major management modules, namely: account modules, authentication modules, password modules and session modules. The detailed explanation of theses management groups is beyond the scope of this tutorial.

The auditd tool uses the pam_tty_audit PAM module to enable or disable auditing of TTY input for specified users. Once a user is configured to be audited, pam_tty_audit works in conjunction with the auditd to track a users actions on the terminal and if configured, capture the exact keystrokes the user makes, then records them in the /var/log/audit/audit.log file.

Configuring PAM for Auditing User TTY Input in Linux

You can configure PAM for auditing a particular users TTY input in the /etc/pam.d/system-auth and /etc/pam.d/password-auth files, using the enable option. On the other hand, as expected, the disable turns it off for the specified users, in the format below:

session required disable=username,username2... enable=username,username2..

To turn on logging of actual user keystrokes (including spaces, backspaces, return keys, the control key, delete key and others), add the log_passwd option together with the other options, using this form:

session required disable=username,username2... enable=username log_passwd

But before you perform any configurations, note that:

  • As seen in the syntax above, you can pass many usernames to the enable or disable option.
  • Any disable or enable option overrides the previous opposite option that matches the same username.
  • After enabling TTY auditing, it is inherited by all processes initiated by the defined user.
  • If recording of keystrokes is activated, the input is not logged instantly, since TTY auditing first stores the keystrokes in a buffer and writes the buffer content at given intervals, or after the audited user logs out, into the /var/log/audit/audit.log file.

Let’s look at an example below, where we’ll configure pam_tty_audit to record the actions of the user tecmint including keystrokes, across all terminals, while we disable TTY auditing for all other system users.

Open these two following configuration files.

# vi /etc/pam.d/system-auth
# vi /etc/pam.d/password-auth

Add following line to the configuration files.
session required disable=* enable=tecmint

And to capture all keystrokes entered by the user tecmint, we can add the log_passwd option a shown.

session required disable=* enable=tecmint log_passwd

Now save and close the files. Afterwards, view the auditd log file for any TTY input recorded, using the aureport utility.

# aureport --tty
Audit User TTY in Linux

Audit User TTY in Linux

From the output above, you can see the user tecmint whose UID is 1000 used the vi/vim editor, created a directory called bin and moved into it, cleared the terminal and so on.

To search for TTY input logs recored with time stamps equal to or after a specific time, use the -ts to specify the start date/time and -te to set the end date/time.

The following are some example:

# aureport --tty -ts 09/25/2017 00:00:00 -te 09/26/2017 23:00:00
# aureport --tty -ts this-week

You can find more information, in the pam_tty_audit man page.

# man pam_tty_audit

Check out following useful articles.

  1. Configure “No Password SSH Keys Authentication” with PuTTY on Linux Servers
  2. Setting Up LDAP-based Authentication in RHEL/CentOS 7
  3. How to Setup Two-Factor Authentication (Google Authenticator) for SSH Logins
  4. SSH Passwordless Login Using SSH Keygen in 5 Easy Steps
  5. How to Run ‘sudo’ Command Without Entering a Password in Linux

In this article, we described how to configure PAM for auditing of input for specific users on CentOS/RHEL. If you have any questions or additional ideas to share, use the comment from below.

We're giving away a Linux-ready laptop from ZaReason

For the first time ever, is partnering with ZaReason to give away an UltraLap 5330 laptop with Linux pre-installed!

Since 2007, ZaReason has assembled, shipped, and supported hardware specifically designed for Linux, and the UltraLap 5330 is no exception—the 3.6-lb laptop ships with the Linux distribution of your choice and boasts the following hardware specs:

  • 14″ FHD display
  • Intel i3-7100U processor
  • 4GB RAM
  • 120GB M.2 SSD

So, what are you waiting for? Enter our ZaReason Laptop Giveaway by Sunday, September 24 at 11:59 p.m. Eastern Time (3:59 a.m. UTC) for your chance to win.

Have a great idea for a future giveaway? Let us know about it in the comments below.

3 text editor alternatives to Emacs and Vim

Before you start reaching for those implements of mayhem, Emacs and Vim fans, understand that this article isn’t about putting the boot to your favorite editor. I’m a professed Emacs guy, but one who also likes Vim. A lot.

That said, I realize that Emacs and Vim aren’t for everyone. It might be that the silliness of the so-called Editor war has turned some people off. Or maybe they just want an editor that is less demanding and has a more modern sheen.

If you’re looking for an alternative to Emacs or Vim, keep reading. Here are three that might interest you.


Geany is an old favorite from the days when I computed on older hardware running lightweight Linux distributions. Geany started out as my LaTeX editor, but quickly became the app in which I did all of my text editing.

Although Geany is billed as a small and fast IDE (integrated development environment), it’s definitely not just a techie’s tool. Geany is small and it is fast, even on older hardware or a Chromebook running Linux. You can use Geany for everything from editing configuration files to maintaining a task list or journal, from writing an article or a book to doing some coding and scripting.

Plugins give Geany a bit of extra oomph. Those plugins expand the editor’s capabilities, letting you code or work with markup languages more effectively, manipulate text, and even check your spelling.


Atom is a new-ish kid in the text editing neighborhood. In the short time it’s been on the scene, though, Atom has gained a dedicated following.

What makes Atom attractive is that you can customize it. If you’re of a more technical bent, you can fiddle with the editor’s configuration. If you aren’t all that technical, Atom has a number of themes you can use to change how the editor looks.

And don’t discount Atom’s thousands of packages. They extend the editor in many different ways, enabling you to turn it into the text editing or development environment that’s right for you. Atom isn’t just for coders. It’s a very good text editor for writers, too.


Maybe Atom and Geany are a bit heavy for your tastes. Maybe you want a lighter editor, something that’s not bare bones but also doesn’t have features you’ll rarely (if ever) use. In that case, Xed might be what you’re looking for.

If Xed looks familiar, it’s a fork of the Pluma text editor for the MATE desktop environment. I’ve found that Xed is a bit faster and a bit more responsive than Pluma—your mileage may vary, though.

Although Xed isn’t as rich in features as other editors, it doesn’t do too badly. It has solid syntax highlighting, a better-than-average search and replace function, a spelling checker, and a tabbed interface for editing multiple files in a single window.

Other editors worth exploring

I’m not a KDE guy, but when I worked in that environment, KDevelop was my go-to editor for heavy-duty work. It’s a lot like Geany in that KDevelop is powerful and flexible without a lot of bulk.

Although I’ve never really felt the love, more than a couple of people I know swear by Brackets. It is powerful, and I have to admit its extensions look useful.

Billed as a “text editor for developers,” Notepadqq is an editor that’s reminiscent of Notepad++. It’s in the early stages of development, but Notepadqq does look promising.

Gedit and Kate are excellent for anyone whose text editing needs are simple. They’re definitely not bare bones—they pack enough features to do heavy text editing. Both Gedit and Kate balance that by being speedy and easy to use.

Do you have another favorite text editor that’s not Emacs or Vim? Feel free to share by leaving a comment.

Top 5: Your first programming language, running Windows apps on Linux, and more

For more discussion on open source and the role of the CIO in the enterprise, join us at The

The opinions expressed on this website are those of each author, not of the author’s employer or of Red Hat. aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.

Diversity and inclusion: Stop talking and do your homework

Open source undoubtedly has a diversity problem. In fact, tech has a diversity problem. But this isn’t news?—?women, people of color, parents, non-technical contributors, gay, lesbian, transgender, and other marginalized people and allies have shared stories of challenge for years.

At Mozilla, we believe that to influence positive change in diversity and inclusion (D&I) in our communities, and more broadly in open source, we need to learn, empathize, innovate, and take action. Open source is missing out on diverse perspectives and experiences that can drive change for a better world because we’re stuck in our ways—continually leaning on long-held assumptions about why we lose people. Counting who makes it through the gauntlet of tasks and exclusive cultural norms that leads to a first pull request can’t be enough. Neither can celebrating increased diversity on stage at technical conferences, especially when the audience remains homogeneous and abuse goes unchallenged.

This year, leading with our organizational strategy for D&I, we are in investing in a D&I strategy for Mozilla’s communities informed by three months of research.

Following are early recommendations emerging from our research.

Build and sustain diverse communities

1. Provide organizational support to established identity groups

For reasons of safety, friendship, mentorship, advocacy, and empowerment, we found positive support for identity groups. Identity groups are sub-communities formed under a dimension of diversity, such as language, gender, or even a specific skillset. Such groups can act as springboards into and out of the greater community.

2. Develop inclusive community leadership models

To combat gatekeeping and the myth of meritocracy, community roles must be designed with greater accountability for health, inclusion, and especially for recognizing achievements of others as core functions.

3. Implement project-wide strategies for toxic behavior

The perceived risk of losing productivity and momentum when addressing toxic behavior is shown to interfere with and risk community health. Insights amplified by HR industry findings show that, although toxic individuals are often highly productive, their cost in lost productivity far outweighs their perceived value. Strategies for combatting this in open communities should include cross-project communication about such decisions to avoid alienating or losing contributors.

4. Integrate D&I standards and best practices into product lifecycles

Extending on the notion of cross-project collaboration is the strong sense that building D&I standards into product lifecycles would benefit maintainers and community leaders, create reach, increase collaboration, and break down silos. An analogy is how web standards enable open communities to build on one other’s work across various open ecosystems.

5. Build inclusivity into events

Project and community events, although trending in positive directions by putting diversity on stage, struggle with homogenous audiences, unclear processes for code-of-conduct reporting, and neglect of neurodiversity issues. A series of recommendations is coming based on this research, and Mozfest has done a great job in past year of building inclusiveness into programming.

Design models for accessible communication

6. Break the language barrier

Quantitative research showed only 21% of our respondents spoke English as a first language. Prioritizing offering all key communications in multiple languages, or providing transcripts that can be easily localized, is important. The intersection of language and other diversity issues raised almost impossible barriers (for example, a new mother whose first language isn’t English runs out of time translating a presentation made in English).

7. Generate diverse network capabilities

Contrary to the spirit of openness, many (if not a majority of) projects are working on similar D&I problems—with learning rarely shared between, or even within, communities and projects. New generations of community managers and leaders identify the same issues—and begin again. Later this year, we’ll propose an initiative to bring together learning, document ways to build communication, and collaborate towards innovation desperately needed to move the needle in D&I.

8. Experiment with accessible communication

In our interviews, we were surprised to learn that text-based interviews were preferred not only by those with limited bandwidth, but also those who identified as introverts, preferred anonymity, or have a non-English first language. The simple act of changing the way we talk to people can have wide-ranging impacts, so we should experiment often with different modes of communication.

9. Avoid exclusion by technical jargon

Technical jargon or lingo and overly complicated language were cited as critical challenges for getting involved in projects.?Our data shows that technical confidence might be influencing that barrier, and men were nearly twice as likely to rate their technical confidence highly. These findings indicate that it’s critically important to limit jargon and to shift from technical posturing to empathy in participatory design. Rust is working on this.

Frameworks for incentive and consequence

10. Mobilize community participation guidelines

In recent conversations with other open project leaders, I’ve realized this is a pivotal moment for open projects that have adopted codes of conduct. We’re at a critical stage in making inclusive and open project governance effective and understood—making it? real. Although enforcing our guidelines sometimes feels uncomfortable and even meets resistance, there are far more people for whom empowerment, safety, and inclusion will be celebrated and embraced.

11. Standardize incentives and recognition

Although the people we interviewed want to feel valued, they also said it’s important that their accomplishments are publicly recognized in formats with real-world value. It’s worth noting that recognition in open communities tends to skew toward people most able to surface their accomplishments and technical contributions, which may exclude more reserved people.

12. Design inclusive systems that protect identity

Many systems do not adequately protect the information of people who register in community portals, and thus exclude or expose those who prefer to hide personal data for reasons of safety and privacy. The research showed a variety of non-obvious ways we ask for and store gender-identity information. D&I standards are a way forward in providing structure, predictability, and safety in systems, as well as mechanisms to track our progress.

More detailed findings on our research and path forward can be found on Mozilla’s Open Innovation Blog.

Learn more in Emma Irwin & Larissa Shapiro’s talk, “Time for Action—Innovating for D&I in Open Source Communities,” at Open Source Summit, Sept. 11-14 in Los Angeles.