How to Monitor Failed SSH Login Attempts Using Wazuh

Secure Shell (SSH) is one of the most widely used protocols for remotely managing Linux servers, cloud instances, network devices, and infrastructure components.

Because SSH often provides administrative access to critical systems, it is a frequent target for cybercriminals attempting to gain unauthorized access.

One of the earliest indicators of an SSH attack is a failed login attempt.

These events occur when a user or attacker tries to authenticate to an SSH service but fails due to an invalid username, incorrect password, disabled account, or unsuccessful public key authentication.

While an occasional failed login may simply be a user mistake, repeated failures often signal malicious activity.

Some of the most common SSH attack techniques include:

Brute-force attacks that repeatedly attempt different password combinations until a valid credential is found.
Credential stuffing attacks that use usernames and passwords stolen from previous data breaches.
Password spraying attacks that attempt a small number of common passwords against many accounts to avoid triggering lockout policies.

According to the Open Worldwide Application Security Project, weak authentication monitoring remains a major security concern because attackers frequently target exposed services using automated credential attacks.

This is where Wazuh becomes extremely valuable. Wazuh continuously monitors authentication logs, analyzes SSH events in real time, applies built-in detection rules, and generates alerts whenever suspicious login activity occurs.

Security teams can quickly identify brute-force attempts, investigate malicious IP addresses, and automate responses before attackers successfully gain access.

In this guide, you’ll learn:

How SSH authentication works
What constitutes a failed SSH login attempt
How Wazuh collects and analyzes SSH authentication logs
Which built-in Wazuh rules detect SSH attacks
How to configure SSH log monitoring
How to create custom detection rules for advanced use cases
Best practices for reducing SSH-related security risks

By the end of this tutorial, you’ll have a complete understanding of how to monitor failed SSH login attempts using Wazuh and strengthen your organization’s Linux security posture.

Understanding Failed SSH Login Attempts

Before configuring monitoring and alerts, it’s important to understand how SSH authentication works and what actually causes a login attempt to fail.

What Is SSH Authentication?

SSH (Secure Shell) is a cryptographic network protocol that enables secure remote access to systems over an encrypted connection.

System administrators, DevOps engineers, and security teams commonly use SSH to manage Linux servers, cloud workloads, containers, and network infrastructure.

Unlike legacy remote access protocols such as Telnet, SSH encrypts all communication between the client and server, protecting credentials and session data from interception.

Overview of Secure Shell (SSH)

SSH operates using a client-server model:

The SSH client initiates a connection.
The SSH server validates the user’s identity.
An encrypted communication channel is established.
The user receives access to the remote system.

A typical SSH connection looks like:

ssh user@server-ip

Once connected, users can execute commands, transfer files, and perform administrative tasks securely.

Common SSH Authentication Methods

SSH supports several authentication mechanisms.

Password Authentication

The user provides a username and password that the server validates against local or centralized authentication systems.

Example:

ssh admin@server1

Public Key Authentication

The user authenticates using an SSH key pair rather than a password.

This method is generally considered more secure because private keys are significantly harder to compromise than passwords.

Multi-Factor Authentication (MFA)

Organizations often combine passwords or SSH keys with additional authentication factors such as:

Authentication apps
Hardware security keys
One-time passwords (OTP)

Directory-Based Authentication

Enterprise environments may integrate SSH authentication with:

LDAP
Active Directory
Kerberos
SSSD

Typical SSH Login Workflow

A standard SSH authentication process follows several steps:

Client initiates a connection to the SSH server.
The server presents its host key.
Encryption parameters are negotiated.
The user submits credentials.
The server validates the credentials.
Access is either granted or denied.
The authentication result is written to the system logs.

These log entries are the events that Wazuh monitors and analyzes.

What Constitutes a Failed SSH Login Attempt?

A failed SSH login attempt occurs whenever the authentication process is unsuccessful.

Several situations can generate authentication failure events.

Invalid Username Attempts

An attacker may attempt to log in using usernames that do not exist on the system.

Examples include:

root
admin
test
ubuntu
oracle

Authentication logs often record these events as:

Failed password for invalid user admin

These entries are frequently observed during automated internet-wide scanning campaigns.

Incorrect Password Submissions

The most common failure occurs when a valid username is supplied but the password is incorrect.

Example:

Failed password for root

Repeated failures from the same source often indicate brute-force activity.

Authentication Failures Caused by Disabled Accounts

Authentication may also fail when users attempt to access accounts that have been:

Disabled
Locked
Expired
Suspended

These events can indicate either user error or attempts to abuse dormant accounts.

Public Key Authentication Failures

Organizations that rely on SSH keys may see failures caused by:

Invalid keys
Missing keys
Revoked keys
Incorrect permissions
Corrupted key files

Example log entry:

Failed publickey for user

Monitoring these failures helps identify configuration issues and unauthorized access attempts.

Security Risks of Unmonitored SSH Failures

Ignoring SSH authentication failures can leave organizations blind to some of the most common attack techniques used against Linux infrastructure.

Brute-Force Attacks

Brute-force attacks attempt thousands of username and password combinations until a valid credential is discovered.

Attackers often use automated tools that continuously target exposed SSH services.

The Cybersecurity and Infrastructure Security Agency recommends monitoring authentication failures as part of a defense-in-depth strategy because repeated login failures are often one of the earliest indicators of compromise.

