Re: SSH Notes

["Thomas Chadwick" <j_tetazoo at hotmail dot com>]

> From: Harold L Hunt II <huntharo@msu.edu>
> Reply-To: cygwin-xfree@cygwin.com
> To: cygwin-xfree@cygwin.com
> Subject: SSH Notes
> Date: Thu, 03 Oct 2002 19:16:42 -0400
>
> X11 tunnelling via SSH has always been somewhat of a mystery to me and to 
> most other Cygwin/XFree86 users.  I knew that the instructions that I 
> provided in the Cygwin/XFree86 User's Guide worked, but I did not know what 
> most other methods of starting ssh and Cygwin/XFree86 did not work.  I have 
> now found out what is going on, and I actually think that we may want to 
> make a patch to openssh for Cygwin to make the system more fool-proof.  
> Below are my notes on what I found.
>
> Notes on X11 Tunnelling
> =======================
>
> 1) The key to X11 tunnelling via openssh is to have the ``DISPLAY'' 
> environment variable defined in your Cygwin bash shell BEFORE you ssh into 
> your remote host.  That is, you must run the following command before you 
> run ssh:
>
> export DISPLAY=127.0.0.1:0.0
>
> 2) You do not have to have your X Server (Cygwin/XFree86) running when you 
> open your ssh session to your remote machine, but you have to have the 
> DISPLAY variable set to a valid value.  Remember, you would open an ssh 
> session with X11 forwarding like so:
>
> ssh -X -C foo_user@foo_machine
>
> 3) The .Xauthority file is created on your remote host.  I always thought 
> that the .Xauthority file was created on your Cygwin host, but I was wrong. 
>  Thus, there are no problems with the .Xauthority file being stored in the 
> wrong place in your Cygwin file system, as we have sometimes thought.
All of this information is in the ssh man page:

X11 and TCP forwarding

  If the ForwardX11 variable is set to ``yes'' (or, see the description of
  the -X and -x options described later) and the user is using X11 (the
  DISPLAY environment variable is set), the connection to the X11 display
  is automatically forwarded to the remote side in such a way that any X11
  programs started from the shell (or command) will go through the
  encrypted channel, and the connection to the real X server will be made
  from the local machine.  The user should not manually set DISPLAY.  For-
  warding of X11 connections can be configured on the command line or in
  configuration files.

  The DISPLAY value set by ssh will point to the server machine, but with a
  display number greater than zero.  This is normal, and happens because
  ssh creates a ``proxy'' X server on the server machine for forwarding the
  connections over the encrypted channel.

  ssh will also automatically set up Xauthority data on the server machine.
  For this purpose, it will generate a random authorization cookie, store
  it in Xauthority on the server, and verify that any forwarded connections
  carry this cookie and replace it by the real cookie when the connection
  is opened.  The real authentication cookie is never sent to the server
  machine (and no cookies are sent in the plain).

Admittedly, it's not altogether very clear.  And they're using the term 
"server" in a confusing way.  Personally I think they should use "remote 
machine" or "far-end machine" instead of "server machine", since "server" 
has a particular connotation when talking about X11.

> 4) The instructions in the Cygwin/XFree86 User's Guide for ssh tunnelling 
> work because you launch ssh from within an xterm, which has the DISPLAY 
> variable set correctly already.
>
> 5) When ssh launches with the ``-X'' paramter (for X11 tunnelling) on 
> Cygwin, it looks for the DISPLAY environment variable.  If DISPLAY is not 
> defined, ssh assumes that you do not really want X11 tunnelling and it 
> fails to set the DISPLAY environment variable on the remote host (which is 
> the key step).
>
> 6) You cannot set the DISPLAY environment variable by hand on the remote 
> host after connecting with ssh when the DISPLAY variable was not set on the 
> Cygwin host when you launched.  You might have seen DISPLAY=localhost:10.0 
> in one of your previous sessions on your remote host and thought that you 
> could just set the DISPLAY variable to that again, but you can't.  It 
> appears that ssh just disables the X11 tunnelling (silent failure, the 
> worst kind) when the DISPLAY variable is not defined on your Cygwin host.
>
>
> What to Fix
> ===========
>
> ssh should assume ``DISPLAY=127.0.0.1:0.0'' when the DISPLAY variable is 
> not set on the Cygwin host.  I am not sure why this is not currently the 
> case.  I can only guess that the lack of this assumption is either do to 1) 
> a whiny security geek on the openssh project, or 2) that the assumed usage 
> scenario for openssh is more like a Linux/X machine where you have probably 
> got your X Server running when you connect to your remote machine with ssh, 
> thus DISPLAY would already be set.
>
> At the very least, we should patch the Cygwin release of openssh to assume 
> that DISPLAY=127.0.0.1:0.0 when DISPLAY is not defined in the environment.  
> That would make X11 tunnelling much much easier for 95% of our users and I 
> either can't see or I don't care about any pseduo-security hole that this 
> might open up.  (Hey, if SSH Secure Shell makes this assumption, then we 
> can too.)
I don't agree with this fix.  I think the correct fix should be to make ssh 
die if the -X flag is specified  but the DISPLAY variable is not set 
(instead of quietly continuing on in a somewhat broken state).  A simple 
error message like the following should be sufficient: "Error: In order to 
enable X11 forwarding the DISPLAY variable must be set".

I know you want to make ssh behave correctly for the masses, but you don't 
want to make it behave incorrectly for advanced users trying to debug their 
code.  For instance, I may have 3 different screens running on my local box 
(:0, :1, and :2) and want to set up an ssh channel between screen :2 and a 
remote machine.  If I screw up the way I assign a value to DISPLAY, I don't 
want ssh to keep going and forward my X traffic to the wrong display!


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com