Why Is Someone Trying to Log In to Your Linux Server?

In the first lesson, we explored what changes when a Linux server receives a public IP address. We learned that automated systems can discover services without knowing a domain name.

Now we’re following one of those connections further.

This time, a remote client has reached SSH — the service commonly used to administer Linux servers remotely.

SSH has recorded a series of messages. Some look threatening. Others seem ordinary. The challenge is understanding which messages describe failed access, which describe successful authentication, and which simply tell us that a connection occurred.

1. A Strange Message Appears in the SSH Log

Imagine a small VPS running Ubuntu Server. You are its administrator, and you normally connect using an SSH key.

While reviewing the server’s authentication records, you notice these messages:

Oct 24 02:14:06 vps-lab sshd[4201]:
Invalid user guest from 198.51.100.42 port 51218

Oct 24 02:14:08 vps-lab sshd[4201]:
Failed password for invalid user guest
from 198.51.100.42 port 51218 ssh2

Oct 24 02:15:32 vps-lab sshd[4250]:
Failed password for deploy
from 203.0.113.24 port 53992 ssh2

These are constructed teaching examples, not measurements from a live VPS. The addresses are documentation-only IP ranges. Real journal entries typically appear as one line per event, and formatting varies by OpenSSH version.

At first glance, it looks like someone is trying to enter the server.

But let’s separate what these messages actually establish from what we might be tempted to assume.

Notice what we haven’t seen: evidence that the remote client successfully authenticated.

The presence of a login attempt is not the same thing as a successful login. That difference should guide the entire investigation.

2. How Does an Unknown Client Reach SSH?

SSH usually listens on TCP port 22 unless the administrator has configured another port.

If the port is reachable from the internet, a remote client can establish a network connection and begin communicating with the SSH service.

That client may be a legitimate administrator, an automated inventory system, a monitoring service, a misconfigured script, or an attacker.

We cannot reliably determine which one from the connection itself.

These are simplified conceptual stages. The real SSH protocol also negotiates algorithms, establishes encrypted communication, and performs additional checks.

An automated scanner might disconnect after learning that an SSH service exists. Another client may try to authenticate using a common username. Still another may complete authentication using an authorized key.

The log entries reflect different points in that process.

Importantly, packets dropped by a provider firewall or host firewall may never reach the SSH daemon and therefore may not appear in its authentication logs.

3. Understanding the Most Important SSH Log Messages

You do not need to memorize every OpenSSH message. Start by learning what a few common event types mean — and, equally importantly, what they do not prove.

These message strings and their presence can vary with OpenSSH version, logging configuration, authentication methods and distribution packaging.

For example, some systems may log activity under sshd, while others may show messages involving sshd-session.

Never build an entire security conclusion around a single exact text pattern.

4. Why Do Bots Try Usernames Like root, admin, or guest?

Automated clients can submit account names that are common across operating systems, hosting setups and applications.

Some attempt username and password combinations. Others simply record how an authentication service responds.

The server owner may never have created the requested accounts.

This is why a failed login is an observation, not a complete explanation of intent.

Repeated guessing against common account names can indicate automated abuse, but a small number of failures may also come from ordinary operational mistakes.

Correlate usernames, source addresses, timing and other evidence before assigning a cause.

5. Which SSH Events Deserve Your Attention?

There is no universal number of failed attempts that separates harmless background activity from a serious security incident.

One failed attempt could be an ordinary typo. Hundreds may come from an automated guessing campaign. But even a single successful authentication from an unexplained source may deserve investigation.

These are investigation priorities, not a formula that calculates the probability of compromise.

A message containing Accepted establishes successful SSH authentication for that event. It does not, on its own, prove malicious activity or reveal everything the authenticated client did afterward.

6. Safe Lab: Read SSH Login Attempts on Your Own Server

Let’s examine authentication records using read-only Linux commands.

You won’t need to trigger failed logins, change your SSH configuration, disable a firewall or restart any services.

systemctl status ssh.service --no-pager

systemctl status sshd.service --no-pager

sudo journalctl -u ssh.service \
  --since "24 hours ago" \
  --no-pager

sudo journalctl -u sshd.service \
  --since "24 hours ago" \
  --no-pager

sudo journalctl \
  -t sshd \
  -t sshd-session \
  --since "24 hours ago" \
  --no-pager

sudo tail -n 100 /var/log/auth.log

sudo tail -n 100 /var/log/secure

sudo journalctl \
  -t sshd \
  -t sshd-session \
  --since "1 hour ago" \
  --no-pager

7. What Does a Successful SSH Login Look Like?

Now consider a different example.

Oct 24 09:12:11 vps-lab sshd[6030]:
Accepted publickey for admin from
192.0.2.28 port 56088 ssh2

Illustrative, shortened log entry. Real public-key authentication logs may include the key algorithm and fingerprint.