Credential Theft Attempts

Threat actors frequently use credentials obtained from previous breaches.

Instead of guessing passwords, they attempt to authenticate using known username-password combinations.

This technique is commonly known as credential stuffing.

Monitoring failed SSH logins can reveal these attacks before successful access occurs.

Unauthorized Access Risks

If attackers eventually discover valid credentials, they may gain:

Administrative access
Sensitive data access
Lateral movement capabilities
Persistence within the environment

Detecting authentication failures early reduces the likelihood of successful compromise.

Compliance and Auditing Concerns

Many regulatory frameworks require organizations to monitor authentication activity and investigate suspicious access attempts.

Examples include:

Payment Card Industry Security Standards Council PCI DSS
National Institute of Standards and Technology security controls
ISO 27001 auditing requirements
SOC 2 security monitoring controls

Failure to monitor authentication logs can result in audit findings, compliance violations, and reduced visibility into security events.

If you’re already collecting Linux logs in Wazuh, see How to Add Linux Endpoints to Wazuh for agent deployment best practices.

How Wazuh Detects Failed SSH Login Attempts

Wazuh includes built-in capabilities for collecting SSH authentication logs, decoding events, correlating suspicious behavior, and generating security alerts.

This allows organizations to quickly identify failed login attempts, brute-force attacks, and unauthorized access attempts across their Linux infrastructure.

Wazuh Log Collection Architecture

Wazuh processes SSH authentication events through several components working together.

1. Wazuh Agents

The Wazuh agent runs on Linux endpoints and continuously monitors configured log files.

When SSH authentication events occur, the agent:

Reads the log entry
Normalizes the event
Sends the data to the Wazuh manager

This enables centralized monitoring across hundreds or thousands of systems.

2. Log Analysis Engine

The Wazuh manager receives log events from agents and passes them through the analysis engine.

The analysis engine:

Identifies log formats
Extracts key fields
Matches events against detection rules
Assigns alert severity levels

This process occurs in near real time.

3. Rules and Decoders

Decoders identify SSH-related log entries and extract information such as:

Username
Source IP address
Authentication method
Hostname
Event type

Rules then evaluate the event to determine whether an alert should be generated.

Learn more about rule creation in How to Create Custom Detection Rules in Wazuh (With Examples).

4. Alert Generation Process

When a rule matches:

The event is classified.
A severity level is assigned.
Alert details are generated.
The event is indexed and displayed in the dashboard.

Security teams can then investigate or automate responses.

SSH Log Sources Monitored by Wazuh

Wazuh supports multiple authentication log sources depending on the Linux distribution.

/var/log/auth.log (Ubuntu/Debian)

Ubuntu and Debian systems typically store SSH authentication events in:

/var/log/auth.log

Example:

Failed password for invalid user admin from 192.168.1.100

Wazuh monitors these entries and generates alerts when authentication failures occur.

/var/log/secure (RHEL/CentOS/Rocky Linux)

Red Hat-based systems commonly use:

/var/log/secure

Example:

Failed password for root from 192.168.1.100

Wazuh includes built-in support for parsing these logs.

Systemd Journal Logs

Modern Linux distributions increasingly rely on systemd journaling.

Administrators can review SSH events using:

journalctl -u ssh

journalctl -u sshd

Wazuh can ingest and analyze journal-based authentication logs as well.

Authentication Subsystem Logs

Wazuh can also monitor authentication events generated by:

PAM
LDAP
Active Directory integrations
Kerberos
SSSD

This provides broader authentication visibility beyond the SSH daemon itself.

Default Wazuh Rules for SSH Monitoring

Wazuh ships with numerous built-in rules specifically designed to detect SSH-related threats.

Authentication Failure Detection

The most basic SSH detection rule identifies failed authentication attempts.

Example event:

Failed password for root from 203.0.113.25

Wazuh extracts:

Username
Source IP
Destination host
Timestamp
Authentication method

This information becomes searchable within the Wazuh dashboard.

Multiple Failed Login Attempts

Repeated authentication failures are often more significant than a single failed login.

Wazuh includes frequency-based rules that detect:

Multiple failures from the same IP
Repeated attacks against the same account
Rapid login attempts over short periods

These rules help identify brute-force activity before attackers gain access.

Root Login Attempts

Administrative accounts are common attack targets.

Wazuh specifically detects:

Failed password for root

and

Invalid user root

Repeated root-targeted authentication failures often warrant immediate investigation.

SSH Brute-Force Detection Rules

Wazuh contains built-in correlation rules designed to identify SSH brute-force attacks.

Typical indicators include:

Multiple failed logins
High authentication frequency
Repeated attempts against different accounts
Persistent attacks from a single source IP

When thresholds are exceeded, Wazuh generates higher-severity alerts that can trigger notifications or automated responses.

Once SSH attacks are detected, consider strengthening endpoint visibility with How to Configure File Integrity Monitoring (FIM) in Wazuh and How to Detect Ransomware Activity Using Wazuh.

Prerequisites

Before configuring SSH monitoring in Wazuh, ensure that your environment is properly set up.

Wazuh relies on authentication logs generated by Linux systems, so both the Wazuh infrastructure and monitored endpoints must be functioning correctly.

Environment Requirements

To follow this guide, you’ll need the following components:

A functioning Wazuh deployment
At least one Linux endpoint
The Wazuh agent installed on the endpoint
SSH enabled and running
Administrative privileges on both systems

