Linux auth logs: SSH sign-ins, password spraying and sudo

The Linux authentication pack in the Logit.io Dashboard Library installs six OpenSearch Dashboards that read the auth log your servers already write: an overview, failed SSH sign-ins, successful SSH sign-ins, sudo activity, SSH password spraying and a user investigation timeline. The dashboards read filebeat-* and filter on event.dataset:(system.auth OR system.syslog), and the sign-in and sudo panels narrow that to the parsed auth events Filebeat's system module produces from /var/log/auth.log or /var/log/secure. Within a few minutes of setup you can see who is trying to sign in, from where, whether anyone got in and who ran what with sudo.

This guide is for teams who run Linux servers (cloud VMs, bare metal or long-lived build hosts) and want sign-in and sudo activity in one place instead of grepping auth logs on each box. It covers which auth log lines the parser turns into sign-in events and which it ignores, how to get the auth log onto your stack on Ubuntu, Debian, Red Hat family and Amazon Linux, how to prove the fields with a test event, what each of the six dashboards is for, three investigations worth knowing and how to turn the password spraying view into an alert.

Six dashboards from one auth log

The pack is called Linux authentication in the Dashboard Library. Its six dashboards all read the filebeat-* index pattern with @timestamp as the time field, open on the last 24 hours and refresh every 60 seconds. Each one is built around a question rather than a log file:

The overview is the one to keep open. It has four tiles across the top (System activity, Failed SSH sign-ins, Sudo activity and Last event received), a full-width activity trend, three donuts for dataset, SSH sign-in outcome and process and a table of the latest failed SSH events with the time, user, source address and host. The other five dashboards are where you go once a tile has told you something is worth a look.

Every panel starts from the same base query, written in Lucene:

agent.type:filebeat AND event.module:system AND event.dataset:(system.auth OR system.syslog)

The sign-in panels add event.action:ssh_login and an event.outcome of success or failure. The sudo panels add process.name:sudo. Those three fields are set when your stack parses the log line, so what the dashboards count depends entirely on which lines the parser recognises. That's worth ten minutes of your time before you trust a number.

Which auth log lines count as sign-ins

An SSH connection writes several lines to the auth log, and only some of them become sign-in events. Here's a short, real-shaped extract from an Ubuntu server, with documentation addresses:

Nov 12 08:14:01 web-01 sshd[41822]: Invalid user oracle from 203.0.113.45 port 51234
Nov 12 08:14:03 web-01 sshd[41822]: Failed password for invalid user oracle from 203.0.113.45 port 51234 ssh2
Nov 12 08:14:05 web-01 sshd[41822]: Connection closed by invalid user oracle 203.0.113.45 port 51234 [preauth]
Nov 12 08:15:40 web-01 sshd[41870]: Failed password for root from 203.0.113.45 port 51290 ssh2
Nov 12 08:20:12 web-01 sshd[41901]: Accepted publickey for deploy from 198.51.100.7 port 50122 ssh2: ED25519 SHA256:3q2+7w
Nov 12 08:20:12 web-01 sshd[41901]: pam_unix(sshd:session): session opened for user deploy(uid=1001) by (uid=0)
Nov 12 08:21:30 web-01 sudo:   deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
Nov 12 08:22:02 web-01 sudo:   intern : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/intern ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow

The parser sorts those lines into four groups.

• Accepted. Accepted publickey and Accepted password lines get event.action: ssh_login and event.outcome: success, with the account in user.name, the client in source.ip and source.port and the method in system.auth.ssh.method.
• Failed and Invalid. Failed password, Failed publickey and Invalid user lines get event.action: ssh_login and event.outcome: failure. The word sshd wrote is kept in system.auth.ssh.event, so you can tell a wrong password for a real account (Failed) from a username that doesn't exist (Invalid).
• sudo. Lines from sudo get process.name: sudo. When the line has the TTY=... ; COMMAND=... shape, the invoking account goes to user.name, the target account to user.effective.name and the command to system.auth.sudo.command. A refusal such as user NOT in sudoers or 3 incorrect password attempts lands in system.auth.sudo.error.
• Everything else. Connection closed, disconnected, PAM session lines and anything from other programs keep the program name in process.name and the text in message, but get no event.action. Account changes from useradd, groupadd, usermod and friends are the exception: they're tagged as IAM events with an outcome of success, which is why you'll see them in the process donut.

