Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1045191 - ssh-copy-id fails with message 'Ambiguous output redirect.' with a non-sh style remote shell
Summary: ssh-copy-id fails with message 'Ambiguous output redirect.' with a non-sh sty...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 20
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1135521
TreeView+ depends on / blocked
 
Reported: 2013-12-19 20:32 UTC by Justin Hickey
Modified: 2015-04-09 09:08 UTC (History)
6 users (show)

Fixed In Version: openssh-6.6.1p1-12.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1135521 (view as bug list)
Environment:
Last Closed: 2015-02-18 16:50:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenSSH Project 2206 0 None None None Never

Description Justin Hickey 2013-12-19 20:32:10 UTC
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.

Comment 1 Petr Lautrbach 2014-02-26 15:51:26 UTC
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 2 Fedora End Of Life 2015-01-09 22:23:02 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Justin Hickey 2015-01-15 14:27:43 UTC
This bug still exists in Fedora 20, thus I bumped the version to 20.

Comment 4 mikey 2015-03-27 10:05:49 UTC
Still an issue on Fedora 21, can this be reopened. I have updated upstream bug report.

Comment 5 Fedora Update System 2015-03-30 06:37:11 UTC
openssh-6.6.1p1-12.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/openssh-6.6.1p1-12.fc21

Comment 6 Fedora Update System 2015-04-09 09:08:06 UTC
openssh-6.6.1p1-12.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.