Bug 2349 - ssh-copy-id transfer keys into current directory instead of home folder
Summary: ssh-copy-id transfer keys into current directory instead of home folder
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh-copy-id (show other bugs)
Version: 6.7p1
Hardware: All Linux
: P5 normal
Assignee: Philip Hands
URL:
Keywords:
Depends on:
Blocks: V_7_2
  Show dependency treegraph
 
Reported: 2015-02-04 14:26 AEDT by Gabriel Magno
Modified: 2016-08-02 10:42 AEST (History)
1 user (show)

See Also:


Attachments
Possible patch to copy key into home folder (instead of current directory) (619 bytes, patch)
2015-02-04 14:26 AEDT, Gabriel Magno
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Magno 2015-02-04 14:26:25 AEDT
Created attachment 2543 [details]
Possible patch to copy key into home folder (instead of current directory)

On the server, I configure my user to change the current directory upon login. For example, I add the command "cd /path/to/project" in my ~/.bashrc.

Then, on the client, if I try to "ssh-copy-id user@myserver", it will run smoothly (identifies that it need to add new key, ask for password, says it added the key and ask to try to login), but when I try to login, it will keep asking for password. If I try to execute ssh-copy-id again it keeps identifying that the key need to be added (as if it was not added before). I verified permissions, and they are correct.

I found out that the directory "/path/to/project/.ssh" was created, as was an "authorized_keys" file inside it, containing multiple repeated lines of my public key (one for each of the attempts of issuing ssh-copy-id).

By looking into ssh-copy-id's source script, I could see that it assumes it is already in the home folder, and appends the new keys into ".ssh/authorized_keys". Shouldn't it be appended to "~/.ssh/authorized_keys"?
Comment 1 Philip Hands 2015-11-26 10:01:57 AEDT
That's odd, since I just tried to reproduce the problem, and with a cd in my ~/.bashrc, interactive logins end up in another directory, but commands seem to be run in the homedir.

Could you mention which versions of software you're getting this effect with?

Anyway, I don't suppose adding a 'cd' command at the start would do any harm, so maybe I'll do that anyway.
Comment 2 Gabriel Magno 2015-11-27 02:36:20 AEDT
I've just tested ssh-copy-id (openssh 7.1p1) to copy my key to a different server than I tried before, and it worked fine. Then, I guess it's probably some weird behaviour of the server.

Anyway, I think it might be a good idea for ssh-copy-id to cover these cases. You propose to add a "cd ~". Why not just reference the authorized keys file as "~/.ssh/authorized_keys"?
Comment 3 Philip Hands 2015-11-29 06:33:18 AEDT
I had a feeling that cd without a parameter taking you home was a feature before ~ was, but I'm probably remembering something awful from the 80s, like Xenix, which hopefully means we don't have to care any more.

BTW Am I right in thinking that you're no longer able to reproduce this anyway?  If not, and you still have access to the failing system, please try the latest version from here:

  http://git.hands.com/ssh-copy-id

and tell me if that fixes the problem for you.

Cheers, Phil.
Comment 4 Damien Miller 2016-08-02 10:42:24 AEST
Close all resolved bugs after 7.3p1 release