Description of problem: Recently, not able to start firefox nightly over ssh to localhost. I also have a script that sets colored prompts (sine 2007) which helped me discover that environment variable DISPLAY is now empty when I ssh. Found that if I set X11UseLocalhost to no, DISPLAY is set again. However, reading "man sshd_config", i'm not convinced this is the correct solution: 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â. Especially, since I've been using sshd for years with X11UseLocalhost set to 'yes'. Version-Release number of selected component (if applicable): $ rpm -qa | grep ssh lib64ssh2_1-1.4.3-6.mga5 openssh-askpass-qt4-1.0.1-8.mga5 openssh-server-6.6p1-5.7.mga5 openssh-askpass-common-6.6p1-5.7.mga5 sshfs-fuse-2.5-3.mga5 openssh-clients-6.6p1-5.7.mga5 libssh2_1-1.4.3-6.mga5 openssh-6.6p1-5.7.mga5 lib64ssh2-devel-1.4.3-6.mga5 lib64ssh4-0.6.5-1.1.mga5 How reproducible: always Steps to Reproduce: 1. no idea. Found DISPLAY was no longer being set. Found and applied above workaround. 2. 3.
Guillaume, I don't see any recent changes in openssh likely to have caused this, but was hoping you'd have some insight on this or as to who else should look at it.
Assignee: bugsquad => guillomovitch
After finding the workaround, I forgot to mention that with X11UseLocalhost yes (default), I get this when logging in: $ ssh ffn@prf Password: X11 forwarding request failed on channel 0 <============ Last login: Fri Jul 22 16:55:23 2016 from prf.pfortin.com [ffn@prf ~]$ echo $DISPLAY <========= [ffn@prf ~]$
The two last updates in OpenSSH are related to X11 forwarding and to environment variables handling, but I'm unable to reproduce the issue myself.
Did you uninstall xauth on remote machine, by any chance ?
Keywords: (none) => NEEDINFOStatus: NEW => ASSIGNED
"remote" is most often the local one $ rpm -qa | grep xauth mkxauth-1.7-23.mga5 xauth-1.0.9-3.mga5 Restoring X11UseLocalhost to no gives: $ ssh ffn@prf Password: X11 forwarding request failed on channel 0 Last login: Fri May 26 16:58:36 2017 from prf.pfortin.com WARNING: Environment variable DISPLAY is empty; many applications/services may fail in weird ways. e.g., X11 over ssh will have no display. ffn@prf Fri May 26 17:01:02 ~ $ Will attach my color prompt script & rc files.
Created attachment 9341 [details] color prompt script This script adds color, italics and/or underlining to give a visual clue as to what type of connection is active.
Created attachment 9342 [details] rc file for color script
I don't see any issues on a relatively fresh MGA6 STA2 installation (which hasn't even had a hostname set): [bgmilne@localhost ~]$ ssh localhost 'firefox --no-remote' Password: [bgmilne@localhost ~]$ (so, it worked). I suspect there is some configuration issue. Can you attach the output of: ssh -vvv localhost 'echo -e "\n\n\n$DISPLAY\n\n\n"' and ssh -X -vvv localhost 'echo -e "\n\n\n$DISPLAY\n\n\n"' Also, please attach any configuration sections referenced in the logs, for example, if you have something like this in the output: debug1: /home/bgmilne/.ssh/config line 1: Applying options for * debug1: /home/bgmilne/.ssh/config line 8: Applying options for localhost Then you should provide the configuration sections that start on lines 1 and 8 in /home/bgmilne/.ssh/config .
CC: (none) => bgmilne
Created attachment 9395 [details] output of commands as requested With "X11UseLocalhost no" and "X11UseLocalhost yes", these 2 commands produce IDENTICAL output for all combinations. No output matching your example occurs.
Your log contains these warnings: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is c9:73:8b:d8:55:24:4c:c6:42:cf:1b:e8:11:d5:45:91. Please contact your system administrator. Add correct host key in /home/pfortin/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/pfortin/.ssh/known_hosts:23 Password authentication is disabled to avoid man-in-the-middle attacks. Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks. X11 forwarding is disabled to avoid man-in-the-middle attacks. The last line is relevant. You should either do what they suggest (e.g. delete line 23 of .ssh/known_hosts) or enable the option 'NoHostAuthenticationForLocalhost yes' for at least localhost. Then maybe you will also be able to log in. This doesn't look like a bug ...
Sorry; lack of sleep -- just did what you asked without thought... I _rarely_ use localhost; normally: ssh altuser@prf Anyway, deleted the offending line (probably caused by me switching back to wifi from ethernet this morning), and I get: with "X11UseLocalhost no" & with|without -X: prf.pfortin.com:14.0 with "X11UseLocalhost yes" & with|without -X: <empty> just as in my initial report. No config sections referenced in the output.
Hi Pierre, This bug was filed against Mageia 5. Did it get fixed? If so, please change its status to RESOLVED - FIXED. If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It continued to get limited extended support since then, but that support has now ended, too. As a result we are closing this bug report as OLD. If you still see this issue in a newer Mageia version, then please reopen this report and say so.
Status: ASSIGNED => RESOLVEDResolution: (none) => OLDCC: (none) => marja11
Tested "ssh user2@{localhost,prf}" with X11UseLocalhost set to yes and no -- all combinations now seem to set $DISPLAY as expected.
Resolution: OLD => WORKSFORME