Sometimes ~/.Xauthority is not writable, so to tunnel X, another location must be supplied. I propose ssh_config variable OverrideXAUTHORITY. If set, sshd could place XAUTHORITY in the environment, pointing either to this file, or, if it's a directory, to some generated unique filename in that directory. It would then propagate XAUTHORITY to the user's environment also. Because, when this option is present, sshd would _always_ override XAUTHORITY, there is no need for any messy code to try to figure out where the orignal XAUTHORITY was or should have been. This could be mostly handled by using XAuthLocation, but there is no way with that facility to place XAUTHORITY back into the users's environment, and I think that it'd be easier to provide the config option than to provide some feedback path from xauth to the real path. -- Mario
As I was rummaging around, I ran across the .ssh/environment file. This is a place where I could override XAUTHORITY, but there are all sorts of cautions in the code about enabling this file being a security issue. -- Mario
... And, of course, I meant sshd_config. -- Mario
what about using the existing options: $HOME/.ssh/rc If this file exists, it is run with /bin/sh after reading the en- vironment files but before starting the user's shell or command. It must not produce any output on stdout; stderr must be used in- stead. If X11 forwarding is in use, it will receive the "proto cookie" pair in its standard input (and DISPLAY in its environ- ment). The script must call xauth(1) because sshd will not run xauth automatically to add X11 cookies. The primary purpose of this file is to run any initialization routines which may be needed before the user's home directory be- comes accessible; AFS is a particular example of such an environ- ment. This file will probably contain some initialization code followed by something similar to: if read proto cookie && [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | xauth -q - fi If this file does not exist, /etc/ssh/sshrc is run, and if that does not exist either, xauth is used to add the cookie. This file should be writable only by the user, and need not be readable by anyone else. /etc/ssh/sshrc Like $HOME/.ssh/rc. This can be used to specify machine-specific login-time initializations globally. This file should be writable only by root, and should be world-readable.
The problem with all existing options is that the .ssh/rc (or xauth override) has no mechanism for passing a new value for XAUTHORITY _back_ into the user environment. I suppose I could hack something where the user's profile would look in /tmp/for a file created by .ssh/rc, but there is no direct way for this to be handled. I think a better solution is for the sshd_config to be able to create some new value for XAUTHORITY and pass that in to both the setup programs (xauth, rc, sshrc) and the user's ultimate environment. The alternative is maybe for some mechanism to be created which would allow the rc files to pass back environment values to set, since the rcfiles are executed by popen and already write, this would be an even bigger hack. On the other hand, it might be a really cool thing if the Xproto and Xauth keys were made command arguments and then anything output on stdout were just put into the environment. But I think that's a bigger change than what I'm proposing. -- Mario
There is a patch that corrects this behaviour: ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.9/common/006_sshcookie.patch Basically it removes the user defined file then recreates it in /tmp/... Unfortunately, as you can see from the URL it is not up to date. We have been using it for 3.6.1p2 (rhel3 version). I am currently trying to implement it for 3.9p1
Created attachment 1119 [details] Patches openssh to prevent creation of user defined .Xauthority
> Unfortunately, as you can see from the URL it is not up to date. > We have been using it for 3.6.1p2 (rhel3 version). I have just adapted the patch to 3.9p1. I had to remove the following line as the function has disappeared... I'll rewrite it later if I have the time: | fatal_add_cleanup(xauthfile_cleanup_proc, s->pw);
(In reply to Mario Nigrovic from comment #4) > The problem with all existing options is that the .ssh/rc (or xauth > override) > has no mechanism for passing a new value for XAUTHORITY _back_ into > the user > environment. I don't think another mechanism is necessary. ~/.ssh/rc could communicate with subsequent shell initialisation via something like ~/.ssh/xauth.$PPID
closing resolved bugs as of 8.6p1 release