Hi, I have many SSH keys named "id_rsa.NAME.pub" in addition to my default SSH key named "id_rsa.pub". Since OpenSSH 1.13 [1], ssh-copy-id uses "ls -t ${HOME}/.ssh/id*.pub" to determine which key to copy by default. I believe this "all keys, newest first" approach is very unlikely to be what the user intended, especially since SSH itself always tries "id_rsa.pub" by default. I think it would be better to use "${HOME}/.ssh/id_{rsa,dsa,ecdsa}.pub". Also, ssh-copy-id should show the path to the pubkey that it copied, maybe even the pubkey itself. Cheers! [1] http://anoncvs.mindrot.org/index.cgi/openssh/contrib/ssh-copy-id?annotate=1.15
hi! i've been just hit by this bug. ssh-copy-id really should mimic the behavior of ssh regarding key selection!
The theory behind this code was that (in the absence of an explicit -i) the most recently generated key was the one that is most likely to need to be added to remote servers. If you want some other key to be the default, all you need to do is touch the file to make it the default instead. If you have ideas about how one might cater as easily to people that are not using ssh'd default as their main key, please make suggestions.
Is there any reason not to have your main key in id_rsa (other than aesthetics)? I can actually think of one: in conjunction with IdentitiesOnly in .ssh/config, to make SSH not try *any* key by default (lest the wrong key end up in the wrong SSH servers logs). But these users wouldn't want ssh-copy-id to pick a key by default either, so that's ok. Anyway, in my opinion ssh-copy-id is just a (very useful) auxiliary tool and so should follow OpenSSHs conventions, rather than invent its own. I suspect that the vast majority of users expect it to do, instead of the newest key. So here's my suggestions: 1. Move the file (And if you *really* want SSH to use a different key by default, explicitly configure that in .ssh/config with "Host *". You can still override it on a per-host basis.) 2. If you can't, use a symlink 3. If you can't, use a shell alias
The problem is that ssh will use any of id_rsa, id_dsa, id_ecdsa, or id_ed25519, so it's not completely obvious which of those if should choose if there's more than one of them. The current approach allows one to choose. I note that it's actually documented behaviour: The default_ID_file is the most recent file that matches: ~/.ssh/id*.pub, (excluding those that match ~/.ssh/*-cert.pub) so if you create a key that is not the one you want ssh-copy-id to use, just use touch(1) on your preferred key's .pub file to reinstate it as the most recent.
I see. And SSH itself tries all of them, so it doesn't have that problem. Maybe ssh-copy-id could take the newest of just these four then? It'd be closer to OpenSSHs behavior. It'd allow for user choice. And there's no problem with new "secondary keys" (matching a fairly arbitrary name pattern) being used instead of "primary keys" (with one of a small set of default names). Also, ssh-copy-id could print the path to the key it installed.
It seems like a good idea to mention which file is being used (when it is using one, rather than then agent) so I've just added this: http://git.hands.com/?p=ssh-copy-id.git;a=commitdiff;h=fd3e8b115e160a1332773cd8e06a3305d0d680ab;hp=1b931894de0614099255244be789ad097fd0948a I happen to make use the current behaviour, with a file that's not one of the defaults as my main key, but perhaps I'm the only person that does. However, I wouldn't want to remove that only to discover that I'm not alone and so have a load of people hankering after the current behaviour. I hope the INFO message goes at least some way to addressing you concerns. Cheers, Phil.
Close all resolved bugs after 7.3p1 release