similar to: [Bug 771] Add option to override XAUTHORITY env variable

Hi, I noticed that Markus has fixed the temporary file cleanup problems in OpenSSH cvs. What files need patching for this ? I only noticed changes in: session.c, channels.h and channels.c. -Jarno -- Jarno Huuskonen <Jarno.Huuskonen at uku.fi>

http://bugzilla.mindrot.org/show_bug.cgi?id=771 Summary: Add option to override XAUTHORITY env variable Product: Portable OpenSSH Version: 3.7.1p1 Platform: UltraSparc OS/Version: SunOS Status: NEW Severity: enhancement Priority: P5 Component: sshd AssignedTo: openssh-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=771 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org Status|NEW |RESOLVED Resolution|---

Hello all, $XAUTHORITY location has moved from under /tmp to ~/.Xauthority in 2.9p2. The commit message was: --- remove xauth-cookie-in-tmp handling. use default $XAUTHORITY, since we do already trust $HOME/.ssh you can use .ssh/sshrc and .ssh/environment if you want to customize the location of the xauth cookies --- The latter is true, but can only be enabled in per-user basis as far as I see.

This issue has been discussed here and elsewhere a fair bit in the past year or so, but to re-address the issue... As of OpenSSH 2.9.something the ability to have an Xauthority located in /tmp was removed, with the following description in the ChangeLog : - markus at cvs.openbsd.org 2001/06/12 21:21:29 [session.c] remove xauth-cookie-in-tmp handling. use default $XAUTHORITY, since

Hi. I see this XAUTHORITY=/tmp/ssh-*/cookies issue has been discussed repeatedly, but I haven't seen a solution to the following problem. Remote user logs into firewall. On firewall, DISPLAY var set to secure channel, XAUTHORITY set to /tmp/ssh-*/cookies. X11 forwarding from firewall works fine. User logs into machine behind firewall, and sets DISPLAY var to firewall:X11DisplayOffset.0.

Hi, Finally got this working!! I have found a potential Workaround to the following error: >/etc/X11/gdm/PreSession/Default: Registering your session with wtmp >and > utmp > /etc/X11/gdm/PreSession/Default: running: /usr/bin/X11/sessreg -a >-w /var/log/wtmp -u /var/run/utmp -x "/var/gdm/:0.Xservers" -h "" -1 >":0" >"test" >Xlib:

I asked this question a while ago, but never got any response. Since then, I've researched the problem some more, so I can give a much more concise description of what's happening. I'm mounting the home directories of the users upon login (using pam_mount) from the Windows server. However, none of the users can run X Windows. It says there's a problem with the .Xauthority file.

I am not 100% positive of the security implications of this, but I really can't see any potential for harm. If this patch is applied (I coded it against the now-current openssh-2.2.0p1), then if (a) the authorized_keys entry has command="whatever" to force a specific command, and also (b) the invoker specified some command on their ssh cmdline, then the invoked command will be

http://bugzilla.mindrot.org/show_bug.cgi?id=733 Summary: ssh doing xauth stuff even when it can't access local .Xauthority file Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=1401 Summary: ssh does not remove staled credentials from .Xauthority Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket

On some of my machines, when I run "su -" in a terminal to get a root shell, an XAUTHORITY file is automatically generated to give display access to GUI programs spawned by that shell, i.e., # set | grep XAUTH XAUTHORITY=/root/.xauthayZmdH That file contains a copy of the MIT-MAGIC-COOKIE from my original X session. On other machines with the same installed OS (CentOS

Why doesn't openssh bother to clean out the entries it places in .Xauthority? The file just keeps growing and growing... -- Karl Amrhein, <ksa at SLAC.Stanford.EDU> | www.slac.stanford.edu/~ksa SLAC Computing Services, Systems Group | 650.926.5083 Bldg 50, 364 --------------------------------------------------------------------- To unsubscribe, e-mail: secureshell-unsubscribe at

http://bugzilla.mindrot.org/show_bug.cgi?id=733 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From dtucker at zip.com.au

https://bugzilla.mindrot.org/show_bug.cgi?id=911 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #1 from Damien Miller <djm at

http://bugzilla.mindrot.org/show_bug.cgi?id=733 ------- Additional Comments From dtucker at zip.com.au 2004-05-12 14:42 ------- Do you have UsePrivilegeSeparation enabled? If not, does enabling it make any difference? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=733 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Comment #3 from dtucker at zip.com.au 2006-10-07 11:36 ------- Change all RESOLVED bug to CLOSED with the exception

Hi! Several people noticed problems with openssh Version 1.2.2 through 1.2.3 related to X11 forwarding under Linux. For example: Magnus Holmberg <pucko at lysator.liu.se> wrote: > I have just installed openssh-1.2.2p1-1 > on two of my machines and I have one problem. > > I have > X11Forwarding yes > in my /etc/ssh/sshd_config > > but when I try to ssh to that

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

When I SSH using protocol 1 from a Debian box running OpenSSH 2.9p2-4 to a sparc.sunos5 box running vanilla OpenSSH 2.9.1, after a little while (of inactivity?) I get the following message on the client terminal: Disconnecting: protocol error: rcvd type 98 Looking further, this message is actually caused by the SSH daemon. However, I'm at a loss to determine why sshd is doing this. I attach