X11Forwarding with ssh is configured by default with X11UseLocalhost yes, which is the secure setting. The pam_env.conf delivered with sys-libs/pam-0.77-r1 changes the enviroment var DISPLAY from localhost:X.0 to foreign_host:0.0 so the X11 data is not sent over the tunnel anymore, but directly to the host you are connecting from (Or pam_env sets it and ssh won't touch it, if it is already set. I did not check this.).
The DISPLAY variable also makes startxfce4 unworkable. It checks for the DISPLAY variable, and finds it :0.0 and syas that X is already running. So this is not just about ssh.
And if you are running local multiuser ( with one or several heads ) it'll also mash things up. It appears to set display to :0.0, for the user trying to log on to :1. Which doesn't work, naturally.
Bug #69925 has more info on this, basically DISPLAY was changed in pam_env.conf as a temporary hack to fix shadow bug. I would say that the hack did not work very well.
yes, this is very annoying. How could they let a stable releaes slip with no ssh X11 forwarding! This is absolutely critical to a unix system. This is probably the worst slip up I've ever seen. I suggest criticality and priority of this bug be set to the highest possible setting.
note that upgrading the latest unstable r3 release does NOT fix this problem. the only current solution is to downgrade to the 0.77 release.
Confirm that this breaks XFCE4 -- removing/commenting the DISPLAY line in /etc/security/pam_env.conf resolves the issue temporarily. How on earth did this end up stable?
Can someone who has the rights to do so (perhaps a person filed this bug) increase severity to at least major? This bug has caused problems to many people, but it has not got attentions of devs yet.
Even when i log in on a console, DISPLAY is set to :0.0, which is truely nonsense and makes midnight commander hang.
Not only is the DISPLAY variable a problem; but the XAUTHORITY in pam_env.conf ensures that the system logs are filled with these two lines for each login: -- Nov 10 08:38:19 hjem PAM-env[14132]: Unknown PAM_ITEM: <XAUTHORITY> Nov 10 08:38:19 hjem sshd[14132]: PAM pam_putenv: delete non-existent entry; XAUTHORITY -- a simple workaround for this is just to simple delete the line beginning with XAUTHORITY in pam_env.conf
*** Bug 70813 has been marked as a duplicate of this bug. ***
*** Bug 71508 has been marked as a duplicate of this bug. ***
There's a simple workaround that works for me. I simply comment the OVERRIDE setting related of the DISPLAY variable: DISPLAY DEFAULT=${REMOTEHOST}:0.0 # OVERRIDE=${DISPLAY} This way it will assign a "reasonable" DISPLAY when needed, leaving the value provided by sshd for tunneling when available. Can anybody confirm this is the right way?
I think this will still assign a DISPLAY value when X is not running. Is there any reasonable situation, where a default value should be assigned to DISPLAY? When logging in from a remote machine, most people use ssh, it does the "right thing". Even with the modification, pam_env will get it wrong if you log in from a remote machine without a running X, and some programs will be confused. People who regularly log in without ssh from an insecure X server will be the only one benefitting, and they could do the same thing in their .profile / .bashrc / .tcshrc As you can see, I think the line should be removed altogether. /Jakob
This also causes severe delay in starting midnight commander that is compiled with X libs support, it gets confused thinking its in an X session.
*** Bug 71288 has been marked as a duplicate of this bug. ***
For starters, the XAUTHORITY line never fixed what it was supposed to, and is completely unnecessary (see bug 69925). The DISPLAY line is of course breaking things, which may be a bug in pam. It seems you can't use the variable the line is for in OVERRIDE. For example, using "FOO DEFAULT= OVERRIDE=${FOO}bar": jat@lipari jat $ export FOO=foo jat@lipari jat $ echo $FOO foo jat@lipari jat $ su Password: lipari jat # echo $FOO barbar Haven't checked why it does this, but interesting results nonetheless. The DISPLAY line doesn't serve much purpose though, so it might as well be removed. I'm not sure if REMOTEHOST is used by anything else either, but if not then the whole thing might as well be restored to what it was previously (i.e., just comments).
Sorry, it seems I was a little hasty with this and forgot to test. Ends up removing the DISPLAY line doesn't fix my ssh X forwarding problems. DISPLAY is set correctly now, but I'm still getting an error, though this seems to be an unrelated bug. su - also breaks without it, however this is the wrong way to fix that (again, see bug 69925).
Any fix coming up?
Just to confirm that commenting out basically the whole /etc/security/pam_env.conf file fixed the remote SSH X forwarding issue and starting a second X server on vt8 to play games on - whilst keeping the other X on vt7 for real work. Not sure if what I have done is correct, but what is there now breaks these features on my system.
Adding to CC list. Same problem. All solutions in forum thread do not resolve problem (http://forums.gentoo.org/viewtopic.php?p=1823616). Had to downgrade to sys-libs/pam-0.77-r2; delete /etc/ssh/sshd_config and /etc/pam.d/sshd; recompile ssh; change /etc/ssh/sshd_config to allow X11 forwarding. Now it works with HPUX, Solaris 7,8,9, Irix, and all linux clients. Still returns "unable to find an authentication method" from Exceed clients with the security add on package and "Server responded 'no further authentication methods available' on non-comercial SSH Secure Shell for Windows clients with or without X11 tunneling enabled on the client. You can ssh to another system (Linux/UNIX) with both of these clients and then ssh to Gentoo system and X11 forwarding works as expected.
Traced windows problem to mixed locations for storing SSH aaplication data and that the default settings do not work on the clients. When connecting from Windows boxes, the SSH clients expect to find the keys/hosts files in "c:\Documents and Settings\<userid>.ADS\.ssh" but the data is stored in "c:\Documents and Settings\<userid.ADS\Application Data\SSH". Moved the data from the wrong directory to the right directory, and public-key authentication works. Keyboard interactive does not work (asks for password, but never accepts the correct password). Manually set up the connection with SSH windows clients to force Compression=zlib. Password authentication then works. Turning off compression in sshd_conf file also works.
I have sys-libs/pam-0.77-r6 and I have not changed /etc/security/pam_env.conf myself but left whatever the the pam package suggested. So, my pam_env.conf looks like this: REMOTEHOST DEFAULT= OVERRIDE=@{PAM_RHOST} DISPLAY DEFAULT= OVERRIDE=@{DISPLAY} XAUTHORITY DEFAULT= OVERRIDE=@{XAUTHORITY} When I do 'sudo su -' I get this into the logs: sudo: pq : TTY=pts/9 ; PWD=/home/pq ; USER=root ; COMMAND=/bin/su - sudo: PAM pam_putenv: delete non-existent entry; REMOTEHOST PAM-env[31459]: Unknown PAM_ITEM: <DISPLAY> sudo[31459]: PAM pam_putenv: delete non-existent entry; DISPLAY PAM-env[31459]: Unknown PAM_ITEM: <XAUTHORITY> sudo[31459]: PAM pam_putenv: delete non-existent entry; XAUTHORITY su(pam_unix)[31459]: session opened for user root by pq(uid=0) su[31459]: PAM pam_putenv: delete non-existent entry; REMOTEHOST PAM-env[31459]: Unknown PAM_ITEM: <DISPLAY> su[31459]: PAM pam_putenv: delete non-existent entry; DISPLAY PAM-env[31459]: Unknown PAM_ITEM: <XAUTHORITY> su[31459]: PAM pam_putenv: delete non-existent entry; XAUTHORITY That is for a single 'sudo su -' command. I hardly believe this is what it's supposed to do. Comments?
Hmm, it was tested this side (and worked), and I was busy so got a bit behind the bug checking. The basic idea was to have pam_env handle DISPLAY/XAUTHORITY as the shadow maintainer did not want to accept the patch to have su export DISPLAY, and said we should use pam_env. Anyhow, it worked over here, so not sure why it did not work everywhere, and also commenting those lines seems to work here, so I assume my adding display exporting to the pam_xauth module was enough (yes, you need pam_xauth in /etc/pam.d/su). So back the the fix - can we all please check if commenting the DISPLAY and XAUTHORITY lines in /etc/security/pam_env.conf on _BOTH_ sides fixes this?
*** Bug 70782 has been marked as a duplicate of this bug. ***
*** Bug 71342 has been marked as a duplicate of this bug. ***
Well, I commented out the Display and Xauthority lines and I still can't run more than one instance of X. The first starts fine (I use XDM to start up). If I go to a console and type startx it tries to go to display zero. My /etc/X11/xdm/Xservers has this. :0 local /usr/X11R6/bin/X :1 local /usr/X11R6/bin/X
I cant think that it is the same issue ... ?
Comment #1 indicates he can't run startxfce4 and have it find an open display. In addition the Display variable issue was discussed on the mail list as causing issues with X display. It may not be related but based on some of the comments here I thought it might be.
What about 'startx -- :1' - does that work ?
No. If I have xdm running on :0, go to another console, and then do startx -- :1 it tells me that :0 is already in use.
Unfortunately, I think you are right. I commented out the lines and it has not helped. However, others indicate it affected their ability to run multiple X windows so I thought it might affect it.
Their problem was that DISPLAY was already set on login even with no X running ... Maybe just verify for us if that is not your problem with those lines commented.
I see. Mine lines are commented out and I still can't get xdm to run more than one screen. Sorry - looks like I need to look elsewhere.
... hey!! ... why you are broken X11 Forwarding ??? my work stoped... can't forward X .. ;(((
i can't wait any more ...2 month X Forwarding are broken ..
no one workaround not worked with me .. i'm trying comment lines in pam_env.conf .. but nothing to happen ..
su - xlogo works fine ... and was nerver broken .. but ssh x11forwarding - still not working. i'm trying to connect from Gentoo to RedHat Enterprise AS 3 for remote install Oracle .. and X !! not working ... not working ... not working ... not working ...
nice feature i found.. if i connect to myself like ssh -X localhost ;) and run xterm - get "Segmentation fault" =) Loooooooooop ;)
Well commenting out the lines in pam_env.conf on both sides fixes the SSH forwarding for me, but experimnetation shows it is only needed on the server side to allow X forwarding. Also commenting those lines allows Xnest and extra X sessions on other vts to be started. With those lines both of these things broke for me. This is on and amd64 system, and a couple of x86 systems.
Well, a remerge or update should already give you a pam_env.conf with commented lines - is there anybody that have not yet resolved this somehow? Arthur, I recommend you test between two Gentoo boxes with the lines commented, and maybe try a redhat/something else box to connect to that Redhat server, as see if that actually works, else please give some detailed information that makes sense.
step by step detail info about broken X11Forwarding - after some update, about 3month ago, i list X11Forwarding, no special changing. i just doing ssh with eneabled X11Forwarding in conf file. ai@ai ~ $ ssh vml-backup ai@vml-backup's password: /usr/X11R6/bin/xauth: creating new authority file /home/ai/.Xauthority [ai@vml-backup ai]$ xterm [ai@vml-backup ai]$ env | grep DISPLAY DISPLAY=localhost:10.0 [ai@vml-backup ai]$ in this case xterm window are opened but without content (a blank) target machine pam_env.conf -> empty [ai@vml-backup ai]$ cat /etc/security/pam_env.conf | grep -v "^#" [ai@vml-backup ai]$ source machine pam_env.conf -> empty ai@ai ~ $ cat /etc/security/pam_env.conf | grep -v "^#" ai@ai ~ $ debug info while connecting through ssh debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-UQZzB28816/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-UQZzB28816/xauthfile list :0.0 . 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 [ai@vml-backup ai]$ xterm debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 1092 debug2: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug2: channel 1: rcvd adjust 32836 but no window with content ... only empty window border.
*** Bug 70884 has been marked as a duplicate of this bug. ***
Same as for most people, commenting out DISPLAY and XAUTHORITY fixed a number of things: 1) no annoying log entries every two seconds on a server without X at all. 2) ability to run a new xdm on another vc and login normally with the same or other user or whatever. $ su - # xlogo still works OK.
I'm using sys-libs/pam-0.77-r6. In my /etc/security/pam_env.conf everything is commented by default. The problem is that when I log in to this machine via ssh -X then X-forwarding does not work (DISPLAY is unset). I guess the title of the pug is somehow outdated, since surely not pam_env.conf causes this problem now. I also have a Fedora Core 3 machine with pam-0.77 where X-forwarding works. The pam_env.conf is also empty there. My question is, that where should I start looking to find out what's wrong with the Gentoo setup? What mechanisms play a part in setting DISPLAY when logging in to a remote machine via ssh?
Any news on this? What about reverting to a working shadow version (and correcting that security vulnerability) instead of using 4.0.5?
sure, how about this problem? now i think about creating second partition for other Linux Distr... for service Linux servers fabric... about 40 linux (RHEL3) boxes ...
or do what I did, abandon gentoo and start using debian ;)
*** Bug 89001 has been marked as a duplicate of this bug. ***
It works for me now with shadow-4.0.5-r3 and pam-0.77-r6 (with an empty pam_env.conf). Sorry for my previous posts.
pam_env.conf was already fixed some time back: ---- $ grep Id: sys-libs/pam/files/pam_env.conf # $Id: pam_env.conf,v 1.3 2005/02/25 20:31:28 azarah Exp $ $ grep ^DISPLAY sys-libs/pam/files/pam_env.conf ---- Haven't anybody updated their config files ??
> Haven't anybody updated their config files ?? Some of us runs a stable Gentoo system, rather than ~x86. :-) Good to see that the correct solution is implemented in the coming version of pam. /Jakob
There seem to be two bugs. The first was monkeying with user environment variables in pam to begin with. Commenting out everything in pam_env.conf fixes that problem. X11 forwarding works perfectly after that, as long as you use the "-X" switch with ssh. The second bug is with ssh. For some reason, putting "ForwardX11 yes" in ssh_config has no effect. No display variable is set unless you use the "-X" switch on the command line. Doesn't matter if its in /etc/ssh/ssh_config or in ~/.ssh/config.
OK. Quick update. I can see how pam_env.conf could be useful. In the case of ssh, it simply doesn't work. Is it possible that pam_env.conf is evaluated _before_ ssh sets the display variable? That would explain why OVERRIDE has no effect. Also, REMOTEHOST is not set to the host originating the ssh connection. It is set to the destination host. The second bug is not a bug. Hostname matching in ssh_config is on exactly what is typed on the command line. You can't use an IP range (unless you type the IP number when evoking ssh).
Well, like I mentioned earlier, I already reverted the broken "fix" in February ... I guess I should have bumped the revision so that it would get propagated. All I would really like is just for those with issues to verify that it also works for them if they comment those lines in pam_env.conf, or just plain delete the file?
I think it started working for me somewhere in early December. I currently have two pam_env.conf's that only contain comments. No problems anymore.
I updated Openssh to openssh-4.1_p1. At the first trial, the Openssh did not work. The default configure file still need to be changed to enable "X11Forwarding" and "PasswordAuthertication" in order for the software to function correctly.
I think this bug needs to be closed, because it was fixed some time ago. If anybody has a reson, wie can re-open it again.