(PerSource)Penalties default perhaps too aggressive?

[Jochen Bern]

On 11.09.25 09:04, hvjunk wrote:
>> 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.
> 
> Well, that is not always that easy to do:
> What about keys in LDAP/etc.?
> What about keys in a different directories like
> /etc/ssh/authorized_keys.d/${user}/ ?
> 
> How do you propose it would check for those other sources, other than
> reimplementing a openssh server config parser? What about the cases
> where it hits a chrooted environment after login that it can’t check
> those other sources? or the system is hardened and the user can’t read
> the /etc/ssh/sshd_config* files ?

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?

If it adds a pubkey to $HOME/.ssh/authorized_keys if it's missing 
*there*, even if it *did* work to authenticate a login, then that's a 
"THAT file is my mission, I want it able to serve all accesses 
*independent* of all other setup" approach and the potential other 
storages - including the fact whether *they* allowed the keypair to log 
in - are entirely irrelevant to it.

If, on top of that, the script is run interactively, the sane approach 
would be "trust the user to have a working setup", do a normal SSH 
login, and handle the *known and accessible* storages from there.

On the other hand, if you do *not* want to duplicate pubkeys that 
already are in some other storage, and assuming that the sshd is 
sufficiently close to OpenSSH's feature set:
-- Do the same as above, but
-- for all pubkeys you add yourself, add a couple "markers"
    (I have no idea when / in what order these were introduced or which
    do or don't take priority over the system-wide setup, but all of
    command=, environment=, expiry-time=, no-pty seem suitable)
-- *Now* cycle through the privkeys for the pubkeys you added available
    on the client side and try them for a login (in the case of expiry-
    time=, once before and once after the timeout)
-- If you get a (first) login denied, you either hit a rate limit, an
    unsupported algo, or a server that doesn't respect authorized_keys in
    the first place
-- If the login works, check the markers to see whether it was the entry
    you added that made it work
-- Finally, try the all-keypairs-allowed login again
-- If it's denied, you *did* hit a rate limit (and cannot do anything
    anymore for the moment)
-- If not, re-edit authorized_keys and "unmark" or delete the added
    pubkeys as appropriate

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/96dc52f9/attachment.p7s>