WardtermSSH client
EN
Download

How to check SSH login attempts on Linux

Run sudo journalctl -u ssh --since today on Debian and Ubuntu, or -u sshd on Red Hat and Fedora. Where text logs exist, look in /var/log/auth.log or /var/log/secure. Lines with Accepted are real logins, and Failed password or Invalid user are attempts. Use who for current sessions, last for past ones and sudo lastb for failures, where those commands exist.

Updated . Log lines and grep commands run with OpenSSH 10.0 on Debian 13 with rsyslog.

Where the logs are

SystemRead the logs with
Debian or Ubuntu, with systemdsudo journalctl -u ssh
Red Hat or Fedora, with systemdsudo journalctl -u sshd
Debian or Ubuntu with rsyslog/var/log/auth.log
Red Hat family with rsyslog/var/log/secure

A file may be missing, and that is normal: Debian has not installed rsyslog by default since version 12, so a new Debian system often has only the journal.

With journalctl

sudo journalctl -u ssh --since today
sudo journalctl -u ssh --since "2 hours ago" --grep 'Accepted|Failed|Invalid'
sudo journalctl -u ssh -f

-f follows new lines as they arrive, which helps when you are testing a login.

With the text files

sudo grep Accepted /var/log/auth.log
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log

Older lines may be in /var/log/auth.log.1 and compressed files beside it. Since OpenSSH 9.8 these lines carry the name sshd-session rather than sshd, so a filter or script looking for sshd[ finds nothing on a current system.

What the lines mean

All of these are real lines from a test server, with the address changed.

sshd-session[1329]: Accepted publickey for user from 203.0.113.10 port 43594 ssh2: ED25519 SHA256:NxFS05Q+k1zf...
sshd-session[1339]: Accepted password for user from 203.0.113.10 port 43598 ssh2

Someone logged in. These are the lines to read first. The first one shows which key was used. See how to revoke a key if you find one you do not want.

sshd-session[1311]: Failed password for user from 203.0.113.10 port 33598 ssh2

A wrong password for an account that exists.

sshd-session[1317]: Invalid user admin from 203.0.113.10 port 50898
sshd-session[1317]: Failed password for invalid user admin from 203.0.113.10 port 50898 ssh2

An attempt on an account that does not exist on this system. This is how most automated guessing looks.

sshd-session[1326]: Connection closed by authenticating user user 203.0.113.10 port 43590 [preauth]

The client gave up while logging in. With key logins, this usually means a key was offered and not accepted. By default the log does not say which key.

sshd-session[1317]: error: maximum authentication attempts exceeded for invalid user admin from 203.0.113.10 port 50898 ssh2 [preauth]

The client went over MaxAuthTries and was disconnected.

Count attempts by address and user

# Which addresses
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

# Which user names they try
sudo grep -oE 'Invalid user [^ ]+' /var/log/auth.log \
  | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

A single attempt usually produces both a Failed and an Invalid user line, so treat the numbers as a guide. With the journal, start the first pipeline like this:

sudo journalctl -u ssh --since today --no-pager | grep -E 'Failed password|Invalid user' \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

See who is on now

who
w

Both list sessions with a terminal. A command run as ssh server somecommand, a file transfer or a tunnel does not appear. To see all connections, including those:

sudo ss -tnp state established '( sport = :22 )'

Change 22 if your server uses another port. We saw the connection in this list when who showed nothing.

Past sessions: last and lastb

last -a -n 20
sudo lastb -a -n 20

last reads past logins and lastb the failed ones. -a puts the address in the last column. Two limits came up in our tests:

  • last showed only sessions with a terminal. A login that just ran a command left nothing, so the log files are the fuller record.
  • On Debian 13 these commands are gone. The util-linux package no longer includes last or lastb. Install wtmpdb and libpam-wtmpdb to get last back, which worked in our test, for sessions after the install. For failures there is no replacement that reads the old file. The release notes suggest lslogins --failed, but it showed nothing in our test, so use the logs.

See which key was refused

To log the fingerprint of keys that fail too, set this in a file in /etc/ssh/sshd_config.d/ and reload:

LogLevel VERBOSE
sshd-session[1376]: Failed publickey for user from 203.0.113.10 port 43612 ssh2: RSA SHA256:R3PypHnQ7AMz...

What to do with what you find

  • Many failures from many addresses: this is common on any server open to the internet. If the server accepts keys only, password guesses cannot succeed. See how to disable password login and, to reduce the noise, fail2ban.
  • An Accepted line you cannot explain: take this seriously. Note the time, address and key. Remove that access, look at what the account did, and if you are not sure what happened, rebuild the server from a clean state.

Someone with root can edit local logs, so for servers that matter, send them to another machine as well.

To make password guessing pointless, generate an Ed25519 SSH key and accept only keys.

Questions

How do I see failed SSH login attempts?

On systemd systems run sudo journalctl -u ssh --grep 'Failed|Invalid' (sshd on Red Hat). With text logs, grep 'Failed password' in /var/log/auth.log or /var/log/secure. sudo lastb lists failures where it is installed.

Where is the SSH log on Ubuntu?

In the journal, read with sudo journalctl -u ssh, and in /var/log/auth.log when rsyslog is installed, as it is on Ubuntu by default.

Are many failed SSH logins a problem?

On a public server they are normal background noise from bots, and they cannot succeed if only keys are accepted. An Accepted line you cannot explain is the one to act on.

Sources

More in Securing a server

All guides