Wazuh Server Installed

You should already have a working Wazuh server consisting of:

Wazuh Manager
Wazuh Indexer
Wazuh Dashboard

The manager is responsible for receiving and analyzing authentication logs generated by monitored systems.

If you’re building or scaling your deployment, see our How to Build a Wazuh Indexer Cluster guide.

Linux Endpoint with Wazuh Agent

The Linux system you want to monitor must have a Wazuh agent installed and connected to the manager.

Supported distributions include:

Ubuntu
Debian
CentOS
Rocky Linux
AlmaLinux
Red Hat Enterprise Linux
Amazon Linux

SSH Service Enabled

The SSH daemon must be installed and running on the monitored endpoint.

Verify SSH status using:

sudo systemctl status ssh

Ubuntu systems typically use:

ssh

While Red Hat-based systems often use:

sshd

Verify using:

sudo systemctl status sshd

Administrative Access

You’ll need administrative privileges to:

Modify agent configurations
Access authentication logs
Restart services
Generate test authentication events

Most commands throughout this guide require sudo access.

Verify Agent Connectivity

Before configuring SSH monitoring, confirm that the endpoint is actively communicating with the Wazuh manager.

Confirm Agent Registration

On the Wazuh Dashboard:

Navigate to Agents
Locate the Linux endpoint
Verify the agent appears in the inventory

You should see information such as:

Agent name
Operating system
IP address
Registration status

If the agent does not appear, log monitoring will not function correctly.

If your endpoint has not been enrolled yet, review How to Add Linux Endpoints to Wazuh.

Validate Agent Status

Healthy agents should display a status of:

Active

If the status shows:

Disconnected

Never connected

troubleshooting is required before proceeding.

Check Communication with the Manager

You can verify communication directly from the endpoint:

sudo systemctl status wazuh-agent

Expected output:

Active: active (running)

You can also review agent logs:

sudo tail -f /var/ossec/logs/ossec.log

Look for successful connection messages indicating communication with the manager.

If communication issues exist, see Wazuh Agent Not Connecting to Manager? 12 Proven Fixes.

Configuring Wazuh to Monitor SSH Authentication Logs

Most Linux agents automatically collect authentication logs, but it’s important to verify the configuration and ensure SSH events are being ingested properly.

Verify SSH Log Collection

The first step is confirming that SSH authentication events are being written to log files.

Locate SSH Authentication Logs

Authentication logs vary by Linux distribution.

Ubuntu / Debian

/var/log/auth.log

RHEL / CentOS / Rocky Linux

/var/log/secure

You can inspect recent entries using:

sudo tail -f /var/log/auth.log

sudo tail -f /var/log/secure

Confirm Logs Are Being Generated

Attempt an SSH login and verify that new entries appear.

Example:

Accepted password for admin from 192.168.1.10

Failed password for invalid user admin from 192.168.1.10

If no events appear, verify that:

SSH is running
System logging is functioning
Authentication logging is enabled

Review Sample Failed Login Events

Typical failed authentication events include:

Failed password for root from 203.0.113.50 port 54321 ssh2

Failed password for invalid user admin from 203.0.113.50 port 54321 ssh2

Failed publickey for user from 203.0.113.50

These are the events Wazuh will analyze and convert into alerts.

Configure Log Monitoring on Linux Agents

Next, verify that the Wazuh agent is monitoring the authentication logs.

Editing the Agent Configuration

Open the Wazuh agent configuration file:

sudo nano /var/ossec/etc/ossec.conf

Locate the existing <localfile> entries.

Adding Authentication Log Files

For Ubuntu and Debian systems:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

For RHEL-based systems:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/secure</location>
</localfile>

Many Wazuh installations already include these entries by default, but verification is recommended.

Monitoring Journal-Based Systems

Some Linux distributions primarily use systemd journals instead of traditional log files.

In these environments, you can configure journal monitoring using:

<localfile>
  <log_format>journald</log_format>
  <location>journald</location>
</localfile>

This enables Wazuh to collect authentication events directly from systemd.

Restart and Validate Agent Configuration

After making configuration changes, restart the agent.

Restarting the Wazuh Agent

Run:

sudo systemctl restart wazuh-agent

Verify service status:

sudo systemctl status wazuh-agent

Expected result:

active (running)

Verifying Successful Configuration Loading

Review the agent log:

sudo tail -f /var/ossec/logs/ossec.log

Look for startup messages confirming that log monitoring configurations have loaded successfully.

Any configuration errors should be corrected before proceeding.

Checking for Log Ingestion

Generate an SSH authentication event and then search for it in the Wazuh Dashboard.

Navigate to:

Security Events → Events

Search for:

sshd

authentication failure

If events appear, log collection is functioning correctly.

Generating Failed SSH Login Attempts for Testing

Before relying on production alerts, it’s important to verify that Wazuh is correctly detecting failed SSH authentication attempts.

Test Invalid Username Attempts

One of the easiest tests is attempting to log in using a non-existent account.

Simulating Failed Login Events

From another machine, run:

ssh fakeuser@your-server-ip

When prompted for a password, enter any value.

Expected Log Output

You should see entries similar to:

Failed password for invalid user fakeuser from 192.168.1.100

This confirms that authentication failures are being recorded.

Test Incorrect Password Attempts

Another common scenario involves using a valid username with an incorrect password.

