openssh unix dev - Dec 2021 - ssh-copy-id vs PasswordAuthentication no

On 12/9/21 10:21, Harald Dunkel wrote:
> Hi folks,
> 
> to support "PasswordAuthentication no" it might be undesirable
> to add new users with an initial password in /etc/passwd.
> 
> I wonder if it would be possible to support a "destination user"
> option on the ssh-copy-id command line, e.g.
> 
>  ????ssh-copy-id -i somepath/id_ed25519.pub -u systemuser1 root at newhost
> 
> to add the pubkey to ~systemuser1/.ssh/authorized_keys on the
> remote host?
This would be a RFE on the repository for the ssh-copy-id:

https://gitlab.com/phil_hands/ssh-copy-id/

There is already which asks for someething similar:

https://gitlab.com/phil_hands/ssh-copy-id/-/issues/3

Contributions would be certainly welcomed.

Regards,
-- 
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

On 09.12.21 14:04, Jakub Jelen wrote:
> On 12/9/21 10:21, Harald Dunkel wrote:
>> I wonder if it would be possible to support a "destination
user"
>> option on the ssh-copy-id command line, e.g.
>> ?????ssh-copy-id -i somepath/id_ed25519.pub -u systemuser1 root at
newhost
>> to add the pubkey to ~systemuser1/.ssh/authorized_keys on the
>> remote host?
> 
> This would be a RFE on the repository for the ssh-copy-id:
> https://gitlab.com/phil_hands/ssh-copy-id/
I note that, nonetheless, any such tool
a) faces the problem of determining where exactly to put the pubkey
    (ssh-copy-id only knows about the most basic default locations
    of OpenSSH and dropbear), if it is to *reliably* do its job,
b) which, in the case of an OpenSSH-based target machine, requires
    knowledge of sshd_config (Authorized* statements, including any
    relevant Match clauses) and, thus, both
c) root access to the target machine, even if the file eventually
    pinpointed can be written by the nonprivileged target user, and
d) quite a boatload of options- and filesystem-parsing code that
    would essentially duplicate that of the target machine's sshd.

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?

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20211209/1a87a7d5/attachment.p7s>