So in the extract above, the overview counts three failed sign-ins (two of them from the same single attempt by oracle), one successful sign-in and two sudo records. That has two practical consequences, which come up again in the troubleshooting section. A wrong username is counted twice, once for Invalid user and once for Failed password for invalid user. And a server that only accepts keys often never writes a Failed line at all for a real account: the bot connects, offers nothing useful and sshd logs Connection closed by authenticating user root, which isn't a classified sign-in.

Here is roughly what the Failed password for root line looks like once it's parsed and indexed:

{
  "@timestamp": "2026-11-12T08:15:40.000Z",
  "agent": { "type": "filebeat" },
  "event": {
    "module": "system",
    "dataset": "system.auth",
    "action": "ssh_login",
    "outcome": "failure",
    "category": ["authentication"]
  },
  "process": { "name": "sshd", "pid": 41870 },
  "host": { "hostname": "web-01" },
  "user": { "name": "root" },
  "source": { "ip": "203.0.113.45", "port": 51290 },
  "system": { "auth": { "ssh": { "event": "Failed", "method": "password" } } },
  "related": { "ip": ["203.0.113.45"], "user": ["root"], "hosts": ["web-01"] }
}

Note that host.hostname comes from the log line itself, so it's whatever name the server writes into its own logs. That matters if several servers share a short hostname such as localhost or ip-10-0-1-5.

Get the auth log onto your stack

The dashboards need Filebeat's system module, because the module is what sets event.module and event.dataset and what tells your stack to parse the lines. A plain log or filestream input pointed at the same file gets the lines into your stack with none of those fields, so the Library won't detect the pack and every panel stays empty.

First, check the file exists

The module reads files. Some current distributions no longer write an auth log file by default and keep everything in the systemd journal instead, so check before you configure anything:

A quick check on any host:

ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog

If neither file exists, install rsyslog first. It reads from the journal and writes the classic files, so nothing else on the server changes. Only events logged after rsyslog starts reach the file.

Enable the system module

Start with the Filebeat System integration guide in your Logit.io account. Choose Install Integration first, which prepares your stack for this source, then install Filebeat for your OS as the guide shows. The guide's examples use Filebeat 8.x. Then enable the module:

sudo filebeat modules enable system

Edit /etc/filebeat/modules.d/system.yml. Setting the paths explicitly means the same file works on every distribution in the table:

- module: system
  auth:
    enabled: true
    var.paths: ["/var/log/auth.log*", "/var/log/secure*"]
  syslog:
    enabled: false   # optional, see below

The auth fileset is all the sign-in and sudo dashboards need. The syslog fileset (/var/log/syslog or /var/log/messages) adds the system.syslog dataset, which feeds the activity totals and gives the user investigation timeline context such as service restarts. It's also far noisier than the auth log, so turn it on once you've seen a day of auth volume and decided it's worth the extra documents.

Set the output in /etc/filebeat/filebeat.yml. Copy the block from the integration guide while signed in, because it fills in your stack's Logstash host and port:

filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false

output.logstash:
  hosts: ["your-logstash-host:your-ssl-port"]
  loadbalance: true
  ssl.enabled: true

Then test and start:

sudo filebeat test config
sudo filebeat test output
sudo systemctl enable --now filebeat
sudo journalctl -u filebeat -f

test output should finish with talk to server... OK. Filebeat installed from the deb or rpm package runs as root, so it can read the auth log. If you run it as another user, that user needs read access to /var/log/auth.log or /var/log/secure, which normally means membership of the adm group on Debian and Ubuntu. Beats data sent through your stack's Logstash lands in daily filebeat-* indices, which is the pattern the pack reads. If you have renamed the index in your Logs stack, the pack won't find your data.

