openssh bugs - Feb 2014 - [Bug 2206] New: ssh-copy-id fails with message 'Ambiguous output redirect.' with a non-sh style remote shell

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

            Bug ID: 2206
           Summary: ssh-copy-id fails with message 'Ambiguous output
                    redirect.' with a non-sh style remote shell
           Product: Portable OpenSSH
           Version: 6.5p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh-copy-id
          Assignee: unassigned-bugs at mindrot.org
          Reporter: plautrba at redhat.com

This is originally Fedora bug
https://bugzilla.redhat.com/show_bug.cgi?id=1045191 but it's also
applicable to the vanilla sources:

Description of problem:
When using ssh-copy-id to copy the ssh public key to a remote server,
if the account on the remote server uses a shell that is not based on
sh or bash (like tcsh), then the script will fail with the message
'Ambiguous output redirect.'. This message is caused by the redirection
of STDOUT and STDERR using the sh syntax 2>&1 which is invalid for
tcsh.

Specific details:
In the file /usr/bin/ssh-copy-id at line 275 we have the following:

if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh
.ssh/authorized_keys ; fi" \

This command is being executed on the remote machine using the default
shell of the remote account. If the remote shell is tcsh (or any other
shell that doesn't support the 2>&1 syntax), the
     if type restorecon >/dev/null 2>&1 ;
command fails.

Version-Release number of selected component (if applicable):
6.2p2-6.fc19

How reproducible:
Always

Steps to Reproduce:
1. Create an account on a remote machine using tcsh for the shell (or
any other shell that doesn't support the 2>&1 syntax)
2. Generate an ssh key on the local machine
    ssh-keygen -t rsa -b 2048
3. Run ssh-copy-id on the local machine (the command below assumes the
login id is the same on both machines
    ssh-copy-id x.x.x.x

Actual results:
The script exits with
    Ambiguous output redirect.

Expected results:
The script successfully runs with 
    Number of key(s) added: 1

    Now try logging into the machine, with: "ssh 'x.x.x.x'"
    and check to make sure that only the key(s) you wanted were added.

Additional info:
I was able to fix this bug by basically specifying that the ssh command
should use the sh shell instead of the default shell of the remote
account. The changes I made to the ssh-copy-id script are as follows:

Starting at line 273, change the lines
    umask 077 ;
    mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ;
    if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh
.ssh/authorized_keys ; fi" \

To the following single line - add "exec sh -c" at the beginning and
surround the commands in single quotes
    exec sh -c 'umask 077 ; mkdir -p .ssh && cat >>
.ssh/authorized_keys || exit 1 ; if type restorecon >/dev/null 2>&1 ;
then restorecon -F .ssh .ssh/authorized_keys ; fi'" \

I'm not sure if this is the best fix, but it works regardless of the
remote shell.

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

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

Martin Ueding <von.mindrot.org at martin-ueding.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |von.mindrot.org at martin-uedi
                   |                            |ng.de

--- Comment #1 from Martin Ueding <von.mindrot.org at martin-ueding.de>
---
I use the Fish shell which does not use the &&. So this causes errors
here as well:

ssh-copy-id mu at martin-pi.local
/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   
mu at martin-pi.local's password:                                          
fish: Expected a command name, got token of type 'Job im Hintergrund
ausf?hren'. 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 ;                               
                                               ^                        
The suggestion by Petr Lautrbach sounds good, since you cannot rely on
the shell, you have to start your own. Maybe some script could be
shipped with the openssh-server that accepts the keys?

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

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

Michael <abc.mikey at googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abc.mikey at googlemail.com

--- Comment #2 from Michael <abc.mikey at googlemail.com> ---
Hello,

I am experiencing the same problem with the fish shell. The reported
solution seems like it should really be implemented. Relying on the
shell of the server seems unreliable at best.

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

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

Radek Podgorny <radek at podgorny.cz> changed:

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

--- Comment #3 from Radek Podgorny <radek at podgorny.cz> ---
same issue here (with fish shell on remote). what can i do to get this
fixed?

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

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

--- Comment #4 from Radek Podgorny <radek at podgorny.cz> ---
Created attachment 2756
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2756&action=edit
use "sh" on remote system

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

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

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #5 from Jakub Jelen <jjelen at redhat.com> ---
Actually we had to use one-line version of this patch, because some
other shells (tcsh) do not support multi-line arguments well. The
readability is not better, but we achieved more portability.

We carry in Fedora this patch:
http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix-ssh-copy-id-on-non-sh-shell.patch

Upstream doesn't seem to be interested in fixing this so at least for
the others who will encounter such problems and who would like to fix.

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

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

Philip Hands <phil at hands.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at hands.com
           Assignee|unassigned-bugs at mindrot.org |phil at hands.com
             Status|NEW                         |ASSIGNED

--- Comment #6 from Philip Hands <phil at hands.com> ---
Thanks for the patch, and sorry for not getting to it sooner.

My latest version, incorporating something very similar is available
here:

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

which I'd hope works for you (confirmation would be nice), and will
hopefully make it's way into OpenSSH in the not too distant future.

Cheers, Phil.

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