openssh bugs - Jan 2014 - [Bug 2196] New: ssh-copy-id: selects "wrong" pubkey

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

            Bug ID: 2196
           Summary: ssh-copy-id: selects "wrong" pubkey
           Product: Portable OpenSSH
           Version: 6.4p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-copy-id
          Assignee: unassigned-bugs at mindrot.org
          Reporter: felix.kaiser at fxkr.net

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

Radek Podgorny <radek at podgorny.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |radek at podgorny.cz

--- Comment #1 from Radek Podgorny <radek at podgorny.cz> ---
hi!

i've been just hit by this bug. ssh-copy-id really should mimic the
behavior of ssh regarding key selection!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

Philip Hands <phil at hands.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at hands.com

--- Comment #2 from Philip Hands <phil at hands.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

--- Comment #3 from Felix Kaiser <felix.kaiser at fxkr.net> ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

--- Comment #4 from Philip Hands <phil at hands.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

--- Comment #5 from Felix Kaiser <felix.kaiser at fxkr.net> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2196

Philip Hands <phil at hands.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned-bugs at mindrot.org |phil at hands.com

--- Comment #6 from Philip Hands <phil at hands.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.