(PerSource)Penalties default perhaps too aggressive?

[Damien Miller]

On Wed, 10 Sep 2025, Colin Watson wrote:

> On Wed, Sep 10, 2025 at 09:13:54PM +0200, hvjunk wrote:
> > Busy with my first deployment/lab test of PVE9/Debian13 that uses OpenSSH
> 10.0-p1 (1:10.0p1-7 Deb package version) and my normal ssh-copy-id triggers
> the penalty and then doesn’t install the keys. In *my* case I have like 4x
> keys to load, so ssh-copy-id tries them all, and then get the penalty triggers
> and the keys aren’t loaded.
> 
> I cherry-picked a post-10.0 upstream fix in this area into Debian 
> testing/unstable, but haven't yet issued a stable update for it.  Does 
> https://bugs.debian.org/1080350 sound as though it matches your 
> symptoms?

AFAIK that's a different condition: that would cause MaxStartups to
"latch" on under some situations.

I think what is happening here is that ssh-copy-id is making a separate
ssh connection for each key it tries. If these connections fail because
the key is not accepted, then each failed connection will add the
"authfail" penalty to the running total for your source address.

In the default configuration, a single authfail penalty (5s) is below
the enforcement threshold (15s), so it take at least three attempts to
reach the threshold. Trying four keys this way that fail authentication
would certainly hit the penalty.

Once the penalty thresold is hit, connections are blocked until it
expires.

Maybe ssh-copy-id's behaviour of filtering keys by attempting a
connection with each one could be modified. Perhaps instead it could
attempt authentication normally and filter keys by grepping in
authorized_keys. On the other hand there's probably a reason for why it
works the way it does currently.

Another, more annoying thing ssh-copy-id could do is ratelimit
connections to ensure that the the penalty threshold is never it. If it
assumed the default PerSourcePenalties, then it would only need to do
this if when it is asked to copy three or more keys and even then would
only need to throttle after the second key is tried.

If you're in control of the server, you can also avoid this condition
by reducing the authfail penalty and/or increasing the "min" penalty
threshold. You want authfail * nkeys < min

Alternately, as others have suggested, you can allow-list your client
via PerSourcePenaltyExemptList.

Finally, the PerSourcePenalties defaults are little more than my guesses
at values that will usefully throttle attacks without significantly
affecting legitimate traffic. Feedback is always welcome.

-d