Reproducing Authentication Failures

Run:

ssh validuser@your-server-ip

Enter an incorrect password.

Repeat the process several times.

Verifying Event Generation

Authentication logs should contain entries such as:

Failed password for validuser from 192.168.1.100

Multiple events should appear in both the local logs and the Wazuh dashboard.

Simulate Multiple Failed Attempts

To test brute-force detection rules, generate several failures within a short period.

Creating Brute-Force-Like Activity

For testing purposes, repeatedly attempt authentication using invalid credentials:

ssh admin@your-server-ip

Enter an incorrect password multiple times.

Alternatively, perform several separate connection attempts within a few minutes.

This produces a pattern similar to what automated attackers generate.

Testing Wazuh Detection Capabilities

After generating multiple failures:

Open the Wazuh Dashboard.
Navigate to Security Events.
Search for SSH-related alerts.
Review alert severity and triggered rules.

You should observe:

Authentication failure alerts
Repeated login attempt detections
Possible brute-force correlation alerts

These test events confirm that Wazuh is successfully monitoring SSH authentication activity and identifying suspicious login behavior.

Once you’ve confirmed SSH monitoring works correctly, you can learn how to validate and troubleshoot detections in How to Test Wazuh Rules.

Viewing Failed SSH Login Alerts in Wazuh

Once SSH authentication logs are being collected successfully, the next step is learning how to locate and analyze failed login alerts within the Wazuh Dashboard.

Proper alert analysis allows security teams to quickly identify brute-force attempts, investigate suspicious IP addresses, and determine whether an attack requires immediate action.

Accessing the Wazuh Dashboard

Open your Wazuh Dashboard by navigating to:

https://your-wazuh-dashboard

After authentication, you’ll have access to:

Security Events
Threat Hunting
Vulnerability Detection
File Integrity Monitoring
Agent Management

SSH-related alerts are primarily located within the Security Events section.

Navigating to Security Events

From the left navigation menu:

Open Security Events
Select Events

This view contains all alerts generated by the Wazuh rules engine.

Depending on your environment size, this page may contain thousands of events, making filtering essential.

Filtering SSH-Related Alerts

To focus on SSH activity, use search filters that target SSH daemon events.

Common filters include:

data.program_name:sshd

rule.groups:ssh

rule.description:ssh

These filters help isolate authentication-related events from other system activity.

Searching for Authentication Failures

Wazuh provides several methods for locating failed SSH logins.

Common Rule IDs

SSH authentication failures often trigger rules from the SSH monitoring rule set.

Examples may include:

Failed password attempts
Invalid user attempts
SSH authentication failures
SSH brute-force detections

The exact rule IDs may vary slightly between Wazuh versions, so reviewing the rule description is often more useful than memorizing rule numbers.

If you want to understand how rules work internally, see How to Create Custom Detection Rules in Wazuh (With Examples).

Useful Search Queries

Some useful dashboard searches include:

Failed password

Invalid user

authentication failure

sshd

You can also combine filters:

data.program_name:sshd AND level:[5 TO 15]

This displays higher-severity SSH alerts.

Filtering by Hostname or Agent

To investigate a specific system:

agent.name:web-server-01

agent.id:001

This helps identify whether authentication failures are isolated to a particular endpoint.

Understanding Alert Details

Selecting an alert opens detailed event information.

Several fields are particularly valuable during investigations.

Source IP Address

The source IP identifies where the login attempt originated.

Example:

203.0.113.55

This information helps determine:

Whether the source is internal or external
Whether the IP has a history of malicious activity
Whether blocking is appropriate

Target Username

The alert also identifies the account targeted by the attacker.

Examples:

root

admin

ubuntu

Repeated attacks against privileged accounts often indicate automated scanning or brute-force activity.

Timestamp Information

The event timestamp helps analysts determine:

When the attack started
Attack frequency
Correlation with other security events

Reviewing multiple timestamps often reveals attack patterns.

Rule Severity Levels

Wazuh assigns severity levels based on rule logic.

Typical classifications include:

Severity	Meaning
Low	Informational event
Medium	Suspicious activity
High	Potential attack
Critical	Significant security threat

Repeated SSH failures generally receive higher severity scores than isolated authentication mistakes.

Detecting SSH Brute-Force Attacks

One of the primary reasons organizations monitor failed SSH logins is to identify brute-force attacks before attackers successfully authenticate.

Wazuh includes built-in correlation capabilities that help distinguish normal user mistakes from malicious authentication activity.

How Brute-Force Detection Works in Wazuh

Rather than analyzing individual events in isolation, Wazuh evaluates patterns across multiple authentication failures.

Frequency-Based Detection

Frequency-based rules monitor how often authentication failures occur.

For example:

1 failed login may be normal.
2 failed logins may still be harmless.
20 failed logins in 60 seconds becomes suspicious.

Wazuh tracks these frequencies automatically.

Correlation Rules

Correlation rules analyze relationships between multiple events.

Examples include:

Same IP repeatedly failing authentication
Multiple usernames targeted by one source
Rapid authentication attempts over short periods

These rules help identify automated attack activity.

Thresholds and Timing Windows

Wazuh evaluates activity within configurable time periods.

Examples:

5 failures within 60 seconds
10 failures within 5 minutes
25 failures within 10 minutes

Once thresholds are exceeded, Wazuh generates elevated alerts.

