Stay Ahead With Linux Security HOWTOs
How to Secure My Network
network security Linux administration
network security Linux administration Open ports have a way of accumulating over time. A test environment gets deployed and never removed. An administrative interface is exposed for troubleshooting and left in place. A database that was supposed to listen internally ends up reachable from the internet. . Attackers look for these mistakes constantly. Redis, Elasticsearch, MongoDB, Jenkins, and similar services still show up on internet-facing systems where they were never meant to be exposed. Sometimes it's a temporary change that...
Jun 10, 2026 
How to Secure My Networksecurity advisory intrusion detection
security advisory intrusion detection A compromised Linux server can continue running malware long after the initial intrusion. One of the most common persistence techniques is a malicious cron job that silently downloads payloads, restarts malware, or re-establishes attacker access every few minutes. This guide shows how to identify suspicious cron entries, preserve forensic evidence, remove unauthorized scheduled tasks, and verify that no additional persistence mechanisms remain. . What Should You Save Before Removing Cron Jobs...
Jun 09, 2026 
How to Secure My Networkaccess control Linux administration
access control Linux administration Most SSH hardening advice ends at the same recommendation: Disable password authentication and use SSH keys. . That's good advice. It removes entire classes of attacks, including password spraying, credential stuffing, and brute-force attempts against exposed servers. The problem is what happens next. Many administrators treat SSH keys as the finish line when they are really the beginning of the hardening process. Attackers rarely care whether they obtained access with a password or a private...
Jun 05, 2026 
How to Secure My Networksecurity advisory remote access
security advisory remote access Most of the time, nobody notices. SSH authentication succeeds, no alerts are generated, and the connection looks exactly the way it did the day the key was installed. That's part of the problem. . When security teams investigate unauthorized access on Linux systems, they often focus on passwords, exposed services, or vulnerable software. Trusted access receives less attention. Yet a single forgotten or unauthorized SSH key can provide the same access as a legitimate user while attracting very...
Jun 03, 2026 
How to Secure My Networkintrusion detection application security
intrusion detection application security The wrong IPS rule can look like a security fix right up until it becomes an outage. . On Linux systems, detection and prevention are often discussed together, but they do not carry the same operational risk. One tells admins that something suspicious happened. The other can decide whether traffic is allowed to continue. That is why IDS vs IPS is not just a definition to memorize. It is a deployment decision about where to monitor, where to block, and how much confidence a team needs before...
Jun 01, 2026 
Refine HOWTOs
X Clear Filters Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security HOWTOs
We found -3 articles for you...
167
unauthorized accesssecurity techniquesSSHHow To Understand Failed Authentication Patterns in Linux Logs
Exposed SSH servers are continuously hammered by brute-force attacks, password spraying, credential stuffing, and recycled passwords from infostealer dumps. Attackers rotate usernames, test weak credentials, and probe for anything that gives them initial access. The logs usually look messy long before the compromise happens. . The difficult part is separating harmless failures from actual intrusion activity. One failed login from an internal workstation rarely matters. Repeated failures against privileged accounts from cloud VPS ranges usually do. Especially when sudo activity or successful authentication starts appearing afterward. This guide walks through how failed authentication activity appears in Linux SSH and PAM logs, how brute-force attacks differ from password-spraying operations, and how administrators surface suspicious login patterns before attackers establish persistence or reach root access. Raw auth logs get noisy fast. Understand Where Linux Authentication Logs Are Stored Linux distributions store authentication events in different locations depending on the platform. Debian and Ubuntu systems typically write authentication logs to: /var/log/auth.log RHEL, CentOS, AlmaLinux, and Rocky Linux systems usually use: /var/log/secure Modern Linux systems running systemd may also expose authentication activity directly through the system journal: journalctl -u ssh Authentication logs usually contain entries generated by both the SSH daemon ( sshd ) and PAM, which stands for Pluggable Authentication Modules. They appear together because SSH relies on PAM during the authentication process itself. SSH handles the network connection. PAM handles authentication checks, account validation, session management, and policy enforcement. That’s why one SSH login attempt can generate multiple related log entries within seconds. New administrators often think the logs are duplicated at first. They aren’t. Authentication logs generally contain four types of events: Failed login attempts Successful logins Session openings and closures Privilege escalation activity through sudo or su One of the most common ways administrators monitor authentication activity is by tailing logs in real time. sudo tail -f /var/log/auth.log Or on RHEL-based systems: sudo tail -f /var/log/secure “Tailing” logs simply means watching new log entries appear live as the file updates. Authentication events are chronological, so the newest events appear at the bottom. This helps administrators observe SSH activity while reproducing login attempts or investigating suspicious behavior. You can also review SSH-specific events through the journal: journalctl -u ssh That becomes useful on systems where older logs rotate quickly or where journald stores events centrally instead of relying entirely on flat files. Learn What Normal Failed Login Activity Looks Like Most failed authentication events are harmless. Linux systems generate routine login failures constantly during normal operations. Users mistype passwords. Somebody tries the wrong SSH username. A scheduled task continues using an old password after credentials change. Service accounts fail periodically when applications restart with outdated secrets. It happens everywhere. A normal failed SSH login often looks like this: Failed password for john from 192.168.1.25 port 51122 ssh2 You’ll usually see a related PAM entry nearby: pam_unix(sshd:auth): authentication failure; user=john These entries typically belong to the same authentication attempt. SSH records the failed password event while PAM records the internal authentication failure generated during credential validation. A single failed password attempt is common and usually harmless. Administrators should focus more on frequency, repetition, timing, and source behavior instead of isolated events. One failed login from an internal workstation rarely matters. Repeated failures against multiple accounts fromunfamiliar external IP addresses matter a lot more. Authentication logs also help administrators monitor long-term patterns. Repeated failures tied to the same system, user account, or subnet often reveal configuration problems before they become security issues. Sometimes broken automation looks almost identical to credential abuse at first glance. How to Detect Brute Force Attempts in SSH Logs Brute force attacks are usually easy to recognize once the pattern becomes repetitive. Attackers repeatedly attempt passwords against the same account until something works or the target blocks further access. Internet-facing Linux servers see this constantly. Especially SSH services exposed directly to the public internet. Administrative accounts like root get targeted heavily because attackers already know the username exists on many Linux systems. They only need to guess the password. Brute force activity often looks like this: Failed password for root from 185.220.101.4 port 55872 ssh2 Failed password for root from 185.220.101.4 port 55881 ssh2 Failed password for root from 185.220.101.4 port 55903 ssh2 The source IP remains consistent while the connection port changes with each new SSH attempt. That’s normal behavior because every SSH connection opens a separate session. Administrators usually start by searching for failed password events directly: grep "Failed password" /var/log/auth.log To focus specifically on root targeting: grep "Failed password for root" /var/log/auth.log This becomes more useful when combined with IP aggregation: awk '/Failed password/ {print $(NF-3)}' /var/log/auth.log | sort | uniq -c That command extracts source IP addresses from failed authentication entries, sorts them, and counts how often each address appears. Repeated login attempts from the same external IP usually stand out quickly. What matters operationally is repetition. One failed SSH login is normal. Hundreds of failures targeting the same administrativeaccount from the same host usually indicate automation. The MITRE ATT&CK framework tracks brute force authentication abuse under T1110 Brute Force . MITRE documents how attackers automate password guessing against exposed services, administrative accounts, and remote access infrastructure. The behavior described there closely matches what administrators see inside Linux authentication logs during active SSH attacks. Attackers automate these attempts because eventually, weak passwords work. Especially on systems that were not hardened properly after deployment. How to Identify Password Spraying in Linux Authentication Logs Password spraying looks different from traditional brute force activity. Instead of attacking one account repeatedly with many passwords, attackers try a small number of passwords across many usernames. Slower. Quieter too. The goal is to avoid account lockouts while testing reused credentials at scale. Many lockout policies trigger after repeated failures against a single account. Password spraying sidesteps that problem by rotating usernames instead. A spraying attempt may look like this: Failed password for admin from 203.0.113.44 Failed password for backup from 203.0.113.44 Failed password for finance from 203.0.113.44 One source IP rotates through multiple usernames carefully over time. Attackers often target predictable accounts first: admin backup finance support deploy test Administrators can start reviewing spraying behavior with simple searches: grep "Failed password" /var/log/auth.log | awk '{print $11}' Or broader sorting: grep "Failed password" /var/log/auth.log | sort Timestamps matter heavily during spraying investigations. Attackers intentionally spread attempts across longer periods to remain below alert thresholds and avoid triggering lockout policies. Ten failures over an hour often attract less attention than ten failures in thirty seconds, even though the intent is the same. This is why authentication logs should always be reviewed as sequences instead of isolated events. Password spraying tends to look subtle until someone lines up the timestamps properly. How to Investigate Stolen Credential Abuse Failed authentication attempts become much more serious once attackers successfully log in. At that point, the investigation shifts from attempted access to potential compromise. A successful SSH login following repeated failures deserves immediate review. Example: Accepted password for backupadmin from 203.0.113.44 port 60211 ssh2 Then shortly afterward: sudo: session opened for user root That sequence matters because attackers frequently escalate privileges immediately after gaining initial access. Especially if compromised accounts already have sudo access or weak privilege restrictions. Administrators investigating suspicious authentication activity usually begin with successful login searches: grep "Accepted password" /var/log/auth.log Then review privilege escalation events: grep "session opened" /var/log/auth.log A practical investigation workflow usually looks like this: Review failed logins leading up to successful authentication Identify the originating IP address Compare timestamps between failures and successful access Review sudo activity and privilege escalation Determine whether the behavior matches normal operational patterns Suspicious login timing often becomes a strong indicator. Administrative accounts authenticating at unusual hours from unfamiliar IP addresses deserve attention, even if the credentials themselves were valid. Research from Elastic Security Labs and Splunk Security Research consistently emphasizes correlating failed and successful authentication activity together instead of reviewing them independently. Rapid privilege escalation, abnormal login velocity, and suspicious authentication sequencing frequently appear during SSH compromise investigations. This iswhere authentication logs stop being troubleshooting data and start becoming incident response evidence. Understand PAM Authentication Failure Messages PAM messages confuse many administrators because the entries look verbose and disconnected from normal SSH logging. They actually provide useful context once you understand how PAM works during authentication. PAM, or Pluggable Authentication Modules, handles authentication processing for many Linux services, including SSH. During login attempts, PAM modules validate credentials, apply account restrictions, enforce authentication policies, and create sessions. That’s why PAM entries appear beside SSH daemon logs constantly. A typical PAM authentication failure looks like this: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh A successful session creation may appear like this: pam_unix(sshd:session): session opened for user john Administrators commonly search PAM-specific activity using: grep "pam_unix" /var/log/auth.log Or through the system journal: journalctl | grep pam PAM logs supplement SSH logs by showing different stages of authentication processing. One SSH login attempt may generate multiple PAM events, including: authentication failure user validation session opened session closed This is normal behavior. PAM modules log actions separately as the authentication process moves through different stages internally. Beginners often assume multiple PAM entries indicate multiple login attempts. Usually, they belong to the same session sequence instead. The Red Hat PAM documentation explains how PAM modules generate authentication and session events during login processing. Understanding those stages helps administrators interpret Linux authentication logs more accurately during both troubleshooting and security investigations. PAM fills gaps that SSH logging alone doesn’t always explain clearly. How to Respond to Suspicious Authentication Activity Once suspicious authentication behavior appears, response speed matters. Attackers rarely stop after gaining initial access. Start by identifying exposed or compromised accounts. Disable accounts showing suspicious activity until the investigation finishes. sudo passwd -l username Review whether Fail2Ban or equivalent rate-limiting protections are active: sudo systemctl status fail2ban Then inspect the SSH daemon configuration d irectly: sudo nano /etc/ssh/sshd_config Several SSH settings reduce exposure significantly: PermitRootLogin no PasswordAuthentication no Disabling password authentication forces SSH key usage instead of credential-based logins. Restricting direct root login removes one of the most heavily targeted accounts from external authentication attempts entirely. Administrators should also review: sudo rules firewall restrictions privileged accounts dormant users MFA coverage SSH key management IP-based access restrictions help reduce the attack surface further on systems that only require administrative access from trusted locations. Continuous log monitoring matters too. Authentication abuse usually escalates gradually. Attackers test footholds quietly first, then move toward privilege escalation once they understand the environment. Most compromises leave warning signs in the logs long before defenders notice the breach itself. Conclusion Failed authentication attempts happen on every Linux system. Most is harmless operational noise. The patterns behind those failures often reveal much more. Brute-force attacks, password-spraying campaigns, and stolen-credential abuse all leave traces in SSH and PAM logs before attackers establish persistence or gain root access. Administrators who understand those patterns can investigate suspicious activity more quickly and reduce the chances of unauthorized access going unnoticed. Authentication logs become far more useful once you stop reading individual entries andstart tracking behavior over time. Repetition matters. Timing matters. Successful logins after repeated failures matter even more. Linux logs look chaotic initially. Eventually, the attack patterns start standing out on their own. Want more Linux security guidance, threat analysis, and hardening tutorials delivered directly to your inbox? Subscribe to the LinuxSecurity.com newsletter for practical updates, emerging threat coverage, and operational Linux administration tips. Related Reading Fail2ban Linux Security Brute Force Protection and Monitoring PAM: Important Risks in Linux Authentication Trust Chain Essential Log Management Tools for Effective Linux Security Detecting Lateral Movement on Linux Systems Without EDR Securing Remote Access to Linux Servers: Best Practices for 2026 . Learn to identify and respond to failed authentication patterns in Linux logs to enhance your security posture effectively.. Linux Security, Authentication Logs, Access Monitoring. . MaK Ulac
May 28, 2026 •
How to Secure My Network 166
unauthorized accessserver protectionssh securityEssential Guide to Protecting SSH Using Fail2Ban for Beginners
Dive into our beginner’s guide on securing SSH with Fail2Ban to safeguard your server from unauthorized access and brute-force attacks. . We will start with a metaphor. Imagine a fortress; while its tall walls and strong gates are built to keep out unwanted visitors, there will always be those who attempt to scale the walls or force the gates. Similarly, our digital fortress, especially servers, faces persistent threats. One such gate to it is the Secure Shell (SSH), a protocol allowing secure remote access. So, just as gates require guards and monitoring systems, SSH requires protective measures against potential intruders. Enter Fail2Ban – a vigilant sentry for your servers. It is one of the most effective shields against unauthorized access attempts, especially brute force. . Explore the methods to enhance your SSH security using Fail2Ban, and shield your server against unauthorized access and brute-force attacks.. SSH Security, Fail2Ban Implementation, Server Protection, Unauthorized Access. . Brittany Day
Nov 02, 2023 • How to Learn Tips and Tricks 
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More