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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
