Problem with tunneling vnc through ssh (via a gateway) - SSH

This is a discussion on Problem with tunneling vnc through ssh (via a gateway) - SSH ; Hi! I'm trying to tunnel vnc through ssh (via a gateway). For this reason, I connect with ssh -t -X -l -R 5907:localhost:5907 ssh -l -R 5907:localhost:5907 On the , I start the vncserver with "vncserver -localhost", then I run ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Problem with tunneling vnc through ssh (via a gateway)

  1. Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    I'm trying to tunnel vnc through ssh (via a gateway). For
    this reason, I connect with

    ssh -t -X -l -R 5907:localhost:5907 ssh -l
    -R 5907:localhost:5907

    On the , I start the vncserver with "vncserver -localhost",
    then I run "vncviewer localhost", which yields "Error: Can't open display".

    Any clues why it does not work?

    In this spirit
    With thanks for your efforts
    Yours Gernot

  2. Re: Problem with tunneling vnc through ssh (via a gateway)

    >>>>> "GP" == Gernot Pfanner writes:

    GP> Hi! I'm trying to tunnel vnc through ssh (via a gateway). For
    GP> this reason, I connect with

    GP> ssh -t -X -l -R 5907:localhost:5907 ssh -l
    GP> -R 5907:localhost:5907

    GP> On the , I start the vncserver with "vncserver
    GP> -localhost", then I run "vncviewer localhost", which yields
    GP> "Error: Can't open display".

    GP> Any clues why it does not work?

    You have it backwards; with your setup, the server would be on the first
    host, and the client on the .

    --
    Richard Silverman
    res@qoxp.net


  3. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    >
    > You have it backwards; with your setup, the server would be on the first
    > host, and the client on the .


    Do you mean, I have to run it this way "ssh ... ssh ...
    "? This results in "ssh_exchange_identification: Connection
    closed by remote host" because the was set up by the
    administrator, so that one just can connect through the gateway. Is there
    a way around or would it be of help, if I change the "direction" of vnc,
    i.e. invoke it locally?
    In this spirit
    With thanks
    Yours Gernot

  4. Re: Problem with tunneling vnc through ssh (via a gateway)

    I believe the problem is you're using -R instead of -L so the first
    tunnel, for example, listens on port 5907 of , and sends that
    to localhost (as your computer sees it, hence, your computer). So the
    tunnels are all working backwards, because they're remote tunnels,
    instead of local.

    I would try:
    ssh -t -X -l -L 5907:localhost:5907 ssh -l
    -L 5907:localhost:5907

    Also, VNC server should be listening on port 5907, which is the default
    only if you are using display number 7, and I believe you shouldn't
    need neither -X nor -t to accomplish a VNC connection (not that they
    are impediments, but perhaps unnecesary).

    If will accept connections from you could also
    try:
    ssh -t -X -l -L 5907:localhost:5907
    it is simpler but it excludes the possibility of configuring VNC to
    only accept connections from localhost, which adds some security.

    And last but not least, when doing this kind of thing, I have found
    that adding a -C (compression) enhances performance a lot. But I guess
    that depends on the processors'
    speeds vs network speed...

    Hope it helps.
    Regards:

    Wences


    Gernot Pfanner wrote:
    > Hi!
    >
    > >
    > > You have it backwards; with your setup, the server would be on the first
    > > host, and the client on the .

    >
    > Do you mean, I have to run it this way "ssh ... ssh ...
    > "? This results in "ssh_exchange_identification: Connection
    > closed by remote host" because the was set up by the
    > administrator, so that one just can connect through the gateway. Is there
    > a way around or would it be of help, if I change the "direction" of vnc,
    > i.e. invoke it locally?
    > In this spirit
    > With thanks
    > Yours Gernot



  5. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    >
    > I would try:
    > ssh -t -X -l -L 5907:localhost:5907 ssh -l
    > -L 5907:localhost:5907


    Thanks, but that does not work either. Taking back a step, how do I
    establish an ordinary ssh-session (with X-Forwarding) through a gateway? I
    have tried

    ssh -v -t -X -l ssh -v -X -l

    but this results in "Error: Can't open display:" too. The display-variable
    is not set (as checked by "echo $DISPLAY"), but setting it to localhost
    (setenv DISPLAY 127.0.0.1) does not change things. The extended
    output messages (as turned on by the -v flag) just contain the connection
    details and almost no error. ssh just complains that "The authenticity of
    host '' can't be establis hed" and connecting
    anyway..."Failed to add the host to the list of known hosts". But
    thats all.
    In this spirit
    With thanks
    Yours Gernot

  6. Re: Problem with tunneling vnc through ssh (via a gateway)

    >>>>> "GP" == Gernot Pfanner writes:

    GP> Hi!
    >> I would try: ssh -t -X -l -L 5907:localhost:5907
    >> ssh -l -L 5907:localhost:5907


    GP> Thanks, but that does not work either. Taking back a step, how do
    GP> I establish an ordinary ssh-session (with X-Forwarding) through a
    GP> gateway? I have tried

    GP> ssh -v -t -X -l ssh -v -X -l
    GP>

    GP> but this results in "Error: Can't open display:" too. The
    GP> display-variable is not set (as checked by "echo $DISPLAY"), but
    GP> setting it to localhost (setenv DISPLAY 127.0.0.1) does not change
    GP> things. The extended output messages (as turned on by the -v flag)
    GP> just contain the connection details and almost no error. ssh just
    GP> complains that "The authenticity of host '' can't be
    GP> establis hed" and connecting anyway..."Failed to add the host to
    GP> the list of known hosts". But thats all. In this spirit With
    GP> thanks Yours Gernot

    1) Make sure X is working locally.

    2) Post -vv output.

    3) Try this instead, assuming the gateway has netcat (nc) on it:

    ssh -oproxycommand="ssh -qax username@gateway nc %h %p" -X username@host

    --
    Richard Silverman
    res@qoxp.net


  7. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!


    Firstly, please apologize my reply-delays, but at the moment I do not have
    the possibility to sit at the computer "all day long". Sorry & I DO
    appreciate your help/suggestions

    >
    > 3) Try this instead, assuming the gateway has netcat (nc) on it:
    >
    > ssh -oproxycommand="ssh -qax username@gateway nc %h %p" -X username@host


    This results in

    Could not chdir to home directory /hosts//home/: No such
    file or direc tory
    nc: Command not found
    ssh_exchange_identification: Connection closed by remote host

    >
    > 2) Post -vv output.


    Okay, here the messages for "ssh -vv -t -X -l ssh -vv
    -X -l "...

    OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to [] port 22.
    debug1: Connection established.
    debug1: identity file /home//.ssh/identity type -1
    debug1: identity file /home//.ssh/id_rsa type -1
    debug1: identity file /home//.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
    debug1: match: OpenSSH_3.9p1 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
    up1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
    up14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 124/256
    debug2: bits set: 505/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host '' is known and matches the RSA host key.
    debug1: Found key in /home//.ssh/known_hosts:4
    debug2: bits set: 531/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home//.ssh/identity ((nil))
    debug2: key: /home//.ssh/id_rsa ((nil))
    debug2: key: /home//.ssh/id_dsa ((nil))
    debug1: Authentications that can continue: publickey,password
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home//.ssh/identity
    debug1: Trying private key: /home//.ssh/id_rsa
    debug1: Trying private key: /home//.ssh/id_dsa
    debug2: we did not send a packet, disable method
    debug1: Next authentication method: password
    @'s password:
    debug2: we sent a password packet, wait for reply
    debug1: Authentication succeeded (password).
    debug1: channel 0: new [client-session]
    debug2: channel 0: send open
    debug1: Entering interactive session.
    debug2: callback start
    debug2: ssh_session2_setup: id 0
    debug2: channel 0: request pty-req
    debug2: x11_get_proto: /usr/bin/X11/xauth list :0.0 . 2>/dev/null
    debug1: Requesting X11 forwarding with authentication spoofing.
    debug2: channel 0: request x11-req
    debug1: Sending command: ssh -vv -X -l
    debug2: channel 0: request exec
    debug2: fd 3 setting TCP_NODELAY
    debug2: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    Could not chdir to home directory /hosts//home/: No such file or direc
    tory
    OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to [] port 22.
    debug1: Connection established.
    Could not create directory '/hosts//home//.ssh'.
    debug1: identity file /hosts//home//.ssh/identity type -1
    debug1: identity file /hosts//home//.ssh/id_rsa type -1
    debug1: identity file /hosts//home//.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
    debug1: match: OpenSSH_3.9p1 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.9p1
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
    up14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
    up14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 140/256
    debug2: bits set: 508/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug2: no key of type 0 for host
    debug2: no key of type 2 for host
    The authenticity of host ' ()' can't be establis
    hed.
    RSA key fingerprint is dc:03:8a:90:14:6f:60:f7:db:32:07:60:2c:1a:3f:10.
    Are you sure you want to continue connecting (yes/no)? yes
    Failed to add the host to the list of known hosts (/hosts//home//.ssh/
    known_hosts).
    debug2: bits set: 530/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /hosts//home//.ssh/identity ((nil))
    debug2: key: /hosts//home//.ssh/id_rsa ((nil))
    debug2: key: /hosts//home//.ssh/id_dsa ((nil))
    debug1: Authentications that can continue: publickey,password
    debug1: Next authentication method: publickey
    debug1: Trying private key: /hosts//home//.ssh/identity
    debug1: Trying private key: /hosts//home//.ssh/id_rsa
    debug1: Trying private key: /hosts//home//.ssh/id_dsa
    debug2: we did not send a packet, disable method
    debug1: Next authentication method: password
    @'s password:
    debug2: we sent a password packet, wait for reply
    debug1: Authentication succeeded (password).
    debug1: channel 0: new [client-session]
    debug2: channel 0: send open
    debug1: Entering interactive session.
    debug2: callback start
    debug2: client_session2_setup: id 0
    debug2: channel 0: request pty-req confirm 0
    debug1: Sending environment.
    debug1: Sending env LANG = de_DE.UTF-8
    debug2: channel 0: request env confirm 0
    debug1: Sending env LC_COLLATE = POSIX
    debug2: channel 0: request env confirm 0
    debug2: channel 0: request shell confirm 0
    debug2: fd 3 setting TCP_NODELAY
    debug2: callback done
    debug2: channel 0: open confirm rwindow 0 rmax 32768
    debug2: channel 0: rcvd adjust 131072
    Have a lot of fun...
    Directory: /hosts//home/
    Have a lot of fun...
    Directory: /hosts//home/
    Di Jul 25 08:51:22 CEST 2006
    home/> firefox
    /usr/bin/firefox: line 136: [: too many arguments

    (firefox-bin:11167): Gtk-WARNING **: cannot open display:
    home/> debug2: client_check_window_change: changed
    debug2: channel 0: request window-change
    debug2: client_check_window_change: changed
    debug2: channel 0: request window-change confirm 0


    In this spirit
    With thanks for your efforts
    Yours Gernot

  8. Re: Problem with tunneling vnc through ssh (via a gateway)


    > > 3) Try this instead, assuming the gateway has netcat (nc) on it:
    > >
    > > ssh -oproxycommand="ssh -qax username@gateway nc %h %p" -X username@host

    >
    > This results in
    >
    > Could not chdir to home directory /hosts//home/: No such
    > file or direc tory


    This is a separate problem; the account's home directory does not exist on
    the gateway. This by itself may cause X forwarding to fail, since xauth
    wants to write to ~/.Xauthority

    > nc: Command not found


    Did you read the part where I wrote, "assuming the gateway has netcat (nc) on it?"

    > > 2) Post -vv output.


    The second ssh connection is not doing X forwarding. Make sure the first
    one is working, first.

    --
    Richard Silverman
    res@qoxp.net


  9. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    >
    > The second ssh connection is not doing X forwarding. Make sure the first
    > one is working, first.


    If you mean, the connection to ...*well* there is nothing I can
    do on that machine. I can not even create a file (no write permissions);
    the same keeps true for starting a simple X-application such as "xclock"
    (which is not installed).
    In this spirit
    With thanks
    Yours Gernot


  10. Re: Problem with tunneling vnc through ssh (via a gateway)

    >>>>> "GP" == Gernot Pfanner writes:

    GP> Hi!
    >> The second ssh connection is not doing X forwarding. Make sure
    >> the first one is working, first.


    GP> If you mean, the connection to ...*well* there is nothing
    GP> I can do on that machine. I can not even create a file (no write
    GP> permissions); the same keeps true for starting a simple
    GP> X-application such as "xclock" (which is not installed). In this
    GP> spirit With thanks Yours Gernot

    Then what you're trying to do probably won't work. You need a direct
    session between the client and end server. If you can't use proxycommand,
    you can forward a port through the gateway and use that.

    --
    Richard Silverman
    res@qoxp.net


  11. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    > you can forward a port through the gateway and use that.


    What is the correct syntax? I have tried

    ssh -t -X -l -L 5103:localhost:5103
    ssh -X -l -L 5103:localhost:5103

    but this yields the same results( i.e. "can't open display").
    In this spirit
    With thanks
    Yours Gernot

  12. Re: Problem with tunneling vnc through ssh (via a gateway)

    >>>>> "GP" == Gernot Pfanner writes:

    GP> Hi!
    >> you can forward a port through the gateway and use that.


    GP> What is the correct syntax? I have tried

    GP> ssh -t -X -l -L 5103:localhost:5103 ssh -X -l
    GP> -L 5103:localhost:5103

    GP> but this yields the same results( i.e. "can't open display").

    $ ssh -L 1234:host:22 gateway
    $ ssh -X -p 1234 localhost

    GP> In this spirit With thanks Yours Gernot

    In what spirit?

    --
    Richard Silverman
    res@qoxp.net


  13. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    >
    > $ ssh -L 1234:host:22 gateway
    > $ ssh -X -p 1234 localhost


    Does not work either :-( New ways, new errors:

    Running it as a user, I get

    debug1: Connecting to localhost [127.0.0.1] port 1234.
    debug1: connect to address 127.0.0.1 port 1234: Connection refused
    debug1: Connecting to localhost [::1] port 1234.
    debug1: connect to address ::1 port 1234: Connection refused
    ssh: connect to host localhost port 1234: Connection refused

    so I switched to root, to forward to port 22. Now the connection to
    localhost is etablished, but it just exists with "Exit status 255". The
    log reads

    debug2: we sent a password packet, wait for reply
    debug1: Authentication succeeded (password).
    debug1: Connections to local port 22 forwarded to remote address :22
    debug1: Local forwarding listening on ::1 port 22.
    debug2: fd 4 setting O_NONBLOCK
    debug2: fd 4 is O_NONBLOCK
    debug1: channel 0: new [port listener]
    debug1: Local forwarding listening on 127.0.0.1 port 22.
    debug2: fd 5 setting O_NONBLOCK
    debug2: fd 5 is O_NONBLOCK
    debug1: channel 1: new [port listener]
    debug1: channel 2: new [client-session]
    debug2: channel 2: send open
    debug1: Entering interactive session.
    debug2: callback start
    debug2: ssh_session2_setup: id 2
    debug1: Sending command: ssh -X -l -vv -p 22 localhost
    debug2: channel 2: request exec
    debug2: callback done
    debug2: channel 2: open confirm rwindow 0 rmax 32768
    debug2: channel 2: rcvd adjust 131072
    debug2: channel 2: rcvd ext data 85
    debug2: channel 2: rcvd ext data 42
    debug2: channel 2: rcvd ext data 72
    debug2: channel 2: rcvd ext data 56
    debug2: channel 2: rcvd ext data 32
    debug2: channel 2: rcvd ext data 33
    debug2: channel 2: rcvd ext data 54
    debug2: channel 2: rcvd ext data 33
    debug2: channel 2: rcvd ext data 60
    debug2: channel 2: rcvd ext data 69
    debug2: channel 2: rcvd ext data 67
    debug2: channel 2: rcvd ext data 67
    debug2: channel 2: rcvd ext data 76
    debug2: channel 2: rcvd ext data 43
    Could not chdir to home directory /hosts//home/: No such file or direc
    tory
    OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
    Pseudo-terminal will not be allocated because stdin is not a terminal.
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to localhost [127.0.0.1] port 22.
    debug1: Connection established.
    Could not create directory '/hosts//home//.ssh'.
    debug1: identity file /hosts//home//.ssh/identity type -1
    debug1: identity file /hosts//home//.ssh/id_rsa type -1
    debug1: identity file /hosts//home//.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
    debug1: match: OpenSSH_3.9p1 pat OpenSSH*
    debug2: channel 2: written 789 to efd 8
    debug2: channel 2: rcvd ext data 54
    debug2: channel 2: rcvd ext data 52
    debug2: channel 2: rcvd ext data 33
    debug2: channel 2: rcvd ext data 31
    debug2: channel 2: rcvd ext data 35
    debug2: channel 2: rcvd ext data 118
    debug2: channel 2: rcvd ext data 44
    debug2: channel 2: rcvd ext data 164
    debug2: channel 2: rcvd ext data 164
    debug2: channel 2: rcvd ext data 114
    debug2: channel 2: rcvd ext data 114
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.9p1
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
    up14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: channel 2: written 923 to efd 8
    debug2: channel 2: rcvd ext data 38
    debug2: channel 2: rcvd ext data 38
    debug2: channel 2: rcvd ext data 29
    debug2: channel 2: rcvd ext data 29
    debug2: channel 2: rcvd ext data 49
    debug2: channel 2: rcvd ext data 40
    debug2: channel 2: rcvd ext data 118
    debug2: channel 2: rcvd ext data 44
    debug2: channel 2: rcvd ext data 164
    debug2: channel 2: rcvd ext data 164
    debug2: channel 2: rcvd ext data 114
    debug2: channel 2: rcvd ext data 114
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro
    up14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
    aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-c
    tr
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
    ssh.com,hmac-sha1-96,hmac-md5-96
    debug2: channel 2: written 941 to efd 8
    debug2: channel 2: rcvd ext data 38
    debug2: channel 2: rcvd ext data 38
    debug2: channel 2: rcvd ext data 29
    debug2: channel 2: rcvd ext data 29
    debug2: channel 2: rcvd ext data 49
    debug2: channel 2: rcvd ext data 40
    debug2: channel 2: rcvd ext data 34
    debug2: channel 2: rcvd ext data 54
    debug2: channel 2: rcvd ext data 34
    debug2: channel 2: rcvd ext data 54
    debug2: channel 2: rcvd ext data 58
    debug2: channel 2: rcvd ext data 45
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: channel 2: written 502 to efd 8
    debug2: channel 2: rcvd ext data 48
    debug2: channel 2: rcvd ext data 28
    debug2: channel 2: rcvd ext data 39
    debug2: channel 2: rcvd ext data 45
    debug2: channel 2: rcvd ext data 45
    debug2: channel 2: rcvd ext data 45
    debug2: channel 2: rcvd ext data 31
    debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
    debug2: channel 2: rcvd eof
    debug2: channel 2: output open -> drain
    debug2: channel 2: rcvd close
    debug2: channel 2: close_read
    debug2: channel 2: input open -> closed
    debug2: channel 2: obuf_empty delayed efd 8/(281)
    debug2: dh_gen_key: priv key bits set: 132/256
    debug2: bits set: 507/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug2: no key of type 0 for host localhost
    debug2: no key of type 2 for host localhost
    Host key verification failed.
    debug2: channel 2: written 281 to efd 8
    debug2: channel 2: obuf empty
    debug2: channel 2: close_write
    debug2: channel 2: output drain -> closed
    debug2: channel 2: almost dead
    debug2: channel 2: gc: notify user
    debug2: channel 2: gc: user detached
    debug2: channel 2: send close
    debug2: channel 2: is dead
    debug2: channel 2: garbage collecting
    debug1: channel 2: free: client-session, nchannels 3
    debug1: channel 0: free: port listener, nchannels 2
    debug1: channel 1: free: port listener, nchannels 1
    debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
    debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
    debug1: Exit status 255


    My ssh_config uses default-configuration, i.e. I have not set
    anything. sshd listens to port 22, though it is not running (should it?).
    In this spirt
    Yours Gernot

    > In what spirit?


    Of finding a solution some day? Anyway, many thanks for your kind help so
    far

  14. Re: Problem with tunneling vnc through ssh (via a gateway)


    > > $ ssh -L 1234:host:22 gateway
    > > $ ssh -X -p 1234 localhost

    >
    > Does not work either :-( New ways, new errors:
    >
    > Running it as a user, I get
    >
    > debug1: Connecting to localhost [127.0.0.1] port 1234.
    > debug1: connect to address 127.0.0.1 port 1234: Connection refused


    Run these two commands on the same host, the first one.

    --
    Richard Silverman
    res@qoxp.net


  15. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    >
    >> > $ ssh -L 1234:host:22 gateway
    >> > $ ssh -X -p 1234 localhost

    >>
    >> Does not work either :-( New ways, new errors:
    >>
    >> Running it as a user, I get
    >>
    >> debug1: Connecting to localhost [127.0.0.1] port 1234.
    >> debug1: connect to address 127.0.0.1 port 1234: Connection refused

    >
    > Run these two commands on the same host, the first one.


    Do you mean, that I should connect to host and then run these commands
    from (i.e. create a second ssh-tunnel in the other direction)? This
    yields

    ssh: connect to host localhost port 1234: Connection refused

    As sad as it is, I think that there is no chance of getting at least X to
    work.
    In this spirit
    With thanks for your help
    Yours Gernot



  16. Re: Problem with tunneling vnc through ssh (via a gateway)

    Hi!

    > E.g. in different windows.


    Just another manic monday...
    Yes, it solved the problem, and (not too surprisingly) also the problem
    with vnc, i.e. I am now able to tunnel vnc through ssh again!
    Many, many thanks for your enduring support!
    In this spirit
    Best wishes
    Yours Gernot

+ Reply to Thread