Identifying Suspicious Login Patterns

Certain authentication patterns are strong indicators of malicious activity.

Multiple Usernames from One IP

Attackers frequently test multiple usernames from the same source.

Example:

root
admin
ubuntu
oracle
test

When these attempts originate from a single IP address, brute-force activity becomes more likely.

Repeated Failures Against One Account

An attacker may focus exclusively on a privileged account.

Example:

Failed password for root
Failed password for root
Failed password for root
Failed password for root

Repeated failures targeting a single account often warrant investigation.

Distributed Attack Indicators

Modern attacks sometimes originate from multiple IP addresses simultaneously.

Warning signs include:

Multiple source IPs
Same targeted username
Similar timestamps
Coordinated authentication failures

These attacks are more difficult to identify manually, making centralized monitoring especially valuable.

Investigating Attack Sources

After detecting suspicious activity, analysts should investigate the origin of the authentication attempts.

Reviewing Source IP Addresses

Start by reviewing:

Number of failed attempts
Targeted accounts
Frequency of activity
Historical behavior

Many attacks become obvious when viewed chronologically.

Geolocation Analysis

Source IPs can be enriched with geographic information to provide additional context.

Questions to consider:

Is the connection originating from an expected country?
Does the organization have users in that region?
Is the location consistent with normal access patterns?

Unexpected geographic locations may indicate malicious activity.

Threat Intelligence Integration

Threat intelligence feeds can identify whether an IP address has been associated with:

Botnets
Malware campaigns
Known scanners
Previous attacks

You can automate IP reputation lookups using How to Integrate Wazuh with VirusTotal for Threat Intelligence.

The SANS Institute recommends combining authentication monitoring with threat intelligence enrichment to improve detection accuracy and investigation speed.

Creating Custom Wazuh Rules for Failed SSH Logins

While Wazuh includes excellent built-in SSH detection capabilities, many organizations create custom rules to address environment-specific requirements.

Custom rules allow you to generate more relevant alerts while reducing unnecessary noise.

Why Create Custom Rules?

Custom rules help tailor monitoring to your organization’s unique infrastructure and security requirements.

Environment-Specific Monitoring

Every environment differs.

For example, one organization may allow root SSH access while another prohibits it entirely.

Custom rules allow you to enforce local security policies.

Enhanced Visibility

Additional rules can generate alerts for:

Specific usernames
Sensitive servers
High-risk IP ranges
Administrative accounts

This improves visibility into critical systems.

Reduced False Positives

Custom rules can suppress expected behavior while emphasizing genuinely suspicious activity.

If alert volume becomes excessive, review How to Reduce False Positives in Wazuh.

Example Custom Rule for SSH Failures

The following example creates a custom alert whenever a failed SSH authentication occurs.

Rule Structure Overview

Custom rules are typically added to:

/var/ossec/etc/rules/local_rules.xml

Matching Authentication Failure Events

Example rule:

<group name="custom_ssh_rules">

  <rule id="100500" level="8">
    <if_group>ssh</if_group>
    <match>Failed password</match>
    <description>Custom SSH authentication failure detected</description>
  </rule>

</group>

This rule generates an alert whenever a failed password event is detected.

Assigning Severity Levels

The severity level can be adjusted based on organizational requirements.

Examples:

Level 5  = Informational
Level 8  = Medium severity
Level 12 = High severity
Level 15 = Critical severity

Higher values produce more prominent alerts.

Creating High-Severity Alerts for Root Login Failures

Root account attacks often justify elevated alerting.

Detecting Root Account Targeting

Example rule:

<group name="custom_ssh_rules">

  <rule id="100501" level="12">
    <if_group>ssh</if_group>
    <match>Failed password for root</match>
    <description>Failed SSH login attempt against root account</description>
  </rule>

</group>

This rule specifically targets root authentication failures.

Escalating Critical Events

Organizations with strict security policies may choose to:

Send email notifications
Generate tickets
Trigger active response actions
Escalate incidents automatically

Root login attacks often warrant additional scrutiny.

Testing Custom Rules

Custom rules should always be validated before production deployment.

Rule Validation Process

Verify XML syntax:

sudo /var/ossec/bin/wazuh-logtest

This utility validates rule behavior before deployment.

Triggering Test Events

Generate a failed SSH login attempt:

ssh root@your-server-ip

Enter an invalid password.

Repeat several times if necessary.

Confirming Alert Generation

After testing:

Open the Wazuh Dashboard.
Navigate to Security Events.
Search for the custom rule ID.
Verify the alert appears with the expected severity.

Configuring Active Response for SSH Attacks

Detecting failed SSH login attempts is only part of the security process.

To reduce risk, organizations often want Wazuh to automatically respond to suspicious authentication activity.

Wazuh’s Active Response framework allows security teams to take immediate action against attackers without requiring manual intervention.

What Is Wazuh Active Response?

Active Response is a Wazuh feature that executes predefined actions when specific security events occur.

Instead of simply generating an alert, Wazuh can automatically:

Block malicious IP addresses
Terminate processes
Disable compromised accounts
Run custom scripts
Integrate with external security tools

This helps reduce the time between detection and mitigation.

According to the National Institute of Standards and Technology, automated response capabilities are an important component of modern security operations because they improve response times and reduce the impact of attacks.

Automated Threat Mitigation

