How to fix Accepted publickey for user from hostname port XXXXX ssh2 in SSH

SSHBEGINNERLOWUpdated Jan 4, 2026· 178 views

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.

Quick fix

Fixes Accepted publickey for user from hostname port XXXXX ssh2

# 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"
  1. Locate and examine SSH logs
  2. Understand the log message components
  3. Identify which SSH key was used
  4. Review successful login patterns for security
ssh — error
# 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"
Accepted publickey for user from hostname port XXXXX ssh2

What this error means

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.

Typical symptoms

  • You see this message in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (CentOS/RHEL)
  • The message appears alongside a successful SSH login
  • You're trying to understand who accessed your server and from where
  • You need to audit which SSH key was used for a particular login
  • You're monitoring server security and want to know what successful logins look like

Common causes

  1. A user successfully authenticated to the SSH server using their private key
  2. The public key in the user's ~/.ssh/authorized_keys file matched the client's private key
  3. File permissions on ~/.ssh and authorized_keys were correct (700 and 600 respectively)
  4. The user account was enabled and not restricted by sshd_config rules (AllowUsers, DenyUsers, etc.)
  5. The SSH server accepted the key type and algorithm (RSA, ED25519, ECDSA, etc.)

How to fix "Accepted publickey for user from hostname port XXXXX ssh2"

1Locate and examine SSH logs

Find where your SSH daemon logs are stored. The location varies by operating system:

bash
# 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:

bash
Jun 13 15:31:09 myserver sshd[22293]: Accepted publickey for admin from 192.168.1.50 port 55943 ssh2: RSA SHA256:Ab3d9EfGhIjK1mN0pQrSt2uVwXyZ
2Understand the log message components

Break down what each part of the message means:

bash
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 fingerprint

This is a successful authentication event. No action is needed—it indicates the system is working correctly.

3Identify which SSH key was used

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:

bash
# 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.pub

Compare the SHA256 fingerprint in the output with the fingerprint in the SSH log. They should match.

Example:

bash
$ 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.

4Review successful login patterns for security

Use SSH logs to audit who has access and when they're connecting:

bash
# 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 -c

A healthy server should show:
- Regular logins from expected IP addresses
- Consistent user accounts accessing the system
- No unexpected source IPs or users

5Compare with failed authentication attempts

To get a complete security picture, understand the difference between successful and failed attempts:

bash
# 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.log

Failed 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.

6Monitor and alert on login activity

Set up monitoring to track authentication events:

bash
# 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"

Advanced notes

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:

bash
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:

bash
# 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.pub

Distinguishing 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.

bash
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:

bash
# On the server, list all authorized keys for all users
sudo grep -r "^ssh-" /home/*/.ssh/authorized_keys | head -20

Remove unauthorized keys immediately and consider rotating keys annually.

Frequently asked questions

What does "Accepted publickey for user from hostname port XXXXX ssh2" mean?
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.
How do I fix "Accepted publickey for user from hostname port XXXXX ssh2"?
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.
What causes "Accepted publickey for user from hostname port XXXXX ssh2"?
A user successfully authenticated to the SSH server using their private key The public key in the user's ~/.ssh/authorized_keys file matched the client's private key File permissions on ~/.ssh and authorized_keys were correct (700 and 600 respectively)
Is the "Accepted publickey for user from hostname port XXXXX ssh2" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading