Are remote pipes fixed in 3.5?

From: James Dennis (jdennis@law.harvard.edu)
Date: 01/23/03

  • Next message: James Dennis: "Re: Question"
    Date: Thu, 23 Jan 2003 11:17:41 -0500
    From: James Dennis <jdennis@law.harvard.edu>
    To: kamath@geekoids.com, secureshell@securityfocus.com
    
    

    I believe I responded a little too quickly without understanding
    everything completely. My apologies.

    -- 
    James Dennis
    Harvard Law School
    "Not everything that counts can be counted,
    and not everything that can be counted counts."
    Sean Kamath wrote:
    > Trolling through the mailing list archives, I've found both on the
    > developer list as well as this list questions about remote pipes
    > causing problems with SSH2 (but not SSH1) connections.  The problem
    > I'm talking about is this:
    > 
    > ssh -2 remotehost yes | dd of=/dev/null count=2
    > 
    > This will hang.  the 'yes' program running on remotehost will block,
    > and ssh will never return.  dd will have exited.  Using -1 will work
    > fine.  Basically, SSH2 will shut down the channel without telling the
    > remote side that stdout has closed.  Note that you can play all sorts
    > of games with -n and -f, but nothing fixes it (if you use -f, the dd
    > will exit and it will "appear" to work, but actually all that happens
    > is the ssh is running in the background, and the remote 'yes' is still
    > running (though blocked)).
    > 
    > ssh -v -v -v output:
    > 
    > ...
    > debug1: Sending command: yes
    > debug1: channel request 0: exec
    > debug2: callback done
    > debug1: channel 0: open confirm rwindow 0 rmax 16384
    > debug2: channel 0: rcvd adjust 32768
    > debug1: channel 0: write failed
    > debug1: channel 0: close_write
    > debug1: channel 0: output open -> closed
    > debug1: channel_free: channel 0: client-session, nchannels 1
    > debug3: channel_free: status: The following connections are open:
    >   #0 client-session (t4 r0 i0/0 o3/0 fd 5/-1)
    > <I Hit ^C Here>
    > debug3: channel_close_fds: channel 0: r 5 w -1 e 7
    > 
    > 
    > Nicholas William's post on the developer list in December of 2001 said
    > something about a patch needing to be applied to nchan.c in
    > chan_failed_write2().  So, is this fixed in 3.5?  I think the
    > developers agree that shutting down the connection is the right thing
    > to do (it's what rsh does), so I just need to know if it's in 3.5 to
    > make it worth upgrading from Solaris 9's ssh.
    > 
    > What I'm trying to do is the ubiquitous backup-over-ssh, and end of
    > tape detection is driving me nuts.  Something as simple as:
    > 
    > ssh host ufsdump / | dd od=/dev/rmt/0
    > 
    > WILL NEVER END when the tape runs out.  Sigh.
    > 
    > Sean
    > 
    > PS If this is not fixed, I'll post to the developer list. . .
    >
    


    Relevant Pages

    • Tru64 Unix v5.1B SSH2D chroot environment
      ... The ssh daemon that came with the system has this feature. ... I can only imagine that the client software is ... Opened channel for session ... debug1: ssh-userauth2 successful: method password ...
      (comp.unix.tru64)
    • Trouble with ssh secure tunnel for VNC
      ... "work" using VNC through a ssh tunnel with port forwarding. ... on work and issuing the command 'vncviewer work:1' from home. ... debug1: Connections to local port 5902 forwarded to remote address work:5901 ... debug1: channel 2: new ...
      (comp.security.ssh)
    • Re: Trouble using VNC thru a ssh tunnel
      ... "work" using VNC through a ssh tunnel with port forwarding. ... > debug1: fd 8 setting TCP_NODELAY ... > debug1: channel 2: obuf empty ... > on both machines for a short period of time, ...
      (comp.os.linux.security)
    • Re: Cant log in as anything but root via SSH
      ... debug1: Connection established. ... Remote protocol version 2.0, ... Are you sure you're connecting to the correct machine? ... $ssh root@xxxxxxxxxxxxxx ...
      (SSH)
    • Are remote pipes fixed in 3.5?
      ... SSH2 will shut down the channel without telling the ... remote side that stdout has closed. ... debug1: channel request 0: exec ...
      (SSH)