Debugging SSH Logs: Why “Maximum Authentication Attempts Exceeded” Appears Without Visible Login Attempts


36 views

When examining SSH logs in depth (particularly when processing them through tools like Logstash), you might encounter entries like this:

Oct 23 07:43:47 sshd[59830]: Connection from 74.194.6.5 port 60126 on 213.67.100.148 port 22
Oct 23 07:43:51 sshd[59830]: error: maximum authentication attempts exceeded for root from 74.194.6.5 port 60126 ssh2 [preauth]
Oct 23 07:43:51 sshd[59830]: Disconnecting authenticating user root 74.194.6.5 port 60126: Too many authentication failures [preauth]

Notice how there are no intermediate failed authentication attempts logged between the connection and the maximum attempts error. This differs from the more common pattern:

Oct 23 08:54:06 sshd[62392]: Failed keyboard-interactive/pam for [...]
Oct 23 08:52:41 sshd[49690]: Failed publickey for [...]

There are several scenarios where failed attempts might not appear in logs:

  • Client-side authentication methods: Some SSH clients will try multiple authentication methods internally before reporting failure.
  • Log level configuration: Your sshd_config might have LogLevel set to only show certain message types.
  • Rate-limited logging: Some systems throttle log messages to prevent log flooding.

First, check your sshd configuration:

# Check current log level
sudo sshd -T | grep loglevel

# Recommended configuration for debugging:
LogLevel VERBOSE

For a more complete picture, consider packet capture:

# Capture SSH traffic (adjust interface as needed)
sudo tcpdump -i eth0 -w ssh_capture.pcap port 22

# Or use tshark for more readable output
sudo tshark -i eth0 -Y "tcp.port == 22" -V

When writing Logstash filters, account for these "invisible" attempts:

filter {
  if [message] =~ "maximum authentication attempts exceeded" {
    grok {
      match => { "message" => "error: maximum authentication attempts exceeded for %{USER:auth_user} from %{IP:source_ip} port %{NUMBER:source_port}" }
      add_tag => [ "ssh_auth_failure", "brute_force_attempt" ]
    }
  }
}

For security monitoring, consider these additional approaches:

# Fail2ban configuration example
[sshd]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/auth.log
maxretry = 3
  • Disable root login: PermitRootLogin no in sshd_config
  • Use key-based authentication
  • Implement rate limiting with iptables or similar
  • Consider changing the default SSH port
  • Use tools like fail2ban or crowdsec

When analyzing SSH logs, we typically expect to see explicit failed authentication attempts before reaching the maximum attempts threshold. However, the following log pattern presents an interesting anomaly:

Oct 23 07:43:47 sshd[59830]: Connection from 74.194.6.5 port 60126 on 213.67.100.148 port 22
Oct 23 07:43:51 sshd[59830]: error: maximum authentication attempts exceeded for root from 74.194.6.5 port 60126 ssh2 [preauth]
Oct 23 07:43:51 sshd[59830]: Disconnecting authenticating user root 74.194.6.5 port 60126: Too many authentication failures [preauth]

Several technical factors could explain why failed attempts aren't logged:

  • ChallengeResponseAuthentication: Some authentication methods may not log individual failures by default
  • AuthenticationMethods configuration: Multiple simultaneous auth methods can obscure individual failures
  • LogLevel settings: Default INFO level might not show all auth attempts

To capture all authentication attempts, consider these sshd_config modifications:

# Increase verbosity for auth logging
LogLevel VERBOSE

# Track all authentication methods separately
Match Address 74.194.6.5
    AuthenticationMethods publickey,keyboard-interactive
    MaxAuthTries 3
    LogLevel DEBUG

For comprehensive monitoring, implement these techniques:

# Grep pattern to catch all auth-related events
grep -E "sshd.*(authentication|auth|failed|attempt)" /var/log/auth.log

# Alternative using journalctl for systemd systems
journalctl -u sshd --since "1 hour ago" | grep -i attempt

This logging behavior suggests potential security concerns:

  • Brute force attempts might be obfuscated
  • Password spraying attacks could go undetected
  • Credential stuffing tools often trigger this pattern

For deeper investigation, consider packet capture:

# Capture SSH traffic to/from suspicious IP
tcpdump -i eth0 -w ssh_debug.pcap host 74.194.6.5 and port 22

# Or use strace to monitor sshd process
strace -f -p $(pgrep -f "sshd.*74.194.6.5") -e trace=read,write -s 1024 -o sshd_trace.log

Remember to analyze these captures carefully as they may contain sensitive data.