I will try this.
I found the debig/verbose switch on SSH and I get the following when I try
connecting through the tunnel. Note that it is the same result whether I use
the standard vnc from ATT with manual setting of the SSH port forwarding or
the VNC tight encoder with automatic ssh port forwarding (using the -tunnel
switch):
NOTE: I just replaced my IP with remotehost or localhost as appropriate.
[root@localhost]# ssh -C -g -v -L 5810:remotehost:5902 remotehost
SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: Seeding random number generator
debug: ssh_connect: getuid 0 geteuid 0 anon 0
debug: Connecting to localhost [remotehost] port 22.
debug: Allocated local port 1023.
debug: Connection established.
debug: Remote protocol version 1.99, remote software version OpenSSH_2.1.1
Enabling compatibility mode for protocol 2.0
debug: Local version string SSH-2.0-OpenSSH_2.2.0p1debug: Seeding random number
generator
debug: send KEXINIT
debug: done
debug: wait KEXINIT
debug: got kexinit: diffie-hellman-group1-sha1
debug: got kexinit: ssh-dss
debug: got kexinit: 3des-cbc,blowfish-cbc,arcfour,cast128-cbc
debug: got kexinit: 3des-cbc,blowfish-cbc,arcfour,cast128-cbc
debug: got kexinit: hmac-sha1,hmac-md5,[EMAIL PROTECTED]
debug: got kexinit: hmac-sha1,hmac-md5,[EMAIL PROTECTED]
debug: got kexinit: zlib,nonedebug: first kex follow: 0
debug: reserved: 0
debug: done
debug: kex: server->client 3des-cbc hmac-sha1 zlib
debug: kex: client->server 3des-cbc hmac-sha1 zlib
debug: Sending SSH2_MSG_KEXDH_INIT.
debug: bits set: 500/1024
debug: Wait SSH2_MSG_KEXDH_REPLY.
debug: Got SSH2_MSG_KEXDH_REPLY.
debug: Host 'remotehost' is known and matches the DSA host key.
debug: bits set: 512/1024
debug: len 55 datafellows 0
debug: dsa_verify: signature correct
debug: Wait SSH2_MSG_NEWKEYS.
debug: Enabling compression at level 6.
debug: GOT SSH2_MSG_NEWKEYS.
debug: send SSH2_MSG_NEWKEYS.
debug: done: send SSH2_MSG_NEWKEYS.
debug: done: KEX2.
debug: send SSH2_MSG_SERVICE_REQUEST
debug: service_accept: ssh-userauth
debug: got SSH2_MSG_SERVICE_ACCEPT
debug: authentications that can continue: publickey,password
debug: key does not exist: /root/.ssh/id_dsa
root@localhost's password:
debug: ssh-userauth2 successfull
debug: Connections to local port 5810 forwarded to remote address remotehost: 5902
debug: Local forwarding listening on 0.0.0.0 port 5810.
debug: fd 7 setting O_NONBLOCK
debug: channel 0: new [port listener]
debug: no set_nonblock for tty fd 4
debug: no set_nonblock for tty fd 5
debug: no set_nonblock for tty fd 6
debug: channel 1: new [client-session]
debug: send channel open 1
debug: Entering interactive session.
debug: callback start
debug: Requesting X11 forwarding with authentication spoofing.
debug: channel request 1: shell
debug: client_set_session_ident: id 1
debug: callback done
debug: channel 1: open confirm rwindow 0 rmax 32768
debug: channel 1: rcvd adjust 16384
Last login: Wed Dec 20 10:02:30 2000 from localhost
This is the Linux Server
Managed by
Serge Dutremble
[root@linux /root]# exitdebug: Connection to port 5810 forwarding to remotehost port
5902 requested.
debug: fd 8 setting O_NONBLOCK
debug: channel 2: new [listen port 5810 for remotehost port 5902, connect from
localhost port 1248] channel_open_failure: 2: reason 1: bla bla
debug: channel_free: channel 2: status: The
following connections are open:
#1 client-session (t4 r0 i1/0 o16/0 fd 4/5)
#2 listen port 5810 for remotehost port 5902, connect from localhost
port 1248 (t3 r-1 i1/0 o16/0 fd 8/8)
Maybe someone can figure out something from it. As for myself, it seems that
the references to localhost and remotehost (yes I replaced them appropriately)
is strange in some cases.
Serge.
On Wed, 20 Dec 2000, you wrote: > Two thoughts: > > 1. If you are run
VNC Server on the same host as SSHD (which it appears you > are), you have to
enable "Loopback" connections with VNC. Because of the > SSH tunnel, the VNC
server sees that the connection is coming from the SSHD > server. If they're
the same host, it is a loopback connection. > > 2. If you are planning on
using the Java viewer, you have to run VNC on the > remote server on the same
port you want to use for the redirection. > For example:
> You run VNC Server on port 5920 (so HTTP server runs on port 5820). You
> make your ssh connection with "ssh -L 5920:remote_ip:5920 remote_ip" and
> then connection to http://localhost:5820/.
> The reasoning behind this is: the HTTP server that serves up the Java applet
> "knows" that VNC Server is running on a port 100 more than itself (5820 +
> 100 = 5920). If you are proxying the HTTP port as something like 5825, the
> server still sees that it is running on port 5820 even though the client
> sees it as running on port 5825. The client is expecting (because you
> proxied it that way with SSH) the VNC Server to be running on port 5925, but
> the Java applet will be redirected to port 5920 because that's what the HTTP
> server "knows" VNC to be running on. Since you haven't proxied port 5920,
> but 5925, it will not work.
>
> I know that's a weird concept to explain. If it doesn't make sense, let me
> know.
>
> Mike Erdely
> mailto:[EMAIL PROTECTED]
> http://mike.erdelynet.com/
>
> ----- Original Message -----
> From: "Serge Dutremble" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 18, 2000 1:22 PM
> Subject: VNC and SSH
>
>
> > I have been attempting to use VNC through SSH for a few weeks with no
> results.
> >
> > Some responses from the list have suggested I should redirect both the
> 58XX and
> > 59XX ports in order to get it to work but I get the same result. The
> > instructions in the VNC documentation do not suggest it may be necessary
> at all
> > anyway. I think I have to redirect port 59XX is I use the vnc viewer and
> port
> > 58XX if I want to use the http java viewer. I am not attemting to use
> both at
> > this time but would just like to get at least one going.
> >
> > I try the following on a Linux RH 7.0 workstation:
> >
> > ssh -L 5910:remote_ip:5901 remote_ip
> > I get validated by remote_ip (a Mandrake 6.2 workstation)
> >
> > Then I try on another terminal window:
> > vncviewer localhost:10
> >
> > I get a "vncviewer: VNC server closed connection" message locally while I
> get a
> > "channel_open_failure: 2: reason 1: bla bla" message on remote_ip.
> >
> > The command vncviewer remote_ip:1 works fine (but naturrally not
> encrypted).
> >
> > Doesn't make much sense to me.
> >
> > Can anyone help?
> >
> > Serge.
> > ---------------------------------------------------------------------
> > To unsubscribe, send a message with the line: unsubscribe vnc-list
> > to [EMAIL PROTECTED]
> > See also: http://www.uk.research.att.com/vnc/intouch.html
> > ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, send a message with the line: unsubscribe vnc-list
> to [EMAIL PROTECTED]
> See also: http://www.uk.research.att.com/vnc/intouch.html
> ---------------------------------------------------------------------
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New! Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