Prove it with a test sign-in

You don't need to wait for a bot to find your server. The fastest way to prove the whole path is to write a known line into the auth log yourself with logger, using an address from the documentation range so it can't be confused with a real client:

logger -p authpriv.notice -t sshd "Invalid user logit-test from 192.0.2.10 port 4242"
sudo -k; sudo id
sudo tail -n 5 /var/log/auth.log   # or /var/log/secure

The first line writes an Invalid user line tagged as sshd, which the parser treats as a failed SSH sign-in for logit-test from 192.0.2.10. The second makes sudo ask for your password and log a command. The tail should show both. If you run fail2ban or similar, it may ban 192.0.2.10, which is harmless because nothing real uses that range.

Now open Discover in OpenSearch Dashboards, choose filebeat-*, set the query language to Lucene, set the time picker to the last 15 minutes and search:

event.dataset:system.auth AND user.name:logit-test

Open the document and check that event.action is ssh_login, event.outcome is failure, system.auth.ssh.event is Invalid and source.ip is 192.0.2.10. Then check the sudo half:

event.dataset:system.auth AND process.name:sudo AND system.auth.sudo.command:"/usr/bin/id"

That should show your account in user.name and root in user.effective.name. If either document has a raw message and no parsed fields, the events arrived but weren't parsed: check that you chose Install Integration on the Filebeat System page for this stack.

Next, check the field types with the OpenSearch API on your stack. The endpoint and stack API key are on the Endpoints page in your stack settings, and the guide to connecting to your stack's OpenSearch API covers both authentication modes. In API key mode:

curl -s "https://<stack-id>-es.logit.io/filebeat-*/_field_caps?fields=event.dataset,event.action,event.outcome,process.name,user.name,source.ip,host.hostname,system.auth.sudo.command&apikey=<stack-api-key>&pretty"

You want source.ip as ip and everything else as keyword, all aggregatable. Unlike logstash-*, where string fields are text with a .keyword sub-field, the Beats mapping on filebeat-* maps these fields as keyword directly, which is why the panels group on user.name rather than user.name.keyword. You can read the index templates on your stack (the index templates guide shows how). The default Filebeat template is applied when an index is created, so fix field types in your pipeline rather than editing the live mapping. Existing daily indices keep their first type until they age out.

Finally, count what the Library will see. Detection looks at the last 24 hours of filebeat-* for event.dataset of system.auth or system.syslog, and needs event.action and process.name to be aggregatable:

curl -s -H 'Content-Type: application/json' \
  "https://<stack-id>-es.logit.io/filebeat-*/_search?apikey=<stack-api-key>" -d '{
  "size": 0,
  "query": { "bool": { "filter": [
    { "range": { "@timestamp": { "gte": "now-24h" } } },
    { "terms": { "event.dataset": ["system.auth", "system.syslog"] } }
  ] } },
  "aggs": {
    "hosts":    { "terms": { "field": "host.hostname", "size": 50 } },
    "outcomes": { "terms": { "field": "event.outcome", "missing": "(none)" } },
    "process":  { "terms": { "field": "process.name", "size": 10 } }
  }
}'

Expect one hosts bucket per server you've set up. A server that's missing from the list is the one to look at before you install.

Install and know which dashboard to open

Open your Logs stack's card in your Logit.io account and choose Dashboard Library. Search for Linux authentication. Once matching events have arrived the pack shows a Data detected badge. If you've only just started shipping, press Rescan stack. Some dashboards may already be ticked, based on what the Library found in your data. Failed sign-ins, for example, point it at the failed sign-in and password spraying dashboards. Use Select all to take all six, choose Install dashboards and open them in OpenSearch Dashboards a minute or two later. The Dashboard Library guide covers the permissions you need and what gets installed, and the post on how Dashboard Library detection works explains the badge in more depth.

A sensible routine for the six dashboards:

