Mailing List Archive

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@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.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@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

> 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

Cheers,
TJ
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 12/9/21 23:17, TJ Saunders wrote:
[snip]
> Something like the "publickey" SSH subsystem?
> https://www.ietf.org/rfc/rfc4819.txt

RFC 4819 was interesting to read, especially section 4. Has it been
implemented anywhere?

Would the correct way to read and manipulate authorized_keys files use
authfile.c ? Even though the file format is a little weird, and too
much for awk, it can be processed rather easily in perl, and ssh-copy-id
is shell.

/Lars
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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