Active Response is particularly valuable for SSH attacks because brute-force campaigns often generate hundreds or thousands of authentication failures in a short period.

Instead of waiting for an analyst to intervene, Wazuh can:

Identify the attacking IP
Trigger a response action
Block future connections
Generate an audit trail

This minimizes the attacker’s opportunity to gain access.

Supported Response Actions

Wazuh includes several built-in response mechanisms.

Common actions include:

Firewall blocking
IP blacklisting
Process termination
Account lockout
Custom script execution

Organizations can also create custom Active Response scripts tailored to their environment.

Automatically Block Malicious IP Addresses

One of the most common SSH response actions is blocking the source IP address responsible for repeated authentication failures.

Integrating Firewall Rules

Wazuh can integrate with Linux firewall technologies such as:

iptables
nftables
firewalld
UFW

When an SSH brute-force rule is triggered, Wazuh can automatically insert a blocking rule.

Example firewall action:

iptables -A INPUT -s 203.0.113.55 -j DROP

This immediately prevents additional connection attempts from the attacking host.

Temporary IP Blocking

Permanent blocking may not always be desirable.

Many organizations configure temporary bans such as:

5 minutes
15 minutes
1 hour
24 hours

Temporary blocks reduce attack activity while minimizing the risk of accidentally blocking legitimate users.

Response Workflow

A typical SSH Active Response workflow looks like:

Attacker generates multiple failed logins.
Wazuh detects the pattern.
A brute-force rule is triggered.
Active Response executes.
Firewall rules are updated.
The source IP is blocked.
Security alerts are generated.

This entire process can occur within seconds.

If you’re creating custom SSH detections, see How to Create Custom Detection Rules in Wazuh (With Examples).

Testing Active Response Actions

Before deploying Active Response in production, validate that it functions correctly.

Simulating Attacks

Generate multiple failed login attempts from a test machine:

ssh admin@server-ip

Use invalid credentials repeatedly until the brute-force threshold is reached.

This should trigger both detection and response workflows.

Verifying Automated Blocking

After the attack simulation:

Check firewall rules:

sudo iptables -L

sudo nft list ruleset

Verify that the source IP appears in the blocked list.

You should also see Active Response events within the Wazuh Dashboard documenting the action that was taken.

Visualizing SSH Login Failures in Wazuh Dashboards

Collecting authentication data is useful, but dashboards make it much easier to identify trends, recurring attacks, and high-risk systems.

Wazuh dashboards allow security teams to transform raw authentication logs into actionable security insights.

Creating SSH Monitoring Dashboards

Organizations that regularly monitor Linux infrastructure should create dedicated SSH monitoring dashboards.

These dashboards can provide visibility into:

Authentication activity
Failed login attempts
Brute-force attacks
User access patterns
Security trends

Authentication Activity Overview

A high-level dashboard should include:

Total SSH logins
Successful authentications
Failed authentications
Authentication success rate

This provides a quick overview of overall SSH activity.

Failed Login Trends

Authentication failures often increase before a security incident occurs.

Visualizing failures over time can help identify:

Attack campaigns
Scanning activity
Misconfigured systems
User training issues

Trend analysis is often more valuable than examining individual alerts.

Useful SSH Security Metrics

The following metrics are commonly included in SSH monitoring dashboards.

Failed Login Attempts Per Host

This visualization helps identify:

Systems under attack
Externally exposed servers
Misconfigured authentication services

Hosts generating unusually high authentication failure counts should be investigated.

Top Targeted Usernames

Attackers frequently target predictable usernames such as:

root
admin
ubuntu
oracle
test

Monitoring targeted accounts helps identify attack patterns and potential weaknesses.

Top Attacking IP Addresses

A ranking of source IPs generating authentication failures can quickly reveal:

Brute-force attacks
Automated scanners
Persistent attackers

This metric is particularly useful for firewall tuning and threat hunting.

Authentication Failure Trends

Tracking authentication failures across days, weeks, and months can reveal:

Seasonal attack activity
Long-term threat trends
Changes in exposure levels
Security control effectiveness

Building Security Reports

In addition to dashboards, many organizations generate recurring authentication reports.

Daily Authentication Summaries

Daily reports often include:

Total failed logins
Top attacking IPs
Most targeted accounts
High-severity alerts

These summaries provide operational visibility for security teams.

Weekly Security Reports

Weekly reports typically focus on broader trends:

Authentication volumes
Brute-force activity
Newly observed attackers
Changes in attack frequency

This information supports security planning and risk assessments.

Compliance Reporting

Many compliance frameworks require evidence of authentication monitoring.

Examples include:

PCI DSS
SOC 2
ISO 27001
NIST-based controls

Authentication reports can provide auditors with evidence that login activity is being monitored and reviewed.

Organizations that must retain authentication logs for compliance should also review How to Configure Wazuh Log Retention.

Troubleshooting SSH Login Monitoring Issues

Even when SSH monitoring is configured correctly, issues can occasionally prevent alerts from appearing in Wazuh.

The following troubleshooting steps help identify and resolve the most common problems.

No SSH Alerts Appearing

If authentication failures are occurring but no alerts are generated, start by verifying log collection.

Log Collection Issues

Check whether SSH events are present in the authentication logs.

Ubuntu and Debian:

sudo tail -f /var/log/auth.log

RHEL-based systems:

sudo tail -f /var/log/secure

If no SSH events appear, the issue exists at the operating system level rather than within Wazuh.