1. Daily, the overview. Check Last event received first. On a server that people or automation sign in to every day, a timestamp several hours old usually means Filebeat or rsyslog has stopped, not that the server has gone quiet. Then look at the Failed SSH sign-ins tile against yesterday. Internet-facing SSH on port 22 sees constant background failures, so the level matters less than a step change.
2. When failures jump, failed SSH sign-ins. The two donuts show which accounts are being tried and from which addresses. Mostly root, admin, ubuntu and test from a spread of addresses is the usual internet noise. A real account name from your organisation is more interesting.
3. When one address dominates, password spraying. Same failures, organised to show one source trying many accounts. The donuts make it obvious; the queries in the next section put numbers on it.
4. Weekly, successful SSH sign-ins. The list of accounts that got in, by host. This is the one people skip and shouldn't. Check it for accounts you didn't expect, hosts nobody should be on and password sign-ins on servers that are meant to be key-only.
5. Weekly, sudo activity. Who uses sudo and where. A new name here is worth a conversation.
6. When you need the story, user investigation. Add a filter for one user.name or one host.hostname at the top and read the timeline: sign-in, sudo, service restarts and sign-out in order.

Three investigations worth knowing

One address, many accounts

Password spraying tries a few common passwords against many accounts, which keeps the failures per account low enough to slip under per-account lockouts. The password spraying dashboard shows it visually. This query ranks the sources by how many different accounts each one tried in the last 24 hours and keeps only those that tried five or more:

curl -s -H 'Content-Type: application/json' \
  "https://<stack-id>-es.logit.io/filebeat-*/_search?apikey=<stack-api-key>" -d '{
  "size": 0,
  "query": { "bool": { "filter": [
    { "range": { "@timestamp": { "gte": "now-24h" } } },
    { "term": { "event.dataset": "system.auth" } },
    { "term": { "event.action": "ssh_login" } },
    { "term": { "event.outcome": "failure" } }
  ] } },
  "aggs": {
    "by_source": {
      "terms": { "field": "source.ip", "size": 20, "order": { "accounts": "desc" } },
      "aggs": {
        "accounts": { "cardinality": { "field": "user.name" } },
        "hosts":    { "cardinality": { "field": "host.hostname" } },
        "first":    { "min": { "field": "@timestamp" } },
        "last":     { "max": { "field": "@timestamp" } },
        "spray":    { "bucket_selector": {
          "buckets_path": { "a": "accounts" },
          "script": "params.a >= 5"
        } }
      }
    }
  }
}'

Each bucket is one address with the number of accounts it tried, the number of your servers it reached and when it started and stopped. One address against many accounts on one host is a scanner. The same address reaching several hosts tells you it's working through your address range, which is the moment to block it at the firewall or security group rather than host by host. Cardinality counts are approximate at large numbers, which doesn't matter at this scale.

Failures, then a success

Background failures are noise. A success from an address that has just been failing is not. This query finds addresses with at least five failures and at least one success in the last 24 hours:

curl -s -H 'Content-Type: application/json' \
  "https://<stack-id>-es.logit.io/filebeat-*/_search?apikey=<stack-api-key>" -d '{
  "size": 0,
  "query": { "bool": { "filter": [
    { "range": { "@timestamp": { "gte": "now-24h" } } },
    { "term": { "event.dataset": "system.auth" } },
    { "term": { "event.action": "ssh_login" } }
  ] } },
  "aggs": {
    "by_source": {
      "terms": { "field": "source.ip", "size": 500 },
      "aggs": {
        "failed": { "filter": { "term": { "event.outcome": "failure" } } },
        "ok":     { "filter": { "term": { "event.outcome": "success" } },
                    "aggs": { "users": { "terms": { "field": "user.name", "size": 5 } } } },
        "suspicious": { "bucket_selector": {
          "buckets_path": { "f": "failed>_count", "s": "ok>_count" },
          "script": "params.f >= 5 && params.s >= 1"
        } }
      }
    }
  }
}'

