(PerSource)Penalties default perhaps too aggressive?

Jochen Bern Jochen.Bern at binect.de
Fri Sep 12 20:39:16 AEST 2025


On 12.09.25 12:08, hvjunk wrote:
>> I understand that the purpose of this script is to use the (one)
>> working keypair(s) to "put the other ones on the server". How does
>> it handle *that* objective in cases where it cannot observe the
>> storage the pubkey is / may be in? And what behavior do you *want*
>> in such a case?
> 
> What you are trying to do here

Simply put, this question equates to "does it actually make any *sense* 
to try individual logins with every single privkey available?".

If you want pubkeys that are allowed to log in, but absent from
~/.ssh/authorized_keys specifically, to get added to *that* file 
nonetheless, the information whether some other, potentially invisible 
mechanism *already* blesses them is completely useless to the 
algorithm-to-be.

All you need in that case is *one* working login with *whichever* auth 
that works, and as I said, the only sane approach to do that is to 
assume that the user has a setup that *already works* for the 
*completely normal* SSH login. Including individually tweaked 
server-side rate limits or even more fancy setups (elaborate "Match"es 
in the client's ~/.ssh/config?), if such is necessary.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4336 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20250912/725496af/attachment.p7s>


More information about the openssh-unix-dev mailing list