(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