Most hits are people mistyping a password a few times and then getting it right from the office address, which you'll recognise. Anything else deserves the user investigation dashboard straight away: filter on the account from the users bucket and read what happened after the sign-in. If you're unsure, treat it as compromised: lock the account, rotate its keys and check ~/.ssh/authorized_keys on the host. Raise the size on by_source if you see more than a few hundred failing addresses a day, or narrow the time range.

Sudo that shouldn't happen

The sudo dashboards count every record sudo writes. Three searches narrow that down to what you'd act on. Refusals, which are either a misconfigured account or someone testing their access:

event.dataset:system.auth AND process.name:sudo AND system.auth.sudo.error:*

Interactive root shells, which bypass the per-command record that makes sudo logs useful:

event.dataset:system.auth AND process.name:sudo AND system.auth.sudo.command:("/bin/bash" OR "/usr/bin/bash" OR "/bin/sh" OR "/usr/bin/su")

And new accounts and group changes, which the parser tags from useradd, usermod and groupadd:

event.dataset:system.auth AND process.name:(useradd OR usermod OR userdel OR groupadd OR groupmod)

Save each one in Discover with a clear name so the next person on call can find them next to the dashboards.

Turn the spraying view into an alert

A dashboard only helps when someone is looking at it. Logs stacks include alerting with ElastAlert 2 rules, which you enable from Alerting & Notifications in your stack settings (the guide to creating alerting rules walks through it). The cardinality rule type is a direct match for password spraying: it fires when one value of query_key is seen with too many distinct values of another field.

name: SSH password spraying from one address
type: cardinality
index: "filebeat-*"
timeframe:
  minutes: 15
query_key: source.ip
cardinality_field: user.name
max_cardinality: 5
realert:
  minutes: 60
filter:
  - query:
      query_string:
        query: "event.dataset:system.auth AND event.action:ssh_login AND event.outcome:failure"
alert:
  - "email"
email:
  - "[email protected]"

That alerts when one address fails against more than five different accounts within 15 minutes, and then stays quiet for that address for an hour. Start the threshold higher on internet-facing servers if your background noise already crosses it, and lower on servers that are only reachable from your own network, where a single failure from an unknown address is news.

A second rule worth having uses the frequency rule type on sudo refusals, which are rare enough that three in ten minutes is worth a message:

name: Repeated sudo refusals
type: frequency
index: "filebeat-*"
num_events: 3
timeframe:
  minutes: 10
query_key: user.name
filter:
  - query:
      query_string:
        query: "event.dataset:system.auth AND process.name:sudo AND system.auth.sudo.error:*"
alert:
  - "email"
email:
  - "[email protected]"

Run both with Test only before you enable them. Your logger test line from earlier, repeated with six different usernames, is a safe way to make the first rule fire on purpose.

When the numbers look wrong

• The pack isn't detected. No document in the last 24 hours of filebeat-* has event.dataset of system.auth or system.syslog. Either there's no auth log file (see the distribution table), Filebeat is using a plain input rather than the module, the auth fileset is disabled or the events are going to a renamed index. The detection count above tells you which.
• Some servers are missing. Check journalctl -u filebeat on that server for TLS or permission errors, then check the file exists. Debian 12 and Amazon Linux 2023 hosts built from the same image as your Ubuntu servers are the usual culprits.
• Failed sign-ins look roughly double. A wrong username writes both Invalid user and Failed password for invalid user, and both are failures. To count one per attempt, filter on system.auth.ssh.event:Failed or system.auth.ssh.event:Invalid, not both.
• Failed sign-ins are near zero, but the server is internet-facing. If password authentication is off, bots against real accounts often produce only Connection closed by authenticating user lines, which aren't classified. Search for them directly: event.dataset:system.auth AND message:"authenticating user". OpenSSH 9.8 and later also penalise addresses that keep failing, so a busy server can log fewer lines than it used to.
• sshd shows as sshd-session in the process donut. On OpenSSH 9.8 and later the per-connection process has its own name. Classification doesn't depend on the process name, so the sign-in panels still count, but use process.name:(sshd OR sshd-session) in your own searches.
• Sudo activity is much higher than the number of commands. The tile counts every sudo record, including PAM session opened and closed lines, so one command can be three records. For commands only, add system.auth.sudo.command:*.
• Times are shifted by whole hours. Classic auth log lines such as Nov 12 08:14:01 have no year or time zone, so the stack relies on the time zone Filebeat sends in event.timezone. If the server's clock or zone is wrong, so is @timestamp. Fix the zone with timedatectl rather than in the pipeline.
• Last event received is empty. No auth events in the selected range. On a server people sign in to, that means collection has stopped. Check that rsyslog and Filebeat are both running.
• One host shows under several names, or several under one. host.hostname comes from the log line. Give each server a unique hostname with hostnamectl set-hostname, then restart rsyslog.

