The "Accepted publickey for user" message is a success indicator in SSH daemon logs showing that a user successfully authenticated using public key authentication. Understanding this log entry helps with security auditing, troubleshooting authentication issues, and identifying which SSH key was used for login.
The "Accepted publickey for user from [hostname] port [port] ssh2" message in SSH daemon (sshd) logs is a **success message**, not an error. It indicates that a user has successfully completed SSH authentication using public key authentication and has been granted access to the system. This log entry is automatically generated by the SSH server when an authentication attempt succeeds and contains important security audit information about the connection.
Find where your SSH daemon logs are stored. The location varies by operating system:
# On Debian/Ubuntu systems
cat /var/log/auth.log | grep "Accepted publickey"
# On CentOS/RHEL systems
cat /var/log/secure | grep "Accepted publickey"
# Or check systemd journal (works on most modern Linux systems)
sudo journalctl -u ssh | grep "Accepted publickey"
sudo journalctl -u sshd | grep "Accepted publickey"You'll see output like:
Jun 13 15:31:09 myserver sshd[22293]: Accepted publickey for admin from 192.168.1.50 port 55943 ssh2: RSA SHA256:Ab3d9EfGhIjK1mN0pQrSt2uVwXyZBreak down what each part of the message means:
Jun 13 15:31:09 - Timestamp when login occurred
myserver - Hostname of the server
sshd[22293] - SSH daemon process ID
Accepted publickey - Login succeeded using public key authentication
for admin - The username that logged in
from 192.168.1.50 - Source IP address of the connection
port 55943 - Source port of the connection
ssh2 - SSH protocol version 2
RSA SHA256:Ab3d9... - Key type (RSA/ED25519/ECDSA) and SHA256 fingerprintThis is a successful authentication event. No action is needed—it indicates the system is working correctly.
To find out which specific private key was used to authenticate, match the key fingerprint from the log:
First, display the fingerprint of a key on your system:
# Check all public keys for a user
ssh-keygen -l -f ~/.ssh/authorized_keys
# Or check a specific key file
ssh-keygen -l -f ~/.ssh/id_rsa.pub
ssh-keygen -l -f ~/.ssh/id_ed25519.pubCompare the SHA256 fingerprint in the output with the fingerprint in the SSH log. They should match.
Example:
$ ssh-keygen -l -f ~/.ssh/id_ed25519.pub
256 SHA256:Ab3d9EfGhIjK1mN0pQrSt2uVwXyZ user@localhost (ED25519)If the fingerprint matches the one in the sshd log, this is the key that was used.
Use SSH logs to audit who has access and when they're connecting:
# Show all successful public key logins
sudo grep "Accepted publickey" /var/log/auth.log
# Filter by specific username
sudo grep "Accepted publickey for alice" /var/log/auth.log
# Filter by date (show last 24 hours on most systems)
sudo journalctl --since "24 hours ago" -u ssh | grep "Accepted publickey"
# Count unique source IPs for a user
sudo grep "Accepted publickey for admin" /var/log/auth.log | awk '{print $9}' | sort | uniq -cA healthy server should show:
- Regular logins from expected IP addresses
- Consistent user accounts accessing the system
- No unexpected source IPs or users
To get a complete security picture, understand the difference between successful and failed attempts:
# Successful public key authentications (good)
sudo grep "Accepted publickey" /var/log/auth.log
# Failed public key authentications (investigate)
sudo grep "Postponed publickey" /var/log/auth.log
sudo grep "Rejected publickey" /var/log/auth.log
sudo grep "Permission denied (publickey)" /var/log/auth.log
sudo grep "Invalid user" /var/log/auth.logFailed attempts might indicate:
- Attackers trying to brute-force the system
- Misconfigured scripts or CI/CD pipelines
- Users using wrong keys or usernames
- Account lockdowns or permission issues
Review any suspicious failed attempts and ensure only legitimate users have keys in authorized_keys.
Set up monitoring to track authentication events:
# Show real-time SSH logins as they happen
sudo tail -f /var/log/auth.log | grep "Accepted publickey"
# Or with systemd journal
sudo journalctl -f -u ssh | grep "Accepted publickey"For production systems, consider:
- Setting up log aggregation (ELK, Splunk, CloudWatch)
- Creating alerts for logins from new IPs
- Tracking failed authentication attempts
- Monitoring for privilege escalation attempts after successful login
Example alert trigger: "If 5+ failed publickey attempts occur within 1 minute, alert admin"
Log Levels and Verbosity: By default, sshd logs successful authentications at INFO level. To see more detailed authentication attempts (including failed ones), increase LogLevel in /etc/ssh/sshd_config:
LogLevel VERBOSE # Shows more authentication details
# or
LogLevel DEBUG # Extremely detailed (not for production)Then restart SSH: sudo systemctl restart ssh
Key Fingerprint Formats: Modern SSH logs show SHA256 fingerprints, but you might see older MD5 format on older systems:
# Show SHA256 (modern)
ssh-keygen -l -f ~/.ssh/id_rsa.pub
# Show MD5 (legacy, not recommended)
ssh-keygen -E md5 -l -f ~/.ssh/id_rsa.pubDistinguishing Key Types: The log shows which algorithm was used:
- RSA - Widely supported, 2048+ bit recommended
- ED25519 - Modern, more secure, smaller keys
- ECDSA - Good security, less common than RSA
Prefer ED25519 for new deployments.
Failed vs. Successful Auth Patterns: You'll see "Postponed publickey" before "Accepted publickey" if sshd tries multiple authentication methods. This is normal—the server tries methods in order (GSSAPI, then publickey, then password) until one succeeds.
Jun 13 15:31:08 sshd[22291]: Postponed publickey for admin from 192.168.1.50
Jun 13 15:31:09 sshd[22293]: Accepted publickey for admin from 192.168.1.50 # Success!Security Implications: Review who has keys regularly:
# On the server, list all authorized keys for all users
sudo grep -r "^ssh-" /home/*/.ssh/authorized_keys | head -20Remove unauthorized keys immediately and consider rotating keys annually.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH