sshd "Accepted publickey" and "Accepted password": Successful SSH Login

Oct 18 03:51:11 web1 sshd-session[48211]: Accepted publickey for deploy from 203.0.113.7 port 54321 ssh2: ED25519 SHA256:0K3bVn2Q1sYgq7Wd9rHcLm4xPzT6uEa8ZfJiRvNtBoU
Oct 18 04:02:37 web1 sshd-session[48344]: Accepted publickey for backup from 198.51.100.22 port 40118 ssh2: RSA SHA256:9pQrLx2Dm7Yc4Vn1tKb6ZaWgEoJ3sHfUi0QvXdRy5Tk
Oct 16 21:14:02 web1 sshd-session[41190]: Accepted password for alice from 192.0.2.44 port 51902 ssh2

What it means

Every authentication outcome sshd logs comes from one statement, do_log2() at auth.c:294, with the format %s %s%s%s for %s%.100s from %.200s port %d ssh2%s%s. Reading an Accepted line is reading that format left to right:

• The result word. auth.c:287 is authmsg = authenticated ? "Accepted" : "Failed";. Accepted means this authentication attempt succeeded. The two branches above it produce Postponed and Partial instead.
• The method, and a submethod joined by a slash when there is one (submethod != NULL ? "/" : "") — hence publickey, password, or forms such as keyboard-interactive/pam.
• invalid user , inserted at auth.c:298 when the authentication context is not valid. On Accepted lines it is absent, so the account named is one the host knows.
• The user name, then the client’s address and the client’s source port for that TCP connection.
• The trailing text, built from format_method_key() or from auth_method_info. For public keys that is the key type and fingerprint of the key that was accepted; for a password there is nothing to describe, so the line ends at ssh2.

So the line is the moment the credential check passed. It does not say what the session then did, and it does not say the person at the other end is the account’s owner — only that a key or password that the server accepts was presented from that address.

Is it an attack?

Pattern	Reading
Public key, known account, host and key fingerprint you recognise	Routine login
Accepted from an address that produced a run of Failed password or Invalid user lines minutes earlier	Treat as a compromise until proven otherwise
Accepted password on a host you believe is key-only	Configuration drift — PasswordAuthentication or KbdInteractiveAuthentication is still on somewhere
Public key whose fingerprint is not in your inventory	Someone may have appended a key to authorized_keys (ATT&CK T1098.004)
Accepted for a service or deploy account from an address that is not the CI runner or bastion	Stolen key material, or key reuse outside the intended path
Accepted for root	Compare against PermitRootLogin; the manual’s default is prohibit-password, which disables password and keyboard-interactive authentication for root

A single Accepted line is informational — healthy servers write them constantly. What changes its severity is what surrounds it: the failures before it, the account, the fingerprint and the source address.

How to investigate

# Every successful login in the last 24 hours
# (Debian/Ubuntu unit is ssh; on RHEL/Fedora use -u sshd)
sudo journalctl -u ssh --since "24 hours ago" \
  | grep -E 'Accepted (publickey|password|keyboard-interactive)'

# Who got in, with what method, from where (/var/log/auth.log; RHEL/Fedora: /var/log/secure)
sudo grep ' Accepted ' /var/log/auth.log \
  | awk '{for(i=1;i<=NF;i++) if($i=="Accepted") print $(i+1), $(i+3), $(i+5)}' \
  | sort | uniq -c | sort -rn

# Any password logins at all on a host that should be key-only?
sudo grep 'Accepted password' /var/log/auth.log

# Which key let them in? Compare the fingerprint on the line with the account's keys
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

# Did that source fail repeatedly before it succeeded?
sudo grep '203.0.113.7' /var/log/auth.log

# Everything one connection logged, by PID
sudo grep 'sshd-session\[48211\]' /var/log/auth.log

If the fingerprint is unknown, check the modification time and owner of every authorized_keys file before deleting anything, and keep a copy. If the source failed first and succeeded after, that is the brute-force-to-access transition the SSH brute-force rule is built around; an exported auth.log can be grouped by source and account in the browser log analyzer.

How to stop it

You do not stop Accepted lines — you decide who is able to produce one.

• Turn off passwords. PasswordAuthentication and KbdInteractiveAuthentication both default to yes. Set both to no and Accepted password lines become impossible. The manual notes that because PAM keyboard-interactive authentication “usually serves an equivalent role to password authentication”, you should disable one of the two when UsePAM is enabled.
• Keep keys as the only way in. PubkeyAuthentication defaults to yes; the keys read come from AuthorizedKeysFile, whose default is .ssh/authorized_keys plus .ssh/authorized_keys2. Monitor both paths for changes.
• Narrow the account list with AllowUsers; by default login is allowed for all users, and the manual’s USER@HOST form also restricts particular users to particular hosts, with CIDR address matching.
• Require two methods for sensitive hosts with AuthenticationMethods, for example publickey,keyboard-interactive — successful authentication then requires completing every method in one of the listed sets, and the first step appears as a Partial line.
• Set PermitRootLogin deliberately rather than relying on the default.

sudo sshd -t && sudo systemctl reload ssh

Validate before reloading and keep an existing session open until a new one works.