What the pack doesn't cover

• It reads logs, it doesn't block anything. The pack shows what happened. Keep fail2ban, a firewall allow list or a bastion host in front of SSH. Use the dashboards to check they're working.
• A sudo record is not proof of root. The sudo dashboard counts records, including refused ones. Use system.auth.sudo.error to separate refusals from commands that ran.
• No MFA, geography or dormant account views. Those aren't in this version of the pack. If your stack adds location fields to source.ip, you can build a map in a copy of the dashboard.
• Filebeat only. Every query includes agent.type:filebeat. Auth logs shipped with the OpenTelemetry Collector, Fluent Bit or a syslog forwarder still reach your stack, but not these dashboards.
• Journal-only hosts need rsyslog. The pack was built and checked against the file-based auth log. Hosts that only keep the systemd journal need rsyslog writing the classic file, as described above.
• Auth logs contain personal data. Usernames, addresses and commands are all in there, and people sometimes type a password into the username prompt, which then appears as an Invalid user. Check who can view filebeat-* on your stack and keep retention to what you need.

FAQ

My servers only use the systemd journal. Will the pack work?

Install rsyslog so the server writes /var/log/auth.log or /var/log/secure again, then point the Filebeat system module at that file. The pack was built against the file-based auth log, and rsyslog reads from the journal, so you don't lose anything by adding it.

Why is the failed sign-in count higher than the number of attempts?

sshd writes two lines for a wrong username, Invalid user and Failed password for invalid user, and both are classified as failed sign-ins. A wrong password for a real account writes one. Filter on system.auth.ssh.event when you need one count per attempt.

Do I need the syslog fileset too?

No. The auth fileset fills the sign-in, sudo and spraying dashboards on its own. The pack is detected from either. The syslog fileset adds context to the overview and the user investigation timeline, at the cost of many more documents.

Can I ship auth logs with the OpenTelemetry Collector instead?

You can ship them, but these dashboards won't show them. Every panel filters on agent.type:filebeat and on fields the Filebeat system module produces. Use Filebeat for the auth log even if other logs on the same server go through the Collector.

Can I change the thresholds or add panels?

Yes. Save a copy of the dashboard in OpenSearch Dashboards and change the copy, for example to add system.auth.ssh.method to the successful sign-ins table. Edit the copy rather than the installed dashboard, so the Library version stays as a reference.

Can I try it on the free trial?

Yes. The 14-day free trial includes every feature, including the Dashboard Library, alerting and Hosted OpenSearch MCP. Point Filebeat at one server, write the logger test line and install the pack.

Next steps

Check that each server has an auth log file, enable the auth fileset in the Filebeat system module, write the logger test line and find it in Discover, then install all six dashboards and add the password spraying alert. Look at the successful sign-ins dashboard once a week: it's the one that tells you something you didn't know. If you're running your own OpenSearch cluster for security logs, a Logit.io Logs stack gives you managed Logstash, OpenSearch and OpenSearch Dashboards with the Dashboard Library built in. For a dedicated cluster, see Hosted OpenSearch and OpenSearch pricing. To ask questions of the same auth logs from any MCP-compatible AI assistant, such as which accounts were tried from a given address this week, see Hosted OpenSearch MCP.