Agent Configuration Problems

Review the agent configuration file:

sudo nano /var/ossec/etc/ossec.conf

Verify that the correct authentication log file is configured under the <localfile> section.

Restart the agent after making changes.

Missing Log Permissions

The Wazuh agent must have permission to read authentication logs.

Verify file permissions:

ls -l /var/log/auth.log

ls -l /var/log/secure

Permission issues can prevent log ingestion entirely.

Logs Collected but No Alerts Generated

Sometimes logs are successfully collected but fail to generate alerts.

Rule Matching Problems

If SSH logs do not match existing rules, no alerts will appear.

Use the Wazuh testing utility:

sudo /var/ossec/bin/wazuh-logtest

Paste sample SSH events to verify rule matching behavior.

Decoder Issues

Wazuh relies on decoders to parse log entries.

If a decoder fails:

Fields may not be extracted
Rules may not match
Alerts may not be generated

Review the decoder output within logtest to verify proper parsing.

Event Parsing Validation

Use representative SSH log samples during testing.

Example:

Failed password for root from 203.0.113.55 port 45212 ssh2

Verify that Wazuh correctly extracts:

Source IP
Username
Event type
Authentication status

SSH Logs Missing from the Dashboard

If events are being collected but do not appear in the dashboard, investigate indexing and display issues.

Indexing Delays

Large environments may occasionally experience indexing delays.

Check:

Wazuh Indexer health
Cluster status
Resource utilization

Indexing bottlenecks can delay event visibility.

Data Retention Settings

Events may be deleted if retention settings are too aggressive.

Review:

Index lifecycle policies
Retention configuration
Storage limits

Authentication logs should remain available long enough to support investigations and compliance requirements.

Dashboard Filter Issues

Sometimes events exist but are hidden by active filters.

Verify:

Time range selections
Agent filters
Severity filters
Search queries

Removing filters often reveals missing events.

Active Response Not Triggering

If alerts are generated but automated responses never execute, review the Active Response configuration.

Configuration Validation

Verify that:

Active Response is enabled
The correct rule IDs are referenced
The response action exists
The configuration syntax is valid

Restart Wazuh services after making changes.

Firewall Integration Issues

Firewall-based responses require proper integration.

Confirm that:

iptables or nftables is installed
Required firewall services are running
Response scripts execute successfully

Testing manually can help isolate problems.

Permission Problems

Active Response scripts often require elevated privileges.

Verify:

Script permissions
Execution rights
Sudo configuration
Service account permissions

Insufficient privileges are one of the most common causes of Active Response failures.

If Active Response relies on threat intelligence decisions, you may also find How to Integrate Wazuh with VirusTotal for Threat Intelligence useful for enrichment and investigation workflows.

Best Practices for Monitoring Failed SSH Login Attempts

Configuring Wazuh to monitor SSH authentication failures is an excellent first step, but effective security requires a broader strategy.

By combining proper monitoring, alert tuning, access controls, and system hardening, organizations can significantly reduce the risk of successful SSH attacks.

Disable Password-Based Authentication

One of the most effective ways to reduce SSH-related attacks is eliminating password authentication entirely.

Attackers commonly rely on:

Brute-force attacks
Credential stuffing
Password spraying
Stolen passwords

Without password authentication, these attack techniques become significantly less effective.

Benefits of SSH Key Authentication

SSH key authentication uses a public-private key pair rather than a password.

Advantages include:

Stronger authentication
Resistance to brute-force attacks
Improved security for administrators
Reduced risk of credential theft

Example SSH configuration:

PasswordAuthentication no
PubkeyAuthentication yes

The OpenSSH Project recommends public key authentication as a security best practice for administrative access.

OpenSSH Documentation: https://www.openssh.com/

Reducing Brute-Force Exposure

Disabling password authentication dramatically reduces the number of successful attack paths available to threat actors.

Even if attackers discover:

Server IP addresses
Valid usernames
Open SSH ports

Authentication remains impossible without possession of the corresponding private key.

Monitor Root Login Attempts

Root account targeting is one of the strongest indicators of malicious SSH activity.

Detecting Privileged Account Targeting

Attackers frequently target usernames such as:

root
admin
administrator
oracle
ubuntu

Repeated authentication failures involving privileged accounts should always be investigated.

Many organizations create dedicated Wazuh alerts specifically for root login attempts.

Escalating Critical Events

Root authentication failures often warrant higher severity levels than standard user account failures.

Examples include:

Immediate notifications
Ticket creation
Active Response actions
Security operations escalation

Custom escalation rules can be implemented using How to Create Custom Detection Rules in Wazuh (With Examples).

Use Active Response Carefully

Active Response can automatically mitigate attacks, but overly aggressive configurations can create operational issues.

Avoiding Accidental Lockouts

Legitimate users occasionally mistype passwords.

If Active Response triggers too quickly, administrators may accidentally block:

Employees
Contractors
Automated systems
Monitoring services

Always test response actions thoroughly before production deployment.

Establishing Response Thresholds

Reasonable thresholds often work better than aggressive ones.

Examples:

Failed Attempts	Response
3	Generate alert
5	Increase severity
10	Trigger Active Response
20+	Escalate incident

Organizations should adjust thresholds based on risk tolerance and user behavior.

Implement Alert Tuning

Not every failed login attempt is malicious.

