Bug 1135521

Summary: ssh-copy-id fails with message 'Ambiguous output redirect.' with a non-sh style remote shell
Product: Red Hat Enterprise Linux 6 Reporter: Thorsten Scherf <tscherf>
Component: opensshAssignee: Jakub Jelen <jjelen>
Status: CLOSED ERRATA QA Contact: Stanislav Zidek <szidek>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: extras-qa, jjelen, Justin.Hickey, mattias.ellert, mgrepl, plautrba, szidek, tmraz
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: openssh-5.3p1-105.el6 Doc Type: Bug Fix
Doc Text:
The ssh-copy-id utility failed if the account on the remote server did not use an sh-like shell. Remote commands have been modified to run in an sh-like shell, and ssh-copy-id now also works with non-sh-like shells.
Story Points: ---
Clone Of: 1045191
: 1201758 (view as bug list) Environment:
Last Closed: 2015-07-22 06:46:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1045191    
Bug Blocks:    

Description Thorsten Scherf 2014-08-29 14:01:37 UTC
+++ This bug was initially created as a clone of Bug #1045191 +++

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.

--- Additional comment from Petr Lautrbach on 2014-02-26 10:51:26 EST ---

Your fix seems to be reasonable but I've re-send your report to the upstream bugzilla [1] to see how it should be fixed. Thanks for the report.

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

Comment 1 Jakub Jelen 2015-02-17 07:27:36 UTC
The fix proposed by Petr seems ok for me. This fix is on client side, so it is required to update clients to connect to non-sh servers.

Comment 5 errata-xmlrpc 2015-07-22 06:46:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1335.html