Problem with ssh remote port forwarding and X connection

[Hillel Lubman]

I'm trying to remote forward X connection through several servers (ssh -X doesn't work in such scenario). In simplest case (when A is OpenSolaris desktop, and window from B should appear on A) it would involve to do from server A:

A$ ssh -R6000:localhost:6000 B
(This would mean that ssh will forward connections to port 6000 from B to A).

On A, DISPLAY appears to be :0.0 however exporting such DISPLAY on B, and running there for example xterm doesn't help. After some timeout It produces:
setsockopt TCP_NODELAY: Invalid argument

What can be causing it?

[Alan Coopersmith]

Post by Hillel Lubman
A$ ssh -R6000:localhost:6000 B
(This would mean that ssh will forward connections to port 6000 from B to A).
setsockopt TCP_NODELAY: Invalid argument
What can be causing it?

Does adding the -v flag to ssh provide any additional information?

[Darren Kenny]

Have you specifically enabled port forwarding in the ssh daemon on the server?

You need to edit /etc/ssh/sshd_config and ensure you have a line:

AllowTcpForwarding yes

I'm not 100% sure, but you *may* also need to enable GatewayPorts, but I've not
had to enable it thus far for any use-case I've had.

X11 Forwarding is enabled by default, but that's limited to the -X option, using
the -R and -L options require you to have the above enabled.

Once you've made the edit restart the ssh daemon:

svcadm restart ssh

HTH,

Darren.

Post by Alan Coopersmith

Post by Hillel Lubman
A$ ssh -R6000:localhost:6000 B
(This would mean that ssh will forward connections to port 6000 from B to A).
setsockopt TCP_NODELAY: Invalid argument
What can be causing it?

Does adding the -v flag to ssh provide any additional information?

[Hillel Lubman]

Post by Darren Kenny
Have you specifically enabled port forwarding in the ssh daemon on the server?
AllowTcpForwarding yes
I'm not 100% sure, but you *may* also need to enable GatewayPorts, but I've not
had to enable it thus far for any use-case I've had.
X11 Forwarding is enabled by default, but that's limited to the -X option, using
the -R and -L options require you to have the above enabled.
svcadm restart ssh
HTH,
Darren.

Thanks, I put AllowTcpForwarding yes to /etc/ssh/sshd_config (as well as
tried GatewayPorts yes), but it didn't change the behavior. (Actually
it's stated in sshd_conf that port forwarding is enabled by default).
May be it's some DISPLAY related misconfiguration (I tried ':0.0',
'localhost:0.0')? The application is running, but the window doesn't
appear on the desktop (unlike the case when DISPLAY in not set, in such
case it says: xterm Xt error: Can't open display:

Here is an output from ssh with -v:

While connecting:

debug1: Remote connections from LOCALHOST:6000 forwarded to local
address localhost:6000
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: remote forward success for: listen 6000, connect localhost:6000
debug1: ssh_session2_setup: id 0
debug1: channel request 0: env
debug1: channel request 0: env
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768

After running xterm

debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 6000,
originator 127.0.0.1 port 41516
debug1: fd 9 setting TCP_NODELAY
setsockopt TCP_NODELAY: Invalid argument
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip

It's running, but doesn't appear.

Regards,

Hillel.

[Darren Kenny]

Hi Hillel,

I had success changing the -R for -L, to read:

ssh -N -L6001:localhost:6001 remotehost

This binds localhost 6001, to "localhost 6001" on the remote machine.

But on the remote machine you have to first be sure to specify "xhost
+localhost" or X won't allow connections withtout the correct Xauthority file
information.

So doing this I could do :

DISPLAY=localhost:1 xterm &

and an xterm came up on the remote machine...

I used 6001 (display :1) because I'm already using display :0 (port 6000) to run
all this, and the remote session was a VNC session I had running.

But the idea is the same...

HTH,

Darren.

Post by Hillel Lubman

Post by Darren Kenny
Have you specifically enabled port forwarding in the ssh daemon on the server?
AllowTcpForwarding yes
I'm not 100% sure, but you *may* also need to enable GatewayPorts, but I've not
had to enable it thus far for any use-case I've had.
X11 Forwarding is enabled by default, but that's limited to the -X option, using
the -R and -L options require you to have the above enabled.
svcadm restart ssh
HTH,
Darren.

Thanks, I put AllowTcpForwarding yes to /etc/ssh/sshd_config (as well as
tried GatewayPorts yes), but it didn't change the behavior. (Actually
it's stated in sshd_conf that port forwarding is enabled by default).
May be it's some DISPLAY related misconfiguration (I tried ':0.0',
'localhost:0.0')? The application is running, but the window doesn't
appear on the desktop (unlike the case when DISPLAY in not set, in such
debug1: Remote connections from LOCALHOST:6000 forwarded to local
address localhost:6000
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: remote forward success for: listen 6000, connect localhost:6000
debug1: ssh_session2_setup: id 0
debug1: channel request 0: env
debug1: channel request 0: env
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
After running xterm
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 6000,
originator 127.0.0.1 port 41516
debug1: fd 9 setting TCP_NODELAY
setsockopt TCP_NODELAY: Invalid argument
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
It's running, but doesn't appear.
Regards,
Hillel.

[Hillel Lubman]

Post by Alan Coopersmith

Post by Hillel Lubman
A$ ssh -R6000:localhost:6000 B
(This would mean that ssh will forward connections to port 6000 from B to A).
setsockopt TCP_NODELAY: Invalid argument
What can be causing it?

Does adding the -v flag to ssh provide any additional information?

with -v ssh it outputs (for running xterm&)

debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 6000,
originator 127.0.0.1 port 41503
debug1: fd 9 setting TCP_NODELAY
setsockopt TCP_NODELAY: Invalid argument
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip

After that xterm is still running, but the windows doesn't appear.

Regards,

Hillel.

[Ken Krauter]

Has this problem ever been solved? I have knocked my head against the wall
on this for several weeks. For me, it started after upgrading past snv_128 (now
running snv_134).

I can isolate the problem to running vncserver -localhost. If I leave off
the localhost flag no problems. I have also tried to track down what
my system is calling "localhost" and it appears related to using IPv6 rather
than IPv4 localhost addressing (i.e. ::0 vs 127.0.0.1 for example). The characteristic
is that ssh -vvv shows connection is fine but no output. I have a sense it is somehow
keyed to the way hosts.allow is set up (i.e. tcp_wrappers) but I tried every
permutation of ALL:ALL I could think of there and no difference. Again, this
is all "new" to these updates. Used to work perfectly. It is important also
to note that nearly all free vncviewers do not support IPv6 localhost defs
though I have tried tightVNC, turboVNC, Vine Viewer (commercial) anyhow. Also only
accessing the Opensolaris host from a Mac - maybe that is the problem?

I really need the localhost flag to work to assure security and also would love it
to work via XDMCP (i.e. xvnc-inetd + gdm that used to be great!).