# Not able to collect TTY logs using AuditBeat in Kubernetes (AWS EKS)

**URL:** <https://discuss.elastic.co/t/not-able-to-collect-tty-logs-using-auditbeat-in-kubernetes-aws-eks/254006>\
**Category:** Beats\
**Tags:** auditbeat\
**Created:** [November 2, 2020, 9:59am UTC](https://discuss.elastic.co/t/not-able-to-collect-tty-logs-using-auditbeat-in-kubernetes-aws-eks/254006 "2020-11-02T09:59:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![benyitzhaki](https://avatars.discourse-cdn.com/v4/letter/b/9de0a6/32.png) [@benyitzhaki](https://discuss.elastic.co/u/benyitzhaki)\
**Post date:** [November 2, 2020, 9:59am UTC](https://discuss.elastic.co/t/not-able-to-collect-tty-logs-using-auditbeat-in-kubernetes-aws-eks/254006/1 "2020-11-02T09:59:31Z")

</div>

I would like to audit users shell activity using AuditBeat and the auditd module integration, by looking at TTY logs. I have followed every possible doc and can't get it up and running.  
I can see executions, but can't see the actual TTY.

I'm running AuditBeat in Kubernetes, over AWS EKS. Using the official helm chart.  
I have minimal configuration file:

```auto
    image:
      repository: docker.elastic.co/beats/auditbeat
      tag: 6.7.0
      pullPolicy: IfNotPresent
    config:
      auditbeat.modules:
      - module: auditd
        rate_limit: 0
        backlog_limit: 8196
        audit_rules: |
         -a exit,always -F arch=b64 -F euid=0 -S execve -k rootact
         -a exit,always -F arch=b32 -F euid=0 -S execve -k rootact
         -a exit,always -F arch=b64 -F euid>=1 -S execve -k useract
         -a exit,always -F arch=b32 -F euid>=1 -S execve -k useract
      processors:
      - add_cloud_metadata:
      output.file:
        path: "/usr/share/auditbeat/data"
        filename: auditbeat
        rotate_every_kb: 10000
        number_of_files: 5

```

I have also added `session required pam_tty_audit.so enable=*` to both ` /etc/pam.d/password-auth` and ` /etc/pam.d/system-auth`

I'm auditing the outcome by tailing `/usr/share/auditbeat/data/auditbeat`, it has the logs for the executions but none for the TTY.

I have also tried running `aureport --tty` but it returns

```auto
    TTY Report
    ===============================================
    # date time event auid term sess comm data
    ===============================================
    <no events of interest were found>

```

auditd service has been stopped using `sudo service auditd stop` (and anyway we can see other logs by tailing for auditbeat, so its probably not the issue)

Anything i'm missing? What am i doing wrong?

Have already gone through:

- [Not getting TTY translations in Auditbeat 6.7](https://discuss.elastic.co/t/not-getting-tty-translations-in-auditbeat-6-7/191684)
- [Dec 2nd, 2019: [EN][Auditbeat] Monitoring Linux Command Execution](https://discuss.elastic.co/t/dec-2nd-2019-en-auditbeat-monitoring-linux-command-execution/209125)

Thanks

---

<div class="post-metadata">

**Author:** ![benyitzhaki](https://avatars.discourse-cdn.com/v4/letter/b/9de0a6/32.png) [@benyitzhaki](https://discuss.elastic.co/u/benyitzhaki)\
**Post date:** [November 11, 2020, 12:24pm UTC](https://discuss.elastic.co/t/not-able-to-collect-tty-logs-using-auditbeat-in-kubernetes-aws-eks/254006/2 "2020-11-11T12:24:41Z")

</div>

Follow up question - according to the documentation, its required to stop auditd when using auditbeats with auditd, however, it seems that auditd tty logs don't work when auditd is not working. once i enabled auditd and enabled tty logs, it worked fine and i could see my logs using `aureport --tty`. how can we get the two to work together?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 9, 2020, 2:24pm UTC](https://discuss.elastic.co/t/not-able-to-collect-tty-logs-using-auditbeat-in-kubernetes-aws-eks/254006/3 "2020-12-09T14:24:42Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.