Proper tuning helps security teams focus on meaningful threats.

Reducing False Positives

Common sources of SSH false positives include:

Forgotten passwords
Automated scripts
Configuration errors
Service account issues

Reducing unnecessary alerts helps analysts identify genuine attacks more quickly.

Internal Link: For additional tuning techniques, see How to Reduce False Positives in Wazuh.

Customizing Detection Thresholds

Organizations should customize:

Alert severity levels
Frequency thresholds
Correlation rules
Response actions

Tailoring detections to your environment typically improves both accuracy and usability.

Combine Wazuh with Additional SSH Hardening

Monitoring alone is not sufficient. Security improves significantly when Wazuh is combined with additional SSH hardening measures.

Fail2Ban Integration

Fail2Ban automatically blocks IP addresses that generate repeated authentication failures.

Benefits include:

Reduced attack volume
Automated mitigation
Lightweight deployment
Additional protection layer

Fail2Ban and Wazuh often complement one another effectively.

Multi-Factor Authentication

Multi-factor authentication (MFA) requires users to provide an additional verification factor.

Common examples include:

Authentication apps
Hardware security keys
One-time passcodes

MFA significantly reduces the effectiveness of stolen credentials.

The Cybersecurity and Infrastructure Security Agency recommends MFA as one of the most effective defenses against account compromise.

IP Allowlisting

Organizations can further reduce exposure by restricting SSH access to trusted networks.

Examples include:

Corporate VPNs
Administrative subnets
Bastion hosts
Specific office locations

This approach dramatically reduces the number of systems capable of initiating SSH connections.

If suspicious activity is detected despite these controls, consider enhancing investigations with How to Integrate Wazuh with VirusTotal for Threat Intelligence.

Frequently Asked Questions

Question: Does Wazuh Detect SSH Brute-Force Attacks Automatically?

Yes. Wazuh includes built-in SSH detection rules capable of identifying repeated authentication failures, brute-force activity, and suspicious login patterns.

These rules use event correlation and frequency analysis to distinguish normal user mistakes from attack behavior.

Question: Which SSH Log Files Does Wazuh Monitor?

The specific log file depends on the Linux distribution.

Ubuntu and Debian

/var/log/auth.log

CentOS, Rocky Linux, AlmaLinux, and RHEL

/var/log/secure

Wazuh can also monitor systemd journal logs and other authentication-related log sources.

Question: Can Wazuh Block Attackers After Multiple Failed Logins?

Yes. Wazuh Active Response can automatically execute response actions when SSH brute-force activity is detected.

Common actions include:

IP blocking
Firewall rule creation
Script execution
Incident escalation

The exact behavior depends on your Active Response configuration.

Question: How Do I Monitor SSH Login Attempts on Ubuntu?

On Ubuntu systems:

Install the Wazuh agent.
Ensure /var/log/auth.log is monitored.
Verify SSH events are being generated.
Confirm alerts appear in the Wazuh Dashboard.

Ubuntu authentication failures are typically recorded automatically by the SSH daemon.

Question: How Do I Monitor SSH Login Attempts on CentOS or RHEL?

On CentOS, Rocky Linux, AlmaLinux, and RHEL systems:

Install the Wazuh agent.
Monitor /var/log/secure.
Generate test authentication failures.
Validate event ingestion and rule matching.

The monitoring process is largely identical to Ubuntu deployments.

Question: What Wazuh Rule IDs Are Commonly Associated with SSH Authentication Failures?

Wazuh includes multiple built-in SSH detection rules that may vary slightly across versions.

Common categories include:

Failed password attempts
Invalid user attempts
Authentication failures
SSH brute-force detections
Root login attempts

The most reliable approach is to review the rule description within the generated alert rather than relying solely on rule numbers.

Question: Can Wazuh Detect Successful SSH Logins as Well?

Yes.

Wazuh can monitor both:

Failed authentication events
Successful authentication events

Tracking successful logins helps security teams:

Audit user activity
Identify unusual access patterns
Investigate potential compromises
Meet compliance requirements

Question: How Do I Reduce False Positives in SSH Monitoring?

Several techniques can reduce false positives:

Tune alert thresholds
Exclude known automation accounts
Create environment-specific rules
Adjust severity levels
Use correlation-based detections

Conclusion

Monitoring failed SSH login attempts is one of the most effective ways to identify unauthorized access attempts against Linux systems.

Because SSH is commonly targeted by brute-force attacks, credential stuffing campaigns, and password spraying techniques, visibility into authentication failures is essential for maintaining a strong security posture.

Throughout this guide, we’ve covered how Wazuh collects SSH authentication logs, analyzes failed login events, detects brute-force activity, generates alerts, and supports automated response actions.

We also explored dashboard visualizations, custom rule creation, troubleshooting techniques, and SSH security best practices.

Early detection of authentication failures provides several important benefits:

Faster identification of attack activity
Improved incident response capabilities
Better compliance visibility
Reduced risk of unauthorized access
Enhanced protection for privileged accounts

By combining Wazuh monitoring with Active Response, SSH key authentication, multi-factor authentication, IP allowlisting, and proper alert tuning, organizations can significantly strengthen their defenses against SSH-based attacks.

As a next step, consider expanding your monitoring strategy by implementing:

Together, these capabilities help transform Wazuh from a simple log monitoring platform into a comprehensive security monitoring and threat detection solution for Linux environments.