Hi, I am not able to launch netscape from a remote machine. It gives following error: Can't open Display:64.xx.xx.xx:10.0 The rpms installed are: openssh-clients-3.9p1-1 openssh-3.9p1-1 openssh-server-3.9p1-1 openssh-askpass-3.9p1-0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Initially, there was no DISPALY variable defined. So, I did # xhost 64.xx.xx.xx 64.xx.xx.xx being added to access control list # ssh 64.xx.xx.xx # printenv DISPLAY # # export DISPLAY=64.xx.xx.xx:10.0 # printenv DISPLAY # DISPLAY=64.xx.xx.xx:10.0 # netscape #error: can't open display:64.xx.xx.xx:10.0 Here is the content of printenv before DISPLAY was added, ssh_config & sshd_config: [root@INP-LOG-01 root]# printenv PWD=/root HOSTNAME=INP-LOG-01 QTDIR=/usr/lib/qt-2.3.1 CLASSPATH=./:/root/java/classes:/root/CallTrack/app:/root/CallTrack/jar/classes1 2.zip:/root/CallTrack/jar/mysql-connector-java-3.0.8-stable-bin.jar:/root/CallTr ack/jar/SyncUp.jar:/root/CallTrack/jar/xalan.jar:/root/CallTrack/jar/xerces.jar: LESSOPEN=|/usr/bin/lesspipe.sh %s SSH_CONNECTION=12.34.138.231 2092 172.25.32.105 22 KDEDIR=/usr USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;0 1:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.b tm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31: *.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:* .bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;3 5:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35: MACHTYPE=i386-redhat-linux-gnu MAIL=/var/spool/mail/root INPUTRC=/etc/inputrc BASH_ENV=/root/.bashrc LANG=en_US JAVA_HOME=/usr/local/jdk1.3.1_01 LOGNAME=root SHLVL=1 SHELL=/bin/bash USERNAME=root HOSTTYPE=i386 OSTYPE=linux-gnu HISTSIZE=1000 HOME=/root TERM=xterm PATH=/usr/local/jdk1.3.1_01/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/u sr/local/bin:/usr/X11R6/bin:/tmp/status/temp/script/:/root/bin SSH_TTY=/dev/pts/3 _=/usr/bin/printenv # cat /etc/ssh/ssh_config # $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus 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 various options # Host * # ForwardAgent yes # ForwardX11 yes # RhostsRSAAuthentication no # RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication 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,1 # Cipher 3des # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192- cbc,aes256-cbc # EscapeChar ~ Host * ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes cat /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes StrictModes yes #MaxAuthTries 6 #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no #UsePAM no #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server - Thanks
(In reply to comment #0) > Initially, there was no DISPALY variable defined. So, I did If the client requests X11 forwarding ("ssh -X yourserver") but $DISPLAY is not defined after login, this usually means one of the following: - X forwarding is not enabled in the server's sshd_config. - xauth is not installed on either client or server. - xauth wasn't available (or not in the path) at build time and ssh or sshd doesn't know where to find it. (You can specify this with the XAuthLocation option.) > # xhost 64.xx.xx.xx > # export DISPLAY=64.xx.xx.xx:10.0 sshd should set these automatically for you. In general, if you need to fiddle with these yourself then there's something wrong. Also see: http://www.openssh.com/faq.html#3.12 http://www.openssh.com/faq.html#3.13 If none of those work, please attach (ie use "create attachment", don't paste into the text field) the output of "ssh -X -vvv yourserver".
Created attachment 861 [details] Output: ssh -vvv servername
I have attached the output of ssh -X -vvv servername. Also, I modified the /etc/ssh/sshd_config to add an entry for XAuthLocation, the configurations extract now reads as below. But still it does not work. -------- #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes X11DisplayOffset 10 XAuthLocation /usr/X11R6/bin #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 -------------- Is openssh-askpass-gnome rpm required? I have not got it installed. Also, I have openssh-askpass-3.9p1-0 which is slightly lesser version than openssh- 3.9p1-1. Does it make difference? Have not been able to locate 3.9p1-1 version of askpass and askpass-gnome anywhere. Thanks.
(In reply to comment #3) > I have attached the output of ssh -X -vvv servername. OK there's nothing obviously wrong in that. > Also, I modified the /etc/ssh/sshd_config to add an entry for XAuthLocation, > the configurations extract now reads as below. But still it does not work. [..] > XAuthLocation /usr/X11R6/bin You need to specify the full path not just the directory, ie XAuthLocation /usr/X11R6/bin/xauth You will also need to restart sshd after changing the file. Once you change it and restart, please retry the ssh -vvv thing above (and try "echo $DISPLAY" after logging in). > Is openssh-askpass-gnome rpm required? No, it's not required to get X11 forwarding working.
Created attachment 865 [details] ssh -vvv output after setting complete path to Xauthlocation and restarting sshd I modified sshd_config to XAuthLocation /usr/X11R6/bin/xauth and restarted sshd (/etc/init.d/sshd restart). Still does not display. I noticed that whenever I exit from the remote server the DISPLAY variable is lost. I need to set it everytime I connect to remote server. See attached file for complete steps and ssh output, sshd_conf. Thanks.
(In reply to comment #5) > Created an attachment (id=865) [edit] > ssh -vvv output after setting complete path to Xauthlocation and restarting > sshd Is $DISPLAY set on the client before you run ssh -X? > I noticed that whenever I exit from the remote server the DISPLAY variable is > lost. I need to set it everytime I connect to remote server. You shouldn't need to set DISPLAY on the server. Maybe the problem is on the server side... Please run the server in debug mode: ("/path/to/sshd -ddde -p 2022" on the server then connect with "ssh -X -p 2022 yoursever") and attach the debug output from sshd.
> Is $DISPLAY set on the client before you run ssh -X? Yes, see the printenv for client below: BASH_ENV=/root/.bashrc GTK_RC_FILES=/etc/gtk/gtkrc:/root/.gtkrc XMODIFIERS=@im=none LANG=en_US COLORTERM= DISPLAY=:0.0 LOGNAME=root SHLVL=3 GDM_LANG=en_US SESSION_MANAGER=local/HostingOps2:/tmp/.ICE-unix/1389 USERNAME=root SHELL=/bin/bash HOSTTYPE=i386 QT_XFT=0 OSTYPE=linux-gnu HISTSIZE=1000 HOME=/root TERM=xterm PATH=/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/local/bin:/ usr/bin:/usr/X11R6/bin:/root/bin:/root/bin _=/usr/bin/printenv -------------------------------------------------- > Please run the server in debug mode: > ("/path/to/sshd -ddde -p 2022" on the server then connect with "ssh -X -p 2022 > yoursever") and attach the debug output from sshd. [root@servername root]# /etc/rc.d/init.d/sshd -ddde -p 2022 Usage: /etc/rc.d/init.d/sshd {start|stop|restart|reload|condrestart|status} [root@servername root]# ssh -X -p 2022 64.xx.x.xxx ssh: connect to host 64.xx.x.xxx port 2022: Connection refused I am getting connection refused when I try ssh -X -p 2022 64.xx.x.xxx. Thanks.
(In reply to comment #7) > [root@servername root]# /etc/rc.d/init.d/sshd -ddde -p 2022 > Usage: /etc/rc.d/init.d/sshd {start|stop|restart|reload|condrestart|status} That's the startup script. You need the sshd binary, which is probably located at /usr/sbin/sshd or /usr/local/sbin/sshd.
[root@localserver sbin]# /usr/sbin/sshd -ddde -p 2022 debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 151 debug2: parse_server_config: config /etc/ssh/sshd_config len 151 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddde' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2022' socket: Address family not supported by protocol debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2022 on 0.0.0.0. Server listening on 0.0.0.0 port 2022. Generating 768 bit RSA key. RSA key generation complete. [root@localserver sbin]# ssh -X -p 2022 64.xx.x.xxx ssh: connect to host 64.xx.x.xxx port 2022: Connection refused Thanks
(In reply to comment #9) > [root@localserver sbin]# /usr/sbin/sshd -ddde -p 2022 [...] > Server listening on 0.0.0.0 port 2022. [...] > [root@localserver sbin]# ssh -X -p 2022 64.xx.x.xxx > ssh: connect to host 64.xx.x.xxx port 2022: Connection refused You need to run the sshd in debug mode on the server you're connecting to (ie 64.xx.x.xxx). Either you're running it somewhere else, or there is a firewall between the client and server that's blocking the connection to port 2022.
I ran the following on the server/remote machine (ie., 64.xx.x.xxx): [root@remoteserver sbin]# /usr/sbin/sshd -ddde -p 2022 debug2: load_server_config: filename /usr/local/etc/sshd_config debug2: load_server_config: done config len = 149 debug2: parse_server_config: config /usr/local/etc/sshd_config len 149 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddde' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2022' socket: Address family not supported by protocol debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2022 on 0.0.0.0. Server listening on 0.0.0.0 port 2022. Generating 768 bit RSA key. RSA key generation complete. I am running the following from the client/local machine: [root@lclientserver sbin]# ssh -X -p 2022 64.xx.x.xxx ssh: connect to host 64.xx.x.xxx port 2022: Connection refused yes, there is a firewall. But no changes has been done to firewall from the time we were able to launch netscape to now. Thanks.
(In reply to comment #11) > [root@lclientserver sbin]# ssh -X -p 2022 64.xx.x.xxx > ssh: connect to host 64.xx.x.xxx port 2022: Connection refused > > yes, there is a firewall. But no changes has been done to firewall from the > time we were able to launch netscape to now. OK, but it looks like the firewall is preventing the debugging connection on port 2022. You can either a) pick a port that the firewall allows (if there is one) b) kill off the sshd listening on port 22 and use that port (if you have out of band access to restart it if you have to) or c) set LogLevel DEBUG3 in sshd_config and extract the messages from wherever syslogd writes sshd's logs to. When you see "Connection from" in sshd's output then you're on the right track.
I do not have any other port open(including 2022). Also, I do not have access (remote) to start the SSH after shutting it down. I set LogLevel DEBUG3 (in sshd_config) on the remote server. Executed, [root@remoteserver sbin]# /usr/local/sbin/sshd -ddde -p 2022 On checking the /var/log/messages of the remote server, probably the only relevant entry I could find was ".... deny inbound (no xlate)..." Is there any other way I could provide you with debug verbose. Thanks.
(In reply to comment #13) > I do not have any other port open(including 2022). Also, I do not have access > (remote) to start the SSH after shutting it down. You can run sshd in debug on port 22 if you're careful by killing of the listening sshd first, which won't kill the existing sessions. It's a good idea to have out-of-band access to restart sshd if you make a mistake (or maybe an "at" job or something). > I set LogLevel DEBUG3 (in sshd_config) on the remote server. Executed, > [root@remoteserver sbin]# /usr/local/sbin/sshd -ddde -p 2022 No, you need to restart the main sshd that's listening on port 22. > On checking the /var/log/messages of the remote server, probably the only > relevant entry I could find was ".... deny inbound (no xlate)..." You need to check wherever sshd and syslog are configured to send the sshd messages to (this may be /var/log/authlog). Check sshd's SyslogFacility option and syslogd.conf.
Created attachment 883 [details] Output of /usr/sbin/sshd -ddde -p 22 Output of /usr/sbin/sshd -ddde -p 22. Thanks.
The output in attachment #883 [details] doesn't show that the client even requested x11 forwarding. There should be something like this in the debug output: server_input_channel_req: channel 0 request x11-req reply 0 Was DISPLAY set on the client and did you give "-X" to ssh when you generated this output? Could you please get another log with this as the client's command: DISPLAY=foo:0.0 ssh -X yourserver
no reply in two months == no bug
I wonder whether using "-X -Y" switches would solve your problem. Sometimes I need -Y.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.