Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> ssh -X username@hostname, ssh x11 forwarding issuse
rssmrk
 Posted: Jun 8 2016, 08:58 AM
Quote Post


SLF Newbie


Group: Members
Posts: 5
Member No.: 3709
Joined: 8-June 16









Hi All,

While accessing my remote machine i encountered the following.....


*WARNING* X Window Display Initialization failure
*WARNING* (DISPLAY "localhost:11.0")


Please help me out........
PM
^
inittux
 Posted: Jun 8 2016, 09:06 AM
Quote Post


SLF Geek
****

Group: Members
Posts: 307
Member No.: 953
Joined: 20-October 11









QUOTE (rssmrk @ Jun 8 2016, 09:58 AM)
Hi All,

While accessing my remote machine  i encountered the following.....


*WARNING* X Window Display Initialization failure
*WARNING* (DISPLAY "localhost:11.0")


Please help me out........



try to run this in the terminal

CODE

export DISPLAY=:0.0


Then try again

--------------------
PM
^
rssmrk
 Posted: Jun 8 2016, 09:12 AM
Quote Post


SLF Newbie


Group: Members
Posts: 5
Member No.: 3709
Joined: 8-June 16









Thanks a lot for your reply......

But the problem remains the same......





QUOTE (inittux @ Jun 8 2016, 02:06 PM)
QUOTE (rssmrk @ Jun 8 2016, 09:58 AM)
Hi All,

While accessing my remote machine  i encountered the following.....


*WARNING* X Window Display Initialization failure
*WARNING* (DISPLAY "localhost:11.0")


Please help me out........



try to run this in the terminal

CODE

export DISPLAY=:0.0


Then try again

PM
^
helikaon
 Posted: Jun 8 2016, 10:44 AM
Quote Post


SLF Administrator
*******

Group: Admins
Posts: 836
Member No.: 4
Joined: 8-April 11










hi,
have a look at:
CODE

/etc/ssh/sshd_config


on the server you're trying to log onto and make sure inside the file you have:
CODE

X11Forwarding yes


then reload/restart sshd daemon

cheers

--------------------
PMEmail Poster
^
rssmrk
 Posted: Jun 8 2016, 11:27 AM
Quote Post


SLF Newbie


Group: Members
Posts: 5
Member No.: 3709
Joined: 8-June 16









Thanks a lot for your reply......

I have done the following modifications in /etc/ssh/sshd_config

X11Forwarding yes
X11DisplayOffset 10


&

modifications in /etc/ssh/ssh_config

ForwardX11 yes
ForwardX11Trusted yes

but STILL have the issues....
PM
^
helikaon
 Posted: Jun 8 2016, 01:26 PM
Quote Post


SLF Administrator
*******

Group: Admins
Posts: 836
Member No.: 4
Joined: 8-April 11









QUOTE (rssmrk @ Jun 8 2016, 11:27 AM)
Thanks a lot for your reply......

I have done the following modifications in /etc/ssh/sshd_config

X11Forwarding yes
X11DisplayOffset 10


&

modifications in /etc/ssh/ssh_config

ForwardX11 yes
ForwardX11Trusted yes

but STILL have the issues....


did you also restarted the sshd damon, so it ca re-read the config?
CODE

service sshd restart


cheers

--------------------
PMEmail Poster
^
rssmrk
 Posted: Jun 9 2016, 09:54 AM
Quote Post


SLF Newbie


Group: Members
Posts: 5
Member No.: 3709
Joined: 8-June 16









Still the problem remains the same......

Please Help me OUT.............................. http://www.madjacksports.com/forum/images/smilies/facepalm.gif
PM
^
bluoreo
 Posted: Jun 13 2016, 06:59 AM
Quote Post


SLF Newbie


Group: Members
Posts: 4
Member No.: 3713
Joined: 13-June 16









Hi All,

I have a kind-of same problem related to ssh and X environment.

Just a brief explanation of the situation and the test I have made:

Accessing to the linux server from another linux box via ssh -X:
able to start correctly xclock which is forwarded
UNABLE to start firefox, program hangs (no graphics displayed)

Accessing to the linux server from a Windows machine with Xming installed and via Putty with X11 option enabled:
able to start correctly xclock which is forwarded
ABLE to start firefox, program displays correctly

I have tried several things like invoking forefox with --no-remote, trying other options on the sshd_config nothing has worked so far.