This line tells us that the SSH server accepted public-key authentication for the account admin from the recorded client address.

That is materially different from Failed password.

But we still need to ask whether the authentication was expected.

Maybe it was your own login. Maybe a deployment system uses that account. Maybe you were connected through a VPN, meaning the recorded IP belongs to the VPN exit point rather than your home connection.

Or perhaps the login is unexplained.

To understand the situation, compare the timestamp, account and source against legitimate activity you know about.

Don’t assume that a foreign country in an IP geolocation database identifies an attacker. Geolocation is approximate, and clients may connect through cloud providers, corporate gateways and VPNs.

8. Can You Find Previous Successful Sessions?

On distributions with the relevant login accounting tools and records, last can display historical login sessions:

last -F -a | head -n 20

The output may include accounts, session timestamps, terminal identifiers, and remote host information.

These records are useful supporting evidence, but they have limitations. Login accounting may be absent, incomplete or subject to rotation, and not every type of SSH activity necessarily corresponds to an ordinary interactive login session.

To see users currently logged in, you can also run:

who

w

These show current session information, not a complete historical record of all SSH authentications.

If a suspicious login appears in one source but not another, don’t immediately conclude that a record was deleted. First account for the differences between authentication logs and session-accounting systems.

9. A Mini Investigation: Three Events, Three Conclusions

Let’s apply what we’ve learned to a hypothetical VPS.

Imagine you find these three observations in a day’s authentication history.

Notice that the third event is not automatically malicious. It becomes concerning if you cannot match it to authorized activity.

This is the difference between collecting suspicious-looking messages and conducting a useful investigation.

You are not merely counting how many times the word Failed appears. You are building a coherent explanation from the evidence.

10. What If You Find an Unknown Successful Login?

If you discover a successful authentication that nobody authorized can explain, treat it as a potentially serious security incident until you can establish what occurred.

Start by recording the relevant timestamps, accounts, source addresses and log excerpts. Note the server’s timezone and whether multiple authentication sources agree.

Investigate whether the access can be explained by an administrator, VPN connection, hosting provider, backup service or deployment tool.

If the login remains unexplained, consider the possibility of unauthorized access and follow your organization’s incident-response procedure. Preserve relevant evidence and use a trusted management channel or provider console where appropriate.

Avoid randomly restarting SSH, deleting logs, removing accounts, or changing firewall rules while you are still establishing the facts. Those actions can destroy evidence or interrupt legitimate operations.

11. Why You Shouldn’t Immediately Disable SSH

It can be tempting to react to repeated failures by changing your SSH port, disabling password authentication, or blocking source addresses.

Some of those changes may be useful when carefully planned. But making them impulsively on a remote VPS can also remove your own access.

For example, disabling password authentication before confirming that your SSH key works can leave you unable to log in.

Similarly, a firewall rule that blocks your current management path can terminate access even if SSH itself is correctly configured.

This lesson is about recognizing what happened, not making untested configuration changes.

If your SSH connection is already failing, consult Can’t SSH Into Your Linux Server? 12 Checks Before You Reboot before trying random repairs.

We will cover a safer approach to hardening in the third lesson: validating an alternative access method, applying one change at a time and verifying that legitimate access still works.

12. Common Mistakes When Reading SSH Logs

Another common mistake is believing that an absence of SSH log entries proves that nobody contacted the server.

Connections can be filtered before SSH sees them. Logs may be written elsewhere, removed by retention policies or unavailable for a previous boot.

Read log evidence in combination with network exposure and authentication configuration.

13. What You Should Understand Before Securing SSH

Before changing your server, make sure you can answer five questions:

• Which SSH service is active, and how are you currently accessing it?
• Which user accounts actually need remote access?
• Are successful logins consistent with authorized administrators and automation?
• Which addresses and network paths can reach SSH?
• Do you have a verified recovery method if a change blocks remote access?

These answers provide a safer foundation for future changes.

For background on traffic filtering and the difference between a listening socket and an externally accessible service, revisit Linux Firewall Explained.

14. Frequently Asked Questions

15. What Comes Next?

We began with a collection of unfamiliar login attempts. Some messages showed invalid usernames. Others showed rejected passwords. We learned how to find authentication records and how to distinguish these failures from successful authentication.

But recognizing an event is only the second step.

Once you understand what the server is exposing and what its authentication records show, the next question becomes practical:

How do you reduce unnecessary SSH exposure and strengthen access controls without accidentally locking yourself out?

That is the focus of our final lesson.

Primary Technical Sources

• OpenSSH — sshd_config(5) — Authentication and logging configuration.
• Ubuntu Server — OpenSSH Server — OpenSSH administration and troubleshooting.
• systemd — journalctl — Journal filtering and inspection.
• Red Hat — How to Secure the SSHD Daemon? — Common SSH authentication threats.