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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