I look forward to your help. Thanks in advance.
PM
^
rssmrk
 Posted: Jun 15 2016, 10:44 AM
Quote Post


SLF Newbie


Group: Members
Posts: 5
Member No.: 3709
Joined: 8-June 16









Please help me out.............
PM
^
bluoreo
 Posted: Jun 15 2016, 03:19 PM
Quote Post


SLF Newbie


Group: Members
Posts: 4
Member No.: 3713
Joined: 13-June 16









Same here....anyone has more info on the topic?

thanks in advance
PM
^
helikaon
 Posted: Jun 16 2016, 12:37 PM
Quote Post


SLF Administrator
*******

Group: Admins
Posts: 836
Member No.: 4
Joined: 8-April 11










hi guys,
please recheck
CODE

/etc/ssh/sshd_config
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes


Only thing needed is the 'X11Forwarding yes' all other is default (on the side of the server), not needed to setup anything else on ssh_config either (all defaults).
and try
CODE

ssh -YX user@machine

from man sshd_config
[code]

    X11DisplayOffset
            Specifies the first display number available for sshd(8)’s X11 forwarding.  This prevents sshd from interfering with real X11 servers.  The default
            is 10.

    X11Forwarding
            Specifies whether X11 forwarding is permitted.  The argument must be “yes” or “no”.  The default is “no”.

            When X11 forwarding is enabled, there may be additional exposure to the server and to client displays if the sshd(8) proxy display is configured to
            listen on the wildcard address (see X11UseLocalhost below), though this is not the default.  Additionally, the authentication spoofing and authen-
            tication data verification and substitution occur on the client side.  The security risk of using X11 forwarding is that the client’s X11 display
            server may be exposed to attack when the SSH client requests forwarding (see the warnings for ForwardX11 in ssh_config(5)).  A system administrator
            may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can
            warrant a “no” setting.

            Note that disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.  X11 for-
            warding is automatically disabled if UseLogin is enabled.

    X11UseLocalhost
            Specifies whether sshd(8) should bind the X11 forwarding server to the loopback address or to the wildcard address.  By default, sshd binds the
            forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to “localhost”.  This prevents remote
            hosts from connecting to the proxy display.  However, some older X11 clients may not function with this configuration.  X11UseLocalhost may be set
            to “no” to specify that the forwarding server should be bound to the wildcard address.  The argument must be “yes” or “no”.  The default is “yes”.


@rsmrk:
your problem could be also IPTABLES (firewall)... your iptables should not block icmp and also accept loopback traffic
eg.
CODE

iptables -I INPUT -i lo -j ACCEPT
iptables -I INPUT -p icmp -j ACCEPT


@bluoreo not sure what the problem with firefox can be - the 'firefox --no-remote' should work quite fine ... isn't your connection too slow?

cheers,

--------------------
PMEmail Poster
^
bluoreo
 Posted: Jun 20 2016, 04:40 PM
Quote Post


SLF Newbie


Group: Members
Posts: 4
Member No.: 3713
Joined: 13-June 16









Hi,

thanks for reply.

No I think I have enough bandwidth, I am able to open firefox (older version than the one I am running on the server I am interested to work on) via ssh on other machines.

This is what I get when I issue the command and I have enabled the verbose mode in ssh so this is what happens...

CODE

[root@Collaboration ~]# firefox --no-remote
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 58822
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 58823
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 58825
debug1: channel 3: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 6 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 58826
debug1: channel 4: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 58827
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6



and the session is just hanging.... the sshd_config has the setting you mention.

Any other ideas what might be wrong?
Thanks in advance
PM
^
helikaon
 Posted: Jun 22 2016, 09:14 AM
Quote Post


SLF Administrator
*******

Group: Admins
Posts: 836
Member No.: 4
Joined: 8-April 11










Hi,
hmm, not sure what to do next, excetp to try to run ssh command with increased verbosity, like

ssh -Xvvv

and see what it display ... and try to google some info

i'm out of ideas atm, ehh

cheers

--------------------
PMEmail Poster
^
bluoreo
 Posted: Jun 23 2016, 06:53 AM
Quote Post


SLF Newbie


Group: Members
Posts: 4
Member No.: 3713
Joined: 13-June 16









Hi helikaon,
thanks for your reply and tips. Here is what I see at login (at least I copied the relevant part concerning the X environment, I believe) of ssh with -Xvvv enabled
CODE

