If you manage a Linux server sooner or later you will notice something strange in your authentication logs. There may be failed login attempts in a few minutes requests for usernames that you have never created or a successful login from an IP address that you do not recognize.
These events are common on Linux servers exposed to the internet. Automated bots regularly scan public IP addresses. Try common usernames and passwords. Most attempts fail,. That does not mean that every Linux server is safe.
The important question is whether someone actually gained access to the Linux server.
In this guide we will look at how to investigate SSH activity, on a Linux server identify unusual login patterns check for signs of unauthorized access and secure the Linux server afterward. The examples use Ubuntu and Debian although most of the techniques also apply to Linux distributions.
1. Start by Checking the Authentication Logs
Before changing anything look at what the Linux server has recorded. On Ubuntu and Debian SSH authentication events are usually written to /var/log/auth.log.
Run:
sudo tail -n 100 /var/log/auth.logThis shows the 100 lines of the authentication log. Look for repeated failed attempts usernames you do not recognize and any successful logins that seem out of place.
If you want to see entries as they happen use:
sudo tail -f /var/log/auth.logPress control c when you want to stop.
Not every Linux system saves authentication events in this file. On systems that use systemd you can check the journal directly.
sudo journalctl -u ssh --since "24 hours ago"Depending on the distribution, the service might be called sshd rather than ssh.
You can also narrow the search to a particular period:
sudo journalctl -u ssh \
--since "2026-10-12 18:00:00" \
--until "2026-10-12 23:00:00"Replace the example dates with the time of the suspected activity.
This is a starting point because it gives you a timeline. If a server started receiving requests at 20:00 for example you can compare those events with successful logins and any system changes around the same time.
2. Find Failed Login Attempts
Once you have located the logs search, for failed passwords and attempts involving accounts.
On Ubuntu or Debian use:
sudo grep -E "Failed password|Invalid user" /var/log/auth.logYou might see an entry similar to this:
Oct 12 20:14:03 server sshd[18421]: Failed password for invalid user admin from 203.0.113.45 port 52144 ssh2This is an example log entry. The IP address is part of a range that is used for documentation purposes.
The message shows that an SSH client tried to log in as admin. The server did not know about that user. The password attempt did not work.
One single entry does not give information. The same message appearing times in a short time is more important.
Look closely at the usernames that are being tried. Accounts like admin, root, test and ubuntu are often attacked by automated systems. You might also see usernames that're not related to your server at all.
A lot of requests for usernames usually means automated scanning is happening. Still not every failed login is a thing. A system that is monitoring with passwords or an administrator using the wrong account can cause similar messages.
The other events around the log entry are more important, than one line.
3. Find Out Which IP Addresses Are Generating the Most Failures
When the authentication log has thousands of entries looking at each one is not possible. A simple command can help find the common sources.
Run:
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20
The command extracts the source IP address from standard OpenSSH failed-password messages, counts how often each address appears, and sorts the results by frequency.
For example:
245 203.0.113.45
87 198.51.100.22
14 192.0.2.604. Did Anyone Actually Get In?
Failed logins are noise. What you really care about is the one that worked.
sudo grep "Accepted" /var/log/auth.logA successful public-key login might look like this:
Oct 12 20:21:11 server sshd[18510]: Accepted publickey for deploy from 198.51.100.25 port 53321 ssh2So deploy
logged in with a key. Fine, but ask yourself three things. Should that account be logging in at 8 p.m.? Is that IP one of yours, say your office, your VPN, or your CI box? And is key auth even supposed to be on for this user?
An IP you don’t recognize isn’t an automatic red flag. People travel, VPNs rotate, and cloud tools connect from all over.
But an unexplained success is the thing to chase.
Two more commands help for history:
last -aisudo lastb -ai
The first lists successful sessions and the second lists failed ones, though lastb only works if /var/log/btmp exists on your box. Don’t trust either one fully. Logs rotate, and if someone got root, they can edit them. If you think that happened, look at a remote log copy instead of the local files.
5. Look at the Account They Used
Say you found a login you can’t explain. Start with the account:
getent passwd deployCheck the home directory and shell. Was this account created recently? Did its shell change? If so, find out why before you assume it’s harmless.
Then look at the keys, because that’s where attackers like to leave a backdoor:
sudo cat /home/deploy/.ssh/authorized_keysAny key you can’t match to a person or a service deserves a hard look. It might still be legitimate (old deploy keys get forgotten constantly), but you should know whose it is.
Then pull the journal around the login time:
sudo journalctl \
--since "2026-10-12 20:00:00" \
--until "2026-10-12 22:00:00"Look for service restarts changes to authentication steps that raise privilege or other events that happen after the login.
If the user had permission to run commands through sudo review the authentication and system logs for evidence of administrative activity.
Remember one limitation: Linux does not always record every command a user runs. A missing command, in the logs does not mean the user did nothing.
6. Look for Changes That Could Allow Someone to Return
If you suspect an account was compromised do not stop after finding the login. Check whether the user or an attacker has made changes that could give access.
Begin with the account list:
getent passwdLook for accounts that you do not recognize, especially accounts with interactive login shells or unexpected administrative privileges. Compare the results with your normal server configuration before taking action.
Check the affected user's scheduled tasks:
sudo crontab -u deploy -lYou should also review system-wide scheduled jobs and relevant service definitions if the incident warrants it.
Next, examine the effective SSH configuration:
sudo sshd -TThis displays the settings that the SSH daemon applies. Pay attention to root login restrictions, permitted authentication methods, and other settings relevant to your environment.
It will not tell you when a configuration changed. To establish that, you may need configuration backups, file metadata, audit logs, or a known-good baseline.
Finally, inspect running processes and listening network services:
ps auxf sudo ss -tulpn
These commands can show you processes or listening ports that you do not know about. Look at the entries and compare them with the software you have installed and the services you usually use.
Do not quickly delete files or stop every unknown process. If the server might have been broken into these actions can get rid of clues. Keep the information that matters and go through your steps for handling an incident.
7. What to Do If You Find Signs of Unauthorized Access
If you are sure that someone not allowed got in think of this as a security problem of just a regular login issue.
First write down the times, usernames, places they came from how they logged in and any changes you found. Keep copies of the logs in a place where the person who broke in cannot change them.
If the system is still being used by the attacker think about separating it from networks that are not trusted. Try to stop the problem while keeping the proof and making sure important services are still working.
Next find out what the account had access to. A regular user account and an account with sudo rights are very different in terms of danger. Check if any passwords for applications, databases SSH keys or other secrets might have been seen.
From a device remove any SSH keys that should not be there and turn off accounts that have been taken over. Change any passwords that might have been seen including passwords for services if they might have been used.
Changing one password is not enough if the person who broke in could have made another account or changed tasks and services.
If it is clear that the system was taken over it might be safer to rebuild the server using a trusted image and bring back data that has been checked. Trying to get rid of everything the intruder did might not work.
Before you put the server back, into use look into how the person got in and fix the problem that let them in.
8. Make SSH Harder to Use in the Wrong Way
After you finish checking everything look at how SSH accesss set up.
Turn off logging in as root whenever you can.