sshd "srclimit_penalise: activating penalty": What the Penalty Means

Oct 18 03:51:11 web1 sshd[918]: srclimit_penalise: 203.0.113.7/32: activating ipv4 penalty of 20 seconds for penalty: failed authentication
Oct 18 04:02:35 web1 sshd[918]: srclimit_penalise: 198.51.100.22/32: activating ipv4 penalty of 16 seconds for penalty: connections without attempting authentication
Oct 18 04:19:07 web1 sshd[918]: srclimit_penalise: 2001:db8::42/128: activating ipv6 penalty of 20 seconds for penalty: exceeded LoginGraceTime

What it means

OpenSSH tracks, per source address, connections that ended in a way that may represent an attack, and adds seconds to that source’s penalty each time. This line is written at the transition: the accrued penalty has passed the minimum threshold, the entry was not already active, and sshd is now refusing connections from that address range. The manual puts it plainly: “If a penalty is enforced against a client then its source address and any others in the same network, as defined by PerSourceNetBlockSize, will be refused connection for a period.” It also notes that “A penalty doesn’t affect concurrent connections in progress”.

Read the four fields in order:

• The address with its mask — the source address after PerSourceNetBlockSize has been applied. The default is 32:128, “which means each address is considered individually”, so you normally see a single host as /32 or /128.
• ipv4 or ipv6 — which penalty table the entry lives in. The manual notes IPv4 and IPv6 addresses are tracked separately.
• The seconds — the penalty remaining when it was activated. Because penalties accumulate, this is a running total, capped by max (default 10m), not the cost of one bad connection.
• The reason — the string that tells you what the client did.

The srclimit_penalise: prefix is the function name; the penalty table lives in the listening sshd process, which is why these lines carry the listener’s PID rather than a per-connection sshd-session PID.

Is it an attack?

The reason string maps one-to-one onto a PerSourcePenalties keyword and its documented default duration:

Reason in the line	Keyword (default)	Reading
penalty: failed authentication	authfail (5s)	Clients “that disconnect after making one or more unsuccessful authentication attempts” — password or key guessing. Pair with Failed password and Invalid user lines
penalty: connections without attempting authentication	noauth (1s)	Banner grabs and port surveys; the manual warns this “may penalise legitimate scanning tools such as ssh-keyscan(1)“
penalty: exceeded LoginGraceTime	grace-exceeded (10s)	Connections that sat open past LoginGraceTime — see Timeout before authentication
penalty: connection prohibited by RefuseConnection	refuseconnection (10s)	The administrative refusal you configured, firing as intended
penalty: caused crash	crash (90s)	A client that crashed sshd — rare, and the one reason here worth an immediate, full investigation

On an internet-facing host the first two reasons are routine background noise and the line is a sign the control is working. What changes severity is the company the line keeps: many authfail penalties against named staff or service accounts, a penalty for a source inside your own estate, or any Accepted line from an address that was being penalised.

How to investigate

Pivot on the penalised address and on the reason counts.

# Last 24 hours (Debian/Ubuntu unit is ssh; on RHEL/Fedora use -u sshd)
sudo journalctl -u ssh --since "24 hours ago" | grep 'srclimit_penalise:'

# Most-penalised sources (/var/log/auth.log; on RHEL/Fedora /var/log/secure)
sudo grep -oP 'srclimit_penalise: \K\S+(?=: activating)' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

# Why they were penalised
sudo grep -oP 'activating \S+ penalty of \d+ seconds for \K.+$' /var/log/auth.log \
  | sort | uniq -c | sort -rn

# What one source actually did, in order
sudo grep '203\.0\.113\.7' /var/log/auth.log | tail -40

# Did anything from these sources get in?
sudo grep -E 'Accepted (publickey|password)' /var/log/auth.log | tail -50

# The penalty settings actually in effect
sudo sshd -T | grep -iE 'persourcepenalt|persourcenetblocksize|maxauthtries|logingracetime|passwordauthentication'

An exported auth.log can be grouped by source in the browser log analyzer, and the one-source-many-names pattern behind most authfail penalties is encoded in the SSH brute-force rule.

How to stop it

The line is the remedy, not the problem, so the work is making it rarer and making it count.

• Keep PerSourcePenalties enabled. The manual states penalties are enabled by default and may be disabled with the no keyword; individual durations are overridden by keyword arguments such as "crash:2m".
• Exempt addresses you control with PerSourcePenaltyExemptList — your bastion, scanners and monitoring — so a health check never locks itself out. The default is to exempt nothing.
• Reduce exposure. Restricting port 22 at the firewall, or putting it behind a VPN or bastion, removes most penalised connections entirely.
• Take passwords out of play. PasswordAuthentication no (default yes) and, where PAM is enabled, KbdInteractiveAuthentication no (default yes); the manual notes PAM keyboard-interactive authentication usually serves an equivalent role to password authentication.
• Tighten the limits that feed penalties: MaxAuthTries (default 6), LoginGraceTime (default 120 seconds), PermitRootLogin (default prohibit-password) and AllowUsers, which by default allows login for all users.
• Watch the table size if you are facing a distributed botnet: max-sources4/max-sources6 default to 65536 each, and the default overflow mode is permissive, which “allows new connections by removing existing penalties early”.

sudo sshd -t && sudo systemctl reload ssh

Validate before reloading, and keep a working session open until a new one connects.