currently the command ssh-copy-id requires shell-access on the server-side. To allow the usage of ssh-copy-id on systems where shell-access is not allowed like on some commercial storage providers (e.g. hetzner storage-box), the modification of authorized_keys could be done through downloading, modifying and uploading instead of executing a command on the server-side. If nothing prevents this, we could provide some developer-resources to achieve this with an optional flag like '--use-sftp' or '-s'.
+1 that I would find this feature useful, and could make an attempt at implementing it. The university that I work for provides sftp-only access to its data stores. This feature would help us support researchers and students using key-based authentication. Eerily, I found this bug posted on the same day as I was considering it.
hard parts of this may include: * ensuring umask is set correctly * avoiding race conditions in modifying authorized_keys
I made a draft pull-request: https://github.com/openssh/openssh-portable/pull/199
Created attachment 3441 [details] patchfile to solve #3201 this is a patchfile for the same changes as in https://github.com/openssh/openssh-portable/pull/199/commits/81658011c9a7f4330bf8a49ec4b3f2f129215fa1 but ported to http://git.hands.com/ssh-copy-id.git
Sorry I didn't notice this earlier -- I'll try to have a look at it shortly. Thanks for the contribution :-)
Sorry for the delay -- I was distracted by Debconf, and it took me a while to get back to this. Anyway, thanks for the patch. While testing it noticed that it doesn't manage to tidy up after itself, because the trap gets replaced, and while fixing that I noticed a few other minor improvements, which fired my enthusiasm to the point that I ended up setting up some CI tests for it, and created a repo. on gitlab to run them. See here: https://gitlab.com/phil_hands/ssh-copy-id/-/tree/bug/3201 Perhaps you could test that to ensure that it works for you (I don't normally run an sftp server, so it would be nice to confirm that it works in the real world as well as in my tests). I suspect that there's a potential issue if something were to prevent sftp from writing the new file (e.g. a full disk) since it would presumably succeed in removing the old file and then fail to replace it. Perhaps one should create a new file and then rename it, but maybe one could make that fail due to permission problems ... but I guess that would be fail-safe at least. Thoughts? Cheers, Phil.
Hi Phil, thanks for the review and the refactoring. We tested your code against hetzner storage-boxes and everything worked fine.
Thanks for testing. I've merged the feature into the 'main' branch now. Cheers, Phil.
Thanks all, I've pulled in the changes from Phil's tree.
closing resolved bugs as of 8.6p1 release