Bug 24399

Summary: OpenSSH forced commands munge output
Product: Base System Reporter: cjclark <cjclark>
Component: binAssignee: Crist J. Clark <cjc>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.2-STABLE   
Hardware: Any   
OS: Any   

Description cjclark 2001-01-17 07:40:01 UTC
        OpenSSH "forced commands," a command specified in the
	authorized_keys file, have their output mangled. It looks like
	their is some UNIX-MSDOS conversion going on. Newlines, \n,
	are substituted with \r\n.

Fix: 

No workaround other than to not use forced commands.

        After a quick look at the code, I can't see how a "forced
	command" would produce different results than one provided on
	the command line. But that's what the tests show.
How-To-Repeat: 
        Assuming you have sshd running locally and don't have 
	anything in your configs to break this kind of thing.
        $ man ssh > ssh_1.cat
        $ ssh-keygen -f sshtest -N "" -C SSH-Test  
        $ { echo 'command="cat ssh_1.cat" '; cat sshtest.pub; } >> .ssh/authorized_keys
        $ ssh -i sshtest localhost > ssh_2.cat
        $ cmp ssh_1.cat ssh_2.cat
        ssh_1.cat ssh_2.cat differ: char 79, line 1
        $ tr -d '\r' < ssh_2.cat > ssh_3.cat
        $ cmp ssh_1.cat ssh_3.cat
        $
        But this works,
        $ ssh localhost "cat ssh_1.cat" > ssh_4.cat
        cjc@localhost's password:
        $ cmp ssh_1.cat ssh_4.cat
        $
Comment 1 Kris Kennaway freebsd_committer freebsd_triage 2001-01-17 09:38:37 UTC
Responsible Changed
From-To: freebsd-bugs->green

Over to the maintainer
Comment 2 cjclark 2001-01-18 19:14:09 UTC
Immediately after submitting this, a workaround did occur to me. I
have been using it and it seems to work fine. It is, however, so ugly,
so hideous, I considered ROT-13'ing the rest of this mail for the
squeamish. I basically put,

  command="create_output args | uuencode ssh_raw.out" ...

In the authorized_keys file on the server, and do a,

  ssh server | uudecode -p | use_output args

At the client end. Since the problem seems to be "\n" -> "\r\n"
translation, this works.

However, this still needs to be fixed.
-- 
Crist J. Clark                           cjclark@alum.mit.edu
Comment 3 Crist J. Clark freebsd_committer freebsd_triage 2001-07-21 21:59:43 UTC
State Changed
From-To: open->closed

The correct way to handle data being sent through stdout when using 
forced commands is to add the 'no-pty' specification in the 
autorized_keys entry for the host. 


Comment 4 Crist J. Clark freebsd_committer freebsd_triage 2001-07-21 21:59:43 UTC
Responsible Changed
From-To: green->cjc

Closing my own old PR.