Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 70585 - pam_env.conf breaks ssh X11Forwarding and startxfce
Summary: pam_env.conf breaks ssh X11Forwarding and startxfce
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: PAM Gentoo Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
: 70782 70813 70884 71288 71342 71508 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-11-09 07:52 UTC by Uwe Weissenbacher
Modified: 2005-09-12 06:39 UTC (History)
41 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Weissenbacher 2004-11-09 07:52:24 UTC
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.).
Comment 1 whitehawk 2004-11-09 10:01:39 UTC
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.
Comment 2 Mikael A 2004-11-10 15:55:08 UTC
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.
Comment 3 hodak 2004-11-10 22:04:51 UTC
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.
Comment 4 Tim Burrell 2004-11-11 06:12:04 UTC
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.
Comment 5 Tim Burrell 2004-11-11 06:56:01 UTC
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.
Comment 6 LionsPhil 2004-11-12 09:33:52 UTC
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?
Comment 7 hodak 2004-11-12 10:11:35 UTC
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. 
Comment 8 Heinrich Rebehn 2004-11-17 00:52:01 UTC
Even when i log in on a console, DISPLAY is set to :0.0, which is truely 
nonsense and makes midnight commander hang.
Comment 9 Torgeir Hansen 2004-11-18 02:07:53 UTC
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
Comment 10 Torgeir Hansen 2004-11-18 02:08:21 UTC
*** Bug 70813 has been marked as a duplicate of this bug. ***
Comment 11 Jakob Schiotz 2004-11-18 02:41:07 UTC
*** Bug 71508 has been marked as a duplicate of this bug. ***
Comment 12 Jaime Lopez 2004-11-19 02:23:44 UTC
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?
Comment 13 Jakob Schiotz 2004-11-19 03:21:46 UTC
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
Comment 14 Brad Cowan (RETIRED) gentoo-dev 2004-11-25 20:09:15 UTC
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.
Comment 15 Brad Cowan (RETIRED) gentoo-dev 2004-11-25 20:11:33 UTC
*** Bug 71288 has been marked as a duplicate of this bug. ***
Comment 16 J. Alexander Treuman 2004-11-26 17:13:41 UTC
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).
Comment 17 J. Alexander Treuman 2004-11-26 17:52:08 UTC
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).
Comment 18 Tor Klingberg 2004-12-11 14:06:31 UTC
Any fix coming up?
Comment 19 Marcus D. Hanwell (RETIRED) gentoo-dev 2004-12-12 04:10:12 UTC
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.
Comment 20 Don Krajewski 2005-01-25 15:05:34 UTC
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. 
Comment 21 Don Krajewski 2005-01-26 11:51:46 UTC
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.
Comment 22 Pekka Paalanen 2005-02-15 12:47:33 UTC
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?
Comment 23 Martin Schlemmer (RETIRED) gentoo-dev 2005-02-19 13:41:22 UTC
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?
Comment 24 Martin Schlemmer (RETIRED) gentoo-dev 2005-02-25 11:48:25 UTC
*** Bug 70782 has been marked as a duplicate of this bug. ***
Comment 25 Martin Schlemmer (RETIRED) gentoo-dev 2005-02-25 11:50:14 UTC
*** Bug 71342 has been marked as a duplicate of this bug. ***
Comment 26 Brett I. Holcomb 2005-02-25 18:16:32 UTC
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
Comment 27 Martin Schlemmer (RETIRED) gentoo-dev 2005-02-25 23:13:38 UTC
I cant think that it is the same issue ... ?
Comment 28 Brett I. Holcomb 2005-02-26 08:05:43 UTC
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.
Comment 29 Martin Schlemmer (RETIRED) gentoo-dev 2005-02-26 08:33:16 UTC
What about 'startx -- :1' - does that work ?
Comment 30 Brett I. Holcomb 2005-02-26 10:06:10 UTC
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.

Comment 31 Brett I. Holcomb 2005-02-28 15:29:28 UTC
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.
Comment 32 Martin Schlemmer (RETIRED) gentoo-dev 2005-03-01 16:55:11 UTC
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.
Comment 33 Brett I. Holcomb 2005-03-01 18:50:25 UTC
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.
Comment 34 Arthur I. 2005-03-04 03:20:10 UTC
... hey!! ... why you are broken X11 Forwarding ???
my work stoped... can't forward X .. ;((( 
Comment 35 Arthur I. 2005-03-04 03:21:07 UTC
i can't wait any more ...2 month X Forwarding are broken .. 
Comment 36 Arthur I. 2005-03-04 03:23:43 UTC
no one workaround not worked with me ..
i'm trying comment lines in pam_env.conf .. but nothing to happen .. 
Comment 37 Arthur I. 2005-03-04 03:41:19 UTC
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 ...
Comment 38 Arthur I. 2005-03-04 03:45:15 UTC
nice feature i found..
if i connect to myself 
like ssh -X localhost ;)
and run xterm - get "Segmentation fault" =) Loooooooooop ;)
Comment 39 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-03-13 04:35:11 UTC
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.
Comment 40 Martin Schlemmer (RETIRED) gentoo-dev 2005-03-13 07:35:56 UTC
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.
Comment 41 Arthur I. 2005-03-14 02:33:26 UTC
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.
Comment 42 Martin Schlemmer (RETIRED) gentoo-dev 2005-03-14 23:37:31 UTC
*** Bug 70884 has been marked as a duplicate of this bug. ***
Comment 43 Antek Grzymała (antoszka) 2005-04-07 13:23:07 UTC
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.
Comment 44 Akos Ladanyi 2005-04-07 15:21:59 UTC
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?
Comment 45 Akos Ladanyi 2005-04-12 08:18:15 UTC
Any news on this?

What about reverting to a working shadow version (and correcting that security vulnerability) instead of using 4.0.5?
Comment 46 Arthur I. 2005-04-12 09:07:55 UTC
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 ... 
Comment 47 Torgeir Hansen 2005-04-12 11:34:42 UTC
or do what I did, abandon gentoo and start using debian ;)
Comment 48 Jakub Moc (RETIRED) gentoo-dev 2005-04-13 12:25:38 UTC
*** Bug 89001 has been marked as a duplicate of this bug. ***
Comment 49 Akos Ladanyi 2005-04-14 09:19:08 UTC
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.
Comment 50 Martin Schlemmer (RETIRED) gentoo-dev 2005-04-17 10:19:55 UTC
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 ??
Comment 51 Jakob Schiotz 2005-04-17 11:00:19 UTC
 > 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
Comment 52 Tim Keitt 2005-05-12 07:54:50 UTC
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.
Comment 53 Tim Keitt 2005-05-12 08:22:48 UTC
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).
Comment 54 Martin Schlemmer (RETIRED) gentoo-dev 2005-07-04 07:44:51 UTC
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?
Comment 55 Maurice van der Pot (RETIRED) gentoo-dev 2005-07-04 09:37:25 UTC
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.
Comment 56 Minsong Cao 2005-07-11 17:12:43 UTC
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. 
Comment 57 Uwe Weissenbacher 2005-09-12 06:39:24 UTC
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.