ssh-copy-id fails when a private key file (without .pub suffix) is not present in the same directory as the public key file. # ls ~/.ssh/id_rsa* /root/.ssh/id_rsa /root/.ssh/id_rsa.pub # cp -vf ~/.ssh/id_rsa.pub /tmp/. ‘/root/.ssh/id_rsa.pub’ -> ‘/tmp/./id_rsa.pub’ # ssh-copy-id -i /tmp/id_rsa.pub root@localhost /usr/bin/ssh-copy-id: ERROR: failed to open ID file '/tmp/id_rsa': No such file or directory There's no switch that would disable checking for the private key file. There's no keypair verification done, simply creating an empty /tmp/id_rsa file makes ssh-copy-id work again.
Although creating an empty corresponding private-key file will get past the "ERROR: failed to open ID file" problem, it doesn't solve the issue -- because the empty privkey file will cause the next step to fail: /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system. That last error message is erroneous, because the ssh *login* failed, not because the key was already in the remote host's authorized_keys file. I used to be able to use ssh-copy-id to add a colleague's public key to a remote host without having to know his private key. This change no longer allows that, and isn't controllable by options. Therefore, I consider this change a REGRESSION.
Created attachment 2345 [details] add a '-l' option for a legacy mode This patch adds a new option to ssh-copy-id -l for a legacy mode. The legacy mode doesn't check an existence of a private key and doesn't do remote checks.
ping? Do you have any comments or objections? I've seen several people complaining about the new ssh-copy-id and "-l" for legacy mode seems to me to be reasonable trade-off
+1 for this being a problem. 1/2 of my use of ssh-copy-id is to copy other people's .pub keys to give them access. It follows that nobody in this same position will have the other person's private key file. A flag, or similar method, to indicate that this is a not the initiator's key would be great.
I just had the same problem. I had to install a pubkey of a coworker to some servers and had to fall back to copy&paste method as I ofc did not have his privkey. See also my fresh comment on bug #2331 - I suspect the issue here is caused by the same magic that caused the issue there. Maybe just remove that magic in favor of a "do what I say" mode.
Please add this, I also ran into it while trying to use the program to allow other people access. I'm not sure why it would need to be called a "legacy" mode, it's more of a "blind" mode or a "no verification" mode.
In my git repo: http://git.hands.com/ssh-copy-id there's now a version that has a '-f' (force) option that does what the legacy option was suggested to do (i.e. just go ahead and install things) It would be helpful if you could test that and say whether it deals with the problem for you. Cheers, Phil.
Close all resolved bugs after 7.3p1 release