(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