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
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)
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…
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…
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
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.
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!?
No, that’s a comment. It neither enables nor disables anything.
Somewhere in my sshd_config, I have:
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
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:
# 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.
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
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
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
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
no
[quote=“bloediandi,post:10,topic:73962”]
i cannot find how ssh_config should cause the problem.
Your problem is likely to be in “sshd_config”, rather than in “ssh_config”
“ssh_config” applies to the client. “sshd_config” applies to the server.
I am using the default “# ForwardX11 no” in “ssh_config”, and note that is only a comment. When I put “-X” on the “ssh” command line, that overrides what is in “ssh_config”.
What is in “sshd_config” applies to the “sshd” daemon running on the server. It cannot be overridden by the “ssh” command line, though it probably can be overridden by the command line used to start “sshd” on the server.
Don’t look at ssh_config ; look at sshd_config on the server
When you post the contents of a configuration file, please use code tags. That makes it easier to read.
In this case, don’t bother to repost because it is the wrong configuration file as I have tried to explain above.
I think I remember having this exact same problem after switching to 11.4. If I recall well the issue had nothing to do with “ssh(d)_config” settings but a missing “xauth” program (the one and only part of the “xorg-x11-xauth” rpm). Please check with “zypper” if you have it installed.
Cheers,
Mark
On 2011-11-21 13:36, bloediandi wrote:
> Have a lot of fun…
Apparently it succeeds.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)