debug2: x11_get_proto: /usr/bin/xauth  list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env XDG_VTNR
debug3: Ignored env MANPATH
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env IDL_LMGRD_LICENSE_FILE
debug3: Ignored env HOSTNAME
debug3: Ignored env IMSETTINGS_INTEGRATE_DESKTOP
debug3: Ignored env GLADE_PIXMAP_PATH
debug3: Ignored env TERM
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env SHELL
debug3: Ignored env HISTSIZE
debug3: Ignored env NCARG_FONTCAPS
debug3: Ignored env WINDOWID
debug3: Ignored env QTDIR
debug3: Ignored env QTINC
debug3: Ignored env IMSETTINGS_MODULE
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env GLADE_MODULE_PATH
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env USERNAME
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env NCARG_GRAPHCAPS
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env https_ecaccess
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env PWD
debug3: Ignored env NCARG_ROOT
debug1: Sending env XMODIFIERS = @im=none
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env MODULEPATH
debug3: Ignored env NCARG_DATABASE
debug3: Ignored env LOADEDMODULES
debug3: Ignored env KDEDIRS
debug3: Ignored env LM_LICENSE_FILE
debug3: Ignored env GDMSESSION
debug3: Ignored env SSH_ASKPASS
debug3: Ignored env NCARG_LIB
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env NCARG_NCARG
debug3: Ignored env XDG_SEAT
debug3: Ignored env GDL_PATH
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env LOGNAME
debug3: Ignored env CVS_RSH
debug3: Ignored env QTLIB
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env http_ecaccess
debug3: Ignored env MODULESHOME
debug3: Ignored env LESSOPEN
debug3: Ignored env WINDOWPATH
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env DISPLAY
debug3: Ignored env GLADE_CATALOG_PATH
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env GTK_IM_MODULE
debug3: Ignored env XAUTHORITY
debug3: Ignored env COLORTERM
debug3: Ignored env CCACHE_HASHDIR
debug3: Ignored env BASH_FUNC_module()
debug3: Ignored env BASH_FUNC_scl()
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0


and this is what I see when I launch firefox --no-remote

CODE

[root@Collaboration ~]# firefox --no-remote
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 44161
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 44162
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 44163
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 6 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 44164
debug2: fd 10 setting O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 4: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 44165
debug2: fd 11 setting O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug1: channel 5: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug3: receive packet: type 96
debug2: channel 5: rcvd eof
debug2: channel 5: output open -> drain
debug2: channel 5: obuf empty
debug2: channel 5: close_write
debug2: channel 5: output drain -> closed
debug1: channel 5: FORCE input drain
debug2: channel 5: ibuf empty
debug2: channel 5: send eof
debug3: send packet: type 96
debug2: channel 5: input drain -> closed
debug2: channel 5: send close
debug3: send packet: type 97
debug3: channel 5: will not send data after close
debug3: receive packet: type 97
debug2: channel 5: rcvd close
debug3: channel 5: will not send data after close
debug2: channel 5: is dead
debug2: channel 5: garbage collecting
debug1: channel 5: free: x11, nchannels 6
debug3: channel 5: status: The following connections are open:
 #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
 #1 x11 (t4 r3 i0/0 o0/0 fd 7/7 cc -1)
 #2 x11 (t4 r4 i0/0 o0/0 fd 8/8 cc -1)
 #3 x11 (t4 r5 i0/0 o0/0 fd 9/9 cc -1)
 #4 x11 (t4 r6 i0/0 o0/0 fd 10/10 cc -1)
 #5 x11 (t4 r7 i3/0 o3/0 fd 11/11 cc -1)


Do you catch any non-normal/unexpected behaviors?

Many thanks in advance.
PM
^
helikaon
 Posted: Jun 24 2016, 01:27 PM
Quote Post


SLF Administrator
*******

Group: Admins
Posts: 836
Member No.: 4
Joined: 8-April 11









Hi,
as i said, i dont know exact cause for this happening, and because of that, i can't even simulate it on my laptotp/server, so all you can do - try to google out something like:

'ssh x11 forwarding channel 5: is dead'
which reveals eg.
x11 forw. prob.

or eg. 'ssh x11 forwarding channel 5: garbage collecting'

which leads to eg
x11 forw prob

Try out suggested things.

cheers

--------------------
PMEmail Poster
^
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll