Why XAUTHORITY in /tmp?
Paul D. Smith
override the value of XAUTHORITY since ssh sets it to a user-specific
/tmp directory and installs the cookies there.
But, I've never understood _why_. Why doesn't it just put the cookies
into your ~/.Xauthority file, like normal?
It's a bit of a pain that it works as it does, because while it allows
you to create X sessions on the ssh server system, it _doesn't_ work to
log into another system in the remote cloud and create an X session
there.
In my case, on the remote cloud, home directories are shared so that the
same ~/.Xauthority file is available. Using the "old" ssh, the cookies
would be placed into ~/.Xauthority and it would all Just Work, from any
host in the cloud. With OpenSSH, I need to create a ~/.ssh/rc script to
get the cookie into my ~/.Xauthority file.
I suppose there is some security hole or something with using
~/.Xauthority; can someone give details?
Thanks...
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> HASMAT--HA Software Methods & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Bryan D Howard
...
> In my case, on the remote cloud, home directories are shared so that the
> same ~/.Xauthority file is available. Using the "old" ssh, the cookies
> would be placed into ~/.Xauthority and it would all Just Work, from any
> host in the cloud. With OpenSSH, I need to create a ~/.ssh/rc script to
> get the cookie into my ~/.Xauthority file.
>
> I suppose there is some security hole or something with using
> ~/.Xauthority; can someone give details?
That's right. Think about it. By putting the security information
into a file which is then sent over the wire unencrypted, you've
compromised your security. Unless you're using an *encrypting*
network filesystem, you're lost.
AFAIK, there isn't a widely used *encrypting* network filesystem.
None of the implementations of NFS, AFS, and Samba that I'm familiar
with encrypt the file data sent over the wire.
{Bryan}
--
Bryan D Howard
Richard E. Silverman
Paul> I suppose there is some security hole or something with using
Paul> ~/.Xauthority; can someone give details?
Your home directory in the "cloud" is probably being shared via NFS or
SMB. Thus, your X display keys are being transmitted in the clear over
the network. While this may be acceptable in your particular situation,
it's a not a good idea in general.
--
Richard Silverman
sl...@shore.net
Simon Tatham
> It's a bit of a pain that it works as it does, because while it allows
> you to create X sessions on the ssh server system, it _doesn't_ work to
> log into another system in the remote cloud and create an X session
> there.
It would if you logged into the other system using ssh!
Then you'd get another, different, Xauthority in /tmp on the second
system. X connections originating on the second system would connect
to the ssh server there and be forwarded back to the first system,
where they'd connect to the ssh server _there_ and be forwarded back
to you.
--
Simon Tatham "The voices in my head are trying to ignore me.
<ana...@pobox.com> But if I keep talking, I can drive them insane."
Richard E. Silverman
Dan> (With all due respect, Richard, the snippet above is missing some
Dan> important context. I'll assume you have .ssh/config or
Dan> equivalent files which enable X11 forwarding from A to B, and
Dan> disable it from B to C; otherwise, your excerpt makes no sense at
Dan> all.)
I'm sorry, I thought it was clear from context. Since we're talking about
X forwarding, X forwarding must be turned on from A to B, since the X
display is on A. And it must be turned off from B to C, since otherwise
the XAUTHORITY setting by sshd will prevent the xauth key from being
deposited in the right place and used.
--
Richard Silverman
sl...@shore.net