ssh-copy-id fails by making assumptions about the default shell on the remote machine

[Muelli]

ssh-copy-id 10.200.17.160
/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: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
foo@10.200.17.160's password:
fish: Expected a command name, got token of type “Run job in background”. Did you mean “COMMAND; and COMMAND”? See the help section for the “and” builtin command by typing “help and”.
Standard input: mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ;
                                               ^

I expected to be able to copy my key.

An approach I see is for ssh-copy-id to run bash -c ....

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: openssh-client 1:6.7p1-5ubuntu1.3
ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2
Uname: Linux 3.19.0-25-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.3
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Sep 7 15:56:44 2015
RelatedPackageVersions:
 ssh-askpass N/A
 libpam-ssh N/A
 keychain N/A
 ssh-askpass-gnome 1:6.7p1-5ubuntu1.3
SSHClientVersion: OpenSSH_6.7p1 Ubuntu-5ubuntu1.3, OpenSSL 1.0.1f 6 Jan 2014
SourcePackage: openssh
UpgradeStatus: No upgrade log present (probably fresh install)

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

This sounds reasonable. ssh-copy-id should not be making any assumptions about the user's default shell on the remote machine. It might be better for it to call sh explicitly, since sh (compatibility) is more universally availability.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Carl-Eric Menzel (duesenklipper)]

This should definitely be fixed in ssh-copy-id - making these assumptions is just bad.

However, I found a workaround that is convenient for me at least and that I think could be a stopgap for others too, until such time as ssh-copy-id is fixed. I wrote it up here: http://blog.duesenklipper.de/2015/10/05/interactive-fish-without-breaking-sh-scripts.html

[Christian Ehrhardt  (paelzer)]

Discussed:
https://github.com/fish-shell/fish-shell/issues/2292

Fixed in:
https://github.com/fish-shell/fish-shell/issues/150

So TL;DR it was more seen as an issue in fish and should work in recent versions of fish now.
Reassigning to fish due to that.

The discussions and fixes in fish are very noisy and complex - it would be great if one could test that on a newer release.

[David Adam (zanchey)]

No, it will not work in fish - that issue was closed as "will-not-implement".

The fix is that `ssh-copy-id` should run `sh -c "mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1"` on the remote machine. I see multiple patches submitted upstream, but I'm not aware that any of them ever got merged.

[Adam Bell (arbell)]

I am unsure whether anything was ever changed in the openssh package (this may be an issue in the future with other shells), but this no longer appears to be a problem in the Xenial fish package -- I was unable to reproduce the issue with a current Xenial installation.

Also, the fish shell group has implemented "&&" into the shell now: https://github.com/fish-shell/fish-shell/issues/4620