Hi, if I do the following: ssh -X localhost su - another_user xterm I get: X connection to ming:10.0 broken (explicit kill or server shutdown). Where what is really wanted was something like: Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: :0.0 'tis easy to reproduce the bug, but the debug output that seems relevant is: debug1: X11 connection uses different authentication protocol. I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there are more easy things to do first), so I thought I'd let you know. Cheers, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
While we're on the subject of connections to the local X forwarding port, here's a nit of my own. When I slogin to a remote host with X forwarding enabled, the remote shell sets DISPLAY=foo.bar.com:10.0 (pick your own display number here) where "foo.bar.com" is the remote machine's host name. This works fine as long as there's a valid DNS address entry for that hostname. But if the remote hostname does not correspond to the correct IP address, X forwarding fails. Why should this happen? I have a laptop which normally sits on my home network, and its host name reflects this fact. But occasionally I take it into the office, obtain an IP address with DHCP and slogin into it from my desktop using that IP address. Then the DISPLAY variable setting is incorrect. True, I could set things up to change the host name on the laptop to that provided by DHCP, but I'd rather not do that. (It shows up in outbound email, for example.) Besides, there's a very simple fix: slogin should simply set DISPLAY=127.0.0.1:10.0 (or whatever) regardless of location. Phil
That's a fundamental limitation of the way ssh does forwarding of X connections; it stores the authentication information in ~/.Xauthority, and doing su - both changes the value of ~ and makes it impossible for you to read the file because it has to be readable only by the owner. Old SSH did the same thing. - Dave Dykstra On Sat, Jul 21, 2001 at 01:34:50PM +0100, Matthew Vernon wrote:> Hi, > > if I do the following: > > ssh -X localhost > su - another_user > xterm > > I get: > > X connection to ming:10.0 broken (explicit kill or server shutdown). > > Where what is really wanted was something like: > > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > xterm Xt error: Can't open display: :0.0 > > 'tis easy to reproduce the bug, but the debug output that seems > relevant is: > debug1: X11 connection uses different authentication protocol. > > I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there > are more easy things to do first), so I thought I'd let you know. > > Cheers, > > Matthew > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org
>That's a fundamental limitation of the way ssh does forwarding of X >connections; it stores the authentication information in ~/.Xauthority,I don't believe any of this has anything what so ever to do with the X11 forwarding functionality of ssh since you get exactly the same behaviour on a local login.>and doing su - both changes the value of ~ and makes it impossible for >you to read the file because it has to be readable only by the owner.Not true at all, there is no enforcement of the permissions on the .Xauthority file by xauth or anyone else that I know of and there are no restrictions mentioned in the standard X11R6.4 man page for xauth. As an example: cube$ ssh -X borg Enter passphrase for key '/home/djm/.ssh/id_rsa': Last login: Thu Jul 26 11:50:56 2001 from cube borg$ ls -l ~/.Xauthority -rw------- 1 darrenm staff 453 Jul 26 11:50 /home/darrenm/.Xauthority borg$ chmod 644 ~/.Xauthority borg$ su - Password: # XAUTHORITY=/home/djm/.Xauthority # export XAUTHORITY # DISPLAY=borg:10.0 # export DISPLAY # /usr/X/bin/xdpyinfo name of display: borg:10.0 version number: 11.0 vendor string: Sun Microsystems, In ... I can also start an X client and it will display on braveheart. Okay so this involves the user opening up the permissions on their .Xauthority file to everyone if the users home directory is NFS mounted. If it is local then root could read it anyway (at least on traditional unix filesystems). You could use ACLs to give permission only to root (tricky actually since you need to give the permission to nobody not root, and this isn't really any better than giving world read). I've also written a PAM module for use with su that uses xauth to make a copy of the cookie for the current DISPLAY out of the src users .Xauthority and put it into the destination users .Xauthority. This a safe way to do it - if I ever get the time I'll update the PAM module to remove the cookie from the .Xauthority when the session exits.> >On Sat, Jul 21, 2001 at 01:34:50PM +0100, Matthew Vernon wrote: >> Hi, >> >> if I do the following: >> >> ssh -X localhost >> su - another_user >> xterm >> >> I get: >> >> X connection to ming:10.0 broken (explicit kill or server shutdown). >> >> Where what is really wanted was something like: >> >> Xlib: connection to ":0.0" refused by server >> Xlib: Client is not authorized to connect to Server >> xterm Xt error: Can't open display: :0.0 >> >> 'tis easy to reproduce the bug, but the debug output that seems >> relevant is: >> debug1: X11 connection uses different authentication protocol. >> >> I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there >> are more easy things to do first), so I thought I'd let you know. >> >> Cheers, >> >> Matthew >> >> -- >> "At least you know where you are with Microsoft." >> "True. I just wish I'd brought a paddle." >> http://www.debian.org-- Darren J Moffat
>On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote: >> >That's a fundamental limitation of the way ssh does forwarding of X >> >connections; it stores the authentication information in ~/.Xauthority, >> >> I don't believe any of this has anything what so ever to do with the >> X11 forwarding functionality of ssh since you get exactly the samebehaviour>> on a local login. > >That's true, if you're using xauth.xauth is what OpenSSH uses so what other X authentication are you talking about that has this limitation ?>> >and doing su - both changes the value of ~ and makes it impossible for >> >you to read the file because it has to be readable only by the owner. >> >> Not true at all, there is no enforcement of the permissions on the >> .Xauthority file by xauth or anyone else that I know of and there are >> no restrictions mentioned in the standard X11R6.4 man page for xauth. > >I didn't intend to imply that it was a fundamental limitation, just that >it had to be that way for security reasons.But you used the words ;-) I think I know what you mean though.>> Okay so this involves the user opening up the permissions on their >> .Xauthority file to everyone if the users home directory is NFS mounted. > >Or any other user on the local system even if the user's home directory >is not NFS mounted.If you do the chmod yes, what ai was trying to say was that if the home directory is local then root could read it anyway so you wouldn't need to change the perms.>> If it is local then root could read it anyway (at least on traditional unix >> filesystems). > >True. I believe I've seen cases where su'ing to root (without '-') results >in the original user's .Xauthority file being owned by root, which messes >things up too.The only 3 cases I can think of how that happens is: 1. Local homedir no pre exising .Xauthority, the su action creates one 2. As above but over NFS and homedir is 0777 3. A setuid xauth - bad idea!>> I've also written a PAM module for use with su that uses xauth to >> make a copy of the cookie for the current DISPLAY out of the src users >> .Xauthority and put it into the destination users .Xauthority. This a >> safe way to do it - if I ever get the time I'll update the PAM module >> to remove the cookie from the .Xauthority when the session exits. > >Interesting, but not necessarily safe, if a group of people share the login >you su to. It's too bad that the xauth magic cookie can't be in anWhich is why people should use RBAC systems rather than su to root ;-) (Actually it really needs to be RBAC plus fine grained privilege). How else do you suggest it is done ? root needs the cookie to connect so you have to give it to them some how, if other people use root and you don't trust them then don't log into that machine. I agree that it isn't idea but it is the best that can be done when using the xauth cookie mechanism.>environment variable. On the other hand, I think some systems make it easy >for other people to dump out your environment variables so that would be no >good either./usr/ucb/ps e (Or if your are on a BSD system I guess that is /usr/bin/ps ) /usr/bin/ps on Solaris can't do that since it is no longer setuid and there is no way to access someone elses environment via proc unless you are priveleged. Even still I don't agree with putting security information into environment variable or on the command line. -- Darren J Moffat
>I meant to say that any X access using xauth, including what OpenSSH does >for X forwarding, has the limitation. If you're using plain old xhost >authentication (abhorrent though it is) you don't have the same problem.Agreed.>> Which is why people should use RBAC systems rather than su to root ;-) >> (Actually it really needs to be RBAC plus fine grained privilege). > >Forgive my ignorance, but what's RBAC? I guess "something something Access >Control".Sorry, Role Based Access Control. sudo is kind of a form of RBAC.>in this discussion. Does your PAM module only copy the cookies when su-ing >to root?Yep.>If you're su-ing to root anyway, perhaps all you need to do is set >$XAUTHORITY to point to the original user's $HOME/.Xauthority. Oh, I see, >when you're going over NFS, access by the root user id is usually >disallowed. Was that the main purpose for your PAM module?Exactly. (The case I wrote it for was even more restrictive since it was NFS over Secure RPC). Which was the same as the case demonstrated in the orginal email, hence my mentioning of it. -- Darren J Moffat