On 09.12.21 22:17, TJ Saunders wrote:
I wonder whether "please add this pubkey for target user X (without telling me which file exactly it went into), after I auth for either X or root" would be suitably well-defined a task to roll a standardized API + Subsystem implementation that a remote rollout tool would have to only throw auth, username and pubkey at?Something like the "publickey" SSH subsystem? https://www.ietf.org/rfc/rfc4819.txt
(... which seems to be implemented as an OpenSSH-compatible server-side add-on:
https://github.com/grawity/ssh-publickeyd *possibly* - I find the statement's wording rather confusing - in JunOS: https://www.juniper.net/documentation/us/en/software/junos/standards/topics/concept/system-access.html and in a number of clients, but *not* the OpenSSH one.)Nice ... but the spec covers only the case of managing an account's authorized_keys *when authenticating for the account itself*, not the scenario of the sysadmin generating the account on a no-passwords-permitted system, or having to remove pubkeys of compromised keypairs or a user losing access ...
P.S.: And I see (only) "~/.ssh/authorized_keys" hardcoded into ssh-publickeyd as well ... :-/
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
