The "Connection from hostname port XXXXX on hostname port 22 rdomain" message is a standard informational log entry from sshd (SSH daemon) that records incoming client connections. It indicates a successful socket connection before authentication attempts.
This is a normal SSH server log message that appears when the sshd daemon accepts an incoming TCP connection from a client. The log format shows: 1. **Source**: The client's IP address (shown as "hostname" if reverse DNS is enabled and resolves) 2. **Source port**: The ephemeral port the client's SSH session is using (typically 40000-65535) 3. **Destination**: The server's IP address where SSH is listening 4. **Destination port**: Port 22 (the standard SSH port, or custom if configured) 5. **rdomain**: The routing domain (relevant for OpenBSD implementations with network compartmentalization) This message is logged before any authentication occurs. It simply means the TCP three-way handshake succeeded and the server accepted the connection. Authentication attempts will be logged separately.
Determine if the source IP is expected. Compare the source IP in the log with:
# View recent connections
tail -50 /var/log/auth.log | grep "Connection from"
# Or on RHEL/CentOS
tail -50 /var/log/secure | grep "Connection from"Look for patterns. Legitimate users or automation tools will have consistent IP addresses. Automated bots will show many different IPs attempting connections.
Extract the source IP from the log message. The format is:
Connection from <IP_ADDRESS> port <PORT> on <SERVER_IP> port 22 rdomain ""Try to identify who owns this IP:
# Perform a reverse DNS lookup
dig -x <IP_ADDRESS>
nslookup <IP_ADDRESS>
# Check if it's on your network
ping <IP_ADDRESS>
# See if it matches known CI/CD tools or cloud providers
whois <IP_ADDRESS> | grep -i "netname|descr|organization"Check what happened after the connection. Look for authentication success or failure:
# Find all activity from a specific IP
grep "<IP_ADDRESS>" /var/log/auth.log | tail -20
# Look for failed authentication attempts
grep "Failed password" /var/log/auth.log | grep "<IP_ADDRESS>"
# Look for successful authentication
grep "Accepted publickey" /var/log/auth.log | grep "<IP_ADDRESS>"If you see only "Connection from" messages with no subsequent authentication logs, the connection was terminated before authentication. This is typical of port scanners.
If the connection is from an attacker or unwanted source, block it:
Using firewall (iptables/firewalld):
# Block a single IP
sudo iptables -A INPUT -s <IP_ADDRESS> -p tcp --dport 22 -j DROP
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<IP_ADDRESS>" port protocol="tcp" port="22" reject'
# Block a subnet (example: /24)
sudo iptables -A INPUT -s <IP_ADDRESS>/24 -p tcp --dport 22 -j DROPUsing fail2ban (recommended):
# Fail2ban automatically blocks IPs with too many failed login attempts
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
# Check ban status
sudo fail2ban-client status sshdFor more detailed information about connections, increase SSH logging verbosity:
Edit /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_configChange or add the LogLevel option:
# Show more detail
LogLevel VERBOSE
# Or maximum debug (lots of output)
LogLevel DEBUGThen restart sshd:
sudo systemctl restart ssh # Debian/Ubuntu
sudo systemctl restart sshd # RHEL/CentOSNow connection logs will show more information about key exchange and negotiation.
If you see many failed authentication attempts from the same IP, you're being scanned. Check the rate:
# Count failed password attempts by IP
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -10
# Or for all authentication failures
grep "Failed" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -10A few attempts are normal. Hundreds or thousands indicate a brute force attack. Use fail2ban or cloud firewall rules to block these IPs automatically.
SSH Daemon Log Levels: The sshd log verbosity is controlled by the LogLevel directive in sshd_config. VERBOSE logs every connection attempt. DEBUG and DEBUG2/DEBUG3 provide increasingly detailed information. In production, keep it at INFO or VERBOSE; DEBUG levels produce enormous log files.
Reverse DNS and rdomain: The "rdomain" field is relevant on OpenBSD systems where it indicates the routing domain. On Linux systems, this will typically be empty (""). If reverse DNS is enabled (UseDNS yes in sshd_config), sshd performs a reverse DNS lookup on the client IP. Disabled reverse DNS speeds up connections and reduces log noise.
Connection vs. Authentication: A "Connection from" log message only indicates a TCP connection was accepted. It does NOT mean the user authenticated successfully. Look for subsequent "Accepted" or "Failed" messages to understand the outcome. Many security tools scan for open SSH ports; these will only show "Connection from" messages without authentication attempts.
Routing Domain Details: The rdomain field becomes important in environments using network namespaces or OpenBSD's routing domain isolation. In standard Linux sshd, this will be empty. In multi-tenant or containerized environments, rdomain allows SSH to bind to specific network segments.
Log Analysis Tools: For large numbers of connections, parse logs with scripts:
# Count unique IPs
grep "Connection from" /var/log/auth.log | awk '{print $3}' | sort -u | wc -l
# Find IPs with most connection attempts
grep "Connection from" /var/log/auth.log | awk '{print $3}' | sort | uniq -c | sort -rn | head -20Someone 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