Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: no display with ssh -X after fresh 11.4_64 install

  1. #1

    Default no display with ssh -X after fresh 11.4_64 install

    Hello,

    I´m using OpenSUSE for years with GIS-Servers. There are many advantages in starting programs on the server with the GUI at my desktop via ssh -X. That method always worked fine until my install of 11.4 64bit on a server (Server1) with a supermicro-board and onboard graphics. Another server (Server2) on desktop hardware with a nvidia graphics card works fine with ssh -X and 11.4. I installed 7 other PC and Servers, 6 are running with X11Forwarding like server2, one additional had the same issue as Server1.

    I used OpenSUSE 10.2 to 11.0 and X11Forwarding always worked fine without any assistence from me! Why not with 11.4????

    I try to solve that issue since 4 weeks now, neither internet sites nor any forum could give the key hint so far.
    If the X11Forwarding-problem is not solvable for any reason - are there any alternatives i could try?
    This one of a handful things the Server must do - maybe this is the end of a 5 year OpenSUSE history....

    QGis error:
    QGIS starting in non-interactive mode not supported.
    You are seeing this message most likely because you have no DISPLAY environment variable set.

    Yast only runs without gui

    pgAdmin3 error:
    Error: Unable to initialize gtk, is DISPLAY set properly?

    echo $DISPLAY shows nothing on server1,
    on server2 echo $DISPLAY shows: localhost:10.0

    I set X11Forwarding to "yes" in /etc/ssh/sshd_config on Server1, but no effect. (On Server2 X11Forwarding is set to "no" in /etc/ssh/sshd_config and X11Forwarding works fine!!)

    Server2:
    andi@luth:~> ssh -v -X ServerX
    OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    ssh: Could not resolve hostname ServerX: Name or service not known

    Server1:
    andi@tuba:~> ssh -v -X ServerX
    OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    ssh: Could not resolve hostname ServerX: Name or service not known


    Many thanks for help Andi

  2. #2
    Join Date
    Jun 2008
    Location
    The English Lake District. UK - GMT/BST
    Posts
    36,729
    Blog Entries
    20

    Default Re: no display with ssh -X after fresh 11.4_64 install

    What about plain ssh?
    Leap 15.1_KDE
    My Articles Was I any help? If yes: Click the star below

  3. #3
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: no display with ssh -X after fresh 11.4_64 install

    On 2011-11-21 11:16, bloediandi wrote:
    > ssh: Could not resolve hostname ServerX: Name or service not known


    Try with IP numbers.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.4 x86_64 "Celadon" at Telcontar)

  4. #4

    Default Re: no display with ssh -X after fresh 11.4_64 install

    Sorry, you´re right, would be better to write the severs IP instead of ServerX.

    Here we are, but the seem to be identically...
    Server1:
    andi@cello:~> ssh -v -X 134.110.37.20
    OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: Connecting to 134.110.37.20 [134.110.37.20] port 22.
    debug1: Connection established.
    debug1: identity file /home/andi/.ssh/id_rsa type -1
    debug1: identity file /home/andi/.ssh/id_rsa-cert type -1
    debug1: identity file /home/andi/.ssh/id_dsa type -1
    debug1: identity file /home/andi/.ssh/id_dsa-cert type -1
    debug1: identity file /home/andi/.ssh/id_ecdsa type -1
    debug1: identity file /home/andi/.ssh/id_ecdsa-cert type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
    debug1: match: OpenSSH_5.8 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.8
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: sending SSH2_MSG_KEX_ECDH_INIT
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ECDSA 15:6a:7f:3a:f9:5d:3e:9f:e3:3e:fb:8e:e5:9c:15:1f
    debug1: Host '134.110.37.20' is known and matches the ECDSA host key.
    debug1: Found key in /home/andi/.ssh/known_hosts:2
    debug1: ssh_ecdsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: Roaming not allowed by server
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/andi/.ssh/id_rsa
    debug1: Trying private key: /home/andi/.ssh/id_dsa
    debug1: Trying private key: /home/andi/.ssh/id_ecdsa
    debug1: Next authentication method: keyboard-interactive
    Password:
    debug1: Authentication succeeded (keyboard-interactive).
    Authenticated to 134.110.37.20 ([134.110.37.20]:22).
    debug1: channel 0: new [client-session]
    debug1: Requesting no-more-sessions@openssh.com
    debug1: Entering interactive session.
    debug1: Requesting X11 forwarding with authentication spoofing.
    debug1: Sending environment.
    debug1: Sending env LANG = de_DE.UTF-8
    Last login: Mon Nov 21 13:27:22 2011 from cello.aoe.fal.de
    Have a lot of fun...


    Server2:
    andi@cello:~> ssh -v -X 134.110.37.23
    OpenSSH_5.8p1, OpenSSL 1.0.0c 2 Dec 2010
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: Connecting to 134.110.37.23 [134.110.37.23] port 22.
    debug1: Connection established.
    debug1: identity file /home/andi/.ssh/id_rsa type -1
    debug1: identity file /home/andi/.ssh/id_rsa-cert type -1
    debug1: identity file /home/andi/.ssh/id_dsa type -1
    debug1: identity file /home/andi/.ssh/id_dsa-cert type -1
    debug1: identity file /home/andi/.ssh/id_ecdsa type -1
    debug1: identity file /home/andi/.ssh/id_ecdsa-cert type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
    debug1: match: OpenSSH_5.8 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.8
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: sending SSH2_MSG_KEX_ECDH_INIT
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ECDSA c2:01:f6:49:62:6d:f5:4c:08:b9:86:6d:71:a0:81:9b
    debug1: Host '134.110.37.23' is known and matches the ECDSA host key.
    debug1: Found key in /home/andi/.ssh/known_hosts:4
    debug1: ssh_ecdsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: Roaming not allowed by server
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/andi/.ssh/id_rsa
    debug1: Trying private key: /home/andi/.ssh/id_dsa
    debug1: Trying private key: /home/andi/.ssh/id_ecdsa
    debug1: Next authentication method: keyboard-interactive
    Password:
    debug1: Authentication succeeded (keyboard-interactive).
    Authenticated to 134.110.37.23 ([134.110.37.23]:22).
    debug1: channel 0: new [client-session]
    debug1: Requesting no-more-sessions@openssh.com
    debug1: Entering interactive session.
    debug1: Requesting X11 forwarding with authentication spoofing.
    debug1: Sending environment.
    debug1: Sending env LANG = de_DE.UTF-8
    Last login: Mon Nov 21 09:48:37 2011 from cello.aoe.fal.de
    Have a lot of fun...

  5. #5

    Default Re: no display with ssh -X after fresh 11.4_64 install

    plain ssh means without -X? I can log in via ssh and work on the remote machine, no problems, only if i want to export the display of a gui....

  6. #6

    Default Re: no display with ssh -X after fresh 11.4_64 install

    My best try so far (first time i get another error!):

    logged in on server1 typing:
    andi@tuba:~> export DISPLAY=134.110.37.183:10

    (183 is the IP from the desktop from where i want to open the gui on server1)

    when i start pgadmin3 or qgis then, "nothing" happens, means: server1 opens the gui (i can see pgadmin in top) without error, but the display not appears on my desktop (183). Perhaps someone knows what export display syntax can help?

    cheers Andi

  7. #7
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,503
    Blog Entries
    3

    Default Re: no display with ssh -X after fresh 11.4_64 install

    Quote Originally Posted by bloediandi View Post
    I set X11Forwarding to "yes" in /etc/ssh/sshd_config on Server1, but no effect. (On Server2 X11Forwarding is set to "no" in /etc/ssh/sshd_config and X11Forwarding works fine!!)
    Changes to sshd_config only take effect after the sshd daemon is restarted on that server. Typically, one uses "kill -HUP pid" to restart.

    After restart, the change affects only new connections. An ssh login that you did before that restart will be going by the old configuration.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  8. #8

    Default Re: no display with ssh -X after fresh 11.4_64 install

    Hi nrickert,

    i restarted ssh with rcsshd restart and opened a new terminal on the client to login - nothing. I even restarted the server after setting X11Forwarding to "yes" - nothing. AND: On many other servers X11Forwarding works with X11Forwarding disabled like this:
    # ForwardX11 no

    It seems to me NOT ssh is the reason for my problems but video driver or something else!?

  9. #9
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,503
    Blog Entries
    3

    Default Re: no display with ssh -X after fresh 11.4_64 install

    Quote Originally Posted by bloediandi View Post
    On many other servers X11Forwarding works with X11Forwarding disabled like this:
    # ForwardX11 no
    No, that's a comment. It neither enables nor disables anything.

    Somewhere in my sshd_config, I have:

    [code]
    #AllowAgentForwarding yes
    #AllowTcpForwarding yes
    #GatewayPorts no
    X11Forwarding yes
    #X11DisplayOffset 10
    #X11UseLocalhost yes
    [code]
    That suggests to me that the X11Forwarding line was changed, probably by the openSUSE team, and that the default in the software itself is to disable forwarding.

    Later in the file, I see:
    Code:
    #       X11Forwarding no
    but that is a comment as part of a longer comment on how to set different configuration for a specific user.

    The documentation also indicates that if "UseLogin" is set to "yes", then X forwarding won't work, regardless of its setting.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  10. #10

    Default Re: no display with ssh -X after fresh 11.4_64 install

    i cannot find how ssh_config should cause the problem, because it the same configuration file on both servers, on these where ssh -X exports the display and on those, where ssh -X doesn´t export the display.

    here my original ssh_config:

    # $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $

    # This is the ssh client system-wide configuration file. See
    # ssh_config(5) for more information. This file provides defaults for
    # users, and the values can be changed in per-user configuration files
    # or on the command line.

    # Configuration data is parsed as follows:
    # 1. command line options
    # 2. user-specific file
    # 3. system-wide file
    # Any configuration value is only changed the first time it is set.
    # Thus, host-specific definitions should be at the beginning of the
    # configuration file, and defaults at the end.

    # Site-wide defaults for some commonly used options. For a comprehensive
    # list of available options, their meanings and defaults, please see the
    # ssh_config(5) man page.

    Host *
    # ForwardAgent no
    # ForwardX11 no

    # If you do not trust your remote host (or its administrator), you
    # should not forward X11 connections to your local X11-display for
    # security reasons: Someone stealing the authentification data on the
    # remote side (the "spoofed" X-server by the remote sshd) can read your
    # keystrokes as you type, just like any other X11 client could do.
    # Set this to "no" here for global effect or in your own ~/.ssh/config
    # file if you want to have the remote X11 authentification data to
    # expire after two minutes after remote login.
    ForwardX11Trusted yes

    # RhostsRSAAuthentication no
    # RSAAuthentication yes
    # PasswordAuthentication yes
    # HostbasedAuthentication no
    # GSSAPIAuthentication no
    # GSSAPIDelegateCredentials no
    # BatchMode no
    # CheckHostIP yes
    # AddressFamily any
    # ConnectTimeout 0
    # StrictHostKeyChecking ask
    # IdentityFile ~/.ssh/identity
    # IdentityFile ~/.ssh/id_rsa
    # IdentityFile ~/.ssh/id_dsa
    # Port 22
    Protocol 2
    # Cipher 3des
    # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
    # MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
    # EscapeChar ~
    # Tunnel no
    # TunnelDevice any:any
    # PermitLocalCommand no
    # GSSAPIAuthentication no
    # GSSAPIDelegateCredentials no

    # Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
    # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
    # in this release. The use of 'gssapi' is deprecated due to the presence of
    # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
    # GSSAPIEnableMITMAttack no

    # This enables sending locale enviroment variables LC_* LANG, see ssh_config(5).
    SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
    SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
    SendEnv LC_IDENTIFICATION LC_ALL

    # This will print the fingerprint of the host key in "visual" form
    # this should make it easier to also recognize bad things
    VisualHostKey no

    # This will hash new host keys and make them so unusable for malicious
    # people or software trying to use known_hosts to find further hops.
    HashKnownHosts yes

    # ProxyCommand ssh -q -W %h:%p gateway.example.com



    And here the one i use now:


    # $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $

    # This is the ssh client system-wide configuration file. See
    # ssh_config(5) for more information. This file provides defaults for
    # users, and the values can be changed in per-user configuration files
    # or on the command line.

    # Configuration data is parsed as follows:
    # 1. command line options
    # 2. user-specific file
    # 3. system-wide file
    # Any configuration value is only changed the first time it is set.
    # Thus, host-specific definitions should be at the beginning of the
    # configuration file, and defaults at the end.

    # Site-wide defaults for some commonly used options. For a comprehensive
    # list of available options, their meanings and defaults, please see the
    # ssh_config(5) man page.

    Host *
    # ForwardAgent no
    ForwardX11 yes
    # X11DisplayOffset 10 (selbst eingefügt aus Forumtipp, hat nicht geholfen)

    # If you do not trust your remote host (or its administrator), you
    # should not forward X11 connections to your local X11-display for
    # security reasons: Someone stealing the authentification data on the
    # remote side (the "spoofed" X-server by the remote sshd) can read your
    # keystrokes as you type, just like any other X11 client could do.
    # Set this to "no" here for global effect or in your own ~/.ssh/config
    # file if you want to have the remote X11 authentification data to
    # expire after two minutes after remote login.
    ForwardX11Trusted yes

    # RhostsRSAAuthentication no
    # RSAAuthentication yes
    # PasswordAuthentication yes
    # HostbasedAuthentication no
    # GSSAPIAuthentication no
    # GSSAPIDelegateCredentials no
    # BatchMode no
    # CheckHostIP yes
    # AddressFamily any
    # ConnectTimeout 0
    # StrictHostKeyChecking ask
    # IdentityFile ~/.ssh/identity
    # IdentityFile ~/.ssh/id_rsa
    # IdentityFile ~/.ssh/id_dsa
    # Port 22
    Protocol 2
    # Cipher 3des
    # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
    # MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
    # EscapeChar ~
    # Tunnel no
    # TunnelDevice any:any
    # PermitLocalCommand no
    # GSSAPIAuthentication no
    # GSSAPIDelegateCredentials no

    # Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
    # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
    # in this release. The use of 'gssapi' is deprecated due to the presence of
    # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
    # GSSAPIEnableMITMAttack no

    # This enables sending locale enviroment variables LC_* LANG, see ssh_config(5).
    SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
    SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
    SendEnv LC_IDENTIFICATION LC_ALL

    # This will print the fingerprint of the host key in "visual" form
    # this should make it easier to also recognize bad things
    VisualHostKey

    # This will hash new host keys and make them so unusable for malicious
    # people or software trying to use known_hosts to find further hops.
    HashKnownHosts yes

    # ProxyCommand ssh -q -W %h:%p gateway.example.com
    no

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •