similar to: X11 cookies and forwarding (fwd)

I'm guess I wasn't following the whole cookies discussion completely (putting cookies in /tmp to avoid putting them on NFS, etc.), but I noticed today that with 2.9.9p2, if I use "ssh -X" to start a shell on the server, in that shell XAUTHORITY is set to /tmp/ssh-XXXXXXXX/cookies and there are cookies placed there there. These are the "fake" cookies for the

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.

Hello, I have been having issues with x11 forwarding using my linux-mandrake based servers. I checked my XAUTHORITY variable and it was set to ~/.Xauthority ... After reading the mail archives, I found the /tmp/ssh* directory created during my ssh session, and did this: export XAUTHORITY="/tmp/ssh-hzuA1805/cookies" xeyes ...and the X11 forwarding worked! I'm using the

The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. [This message has been CC'ed to the OpenSSH list in a plea to at least consider supporting more advanced usages of Xauth] Chris Green <sprout at dok.org> writes: > Its not configurable behavior. It always generates a new random file > in /tmp. Then they should probably

On Tue, 6 Nov 2001, Dan Astoorian wrote: > Date: Tue, 6 Nov 2001 13:23:58 -0500 > From: Dan Astoorian <djast at cs.toronto.edu> > To: Dave Dykstra <dwd at bell-labs.com> > Cc: Ed Phillips <ed at UDel.Edu> > Subject: Re: Entropy and DSA key > > On Tue, 06 Nov 2001 10:54:12 EST, Dave Dykstra writes: > > > On Mon, 5 Nov 2001, Ed Phillips wrote: >

http://bugzilla.mindrot.org/show_bug.cgi?id=803 Summary: Security Bug: X11 Forwarding is more powerful than it needs to be. Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-bugs

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

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.

In 2.3.0, the per-user config file was read before the system-wide config file, so options set in ~/.ssh/config took precedence over system-wide defaults. In 2.9.9, the system-wide file seems to be read first, contrary to the man page (cf. ssh.c ll. 631-632). It seems to me that the old behaviour made more sense. (I discovered the change because I could not override a "ForwardX11"

Currently, openssh-2.9p2 adds cookies to a user's .Xauthority file if X11 forwarding is requested but does not delete them while closing down the connection. While this may not necessarily be a security vulnerability, but it's a good idea for the application to cleanup appropriately. This patch takes care of removing the X forwarding cookies from the user's .Xauthority file. Please

On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes: > On Thu, 27 Sep 2001, Dan Astoorian wrote: > > > > > It would (IMHO) be useful if there were a way to optionally configure > > that code to fall back to the internal entropy gathering routines in the > > event that EGD was not available; as it is, the routines simply fail if > > EGD is unavailable at the

In switching to openssh from ssh-1.2.27, I have encountered the following problem with the way openssh handles its XAUTHORITY files separately from ~/.Xauthority. XEmacs has a gnuserv process that runs and allows commands to be issued to a remote XEmacs process. The trouble is when the command is to make a new frame ( window ) on a different X display, it fails because the Xauth cookie is not in

I discovered this in openssh-2.3.0p1; it may affect earlier versions as well. Platforms: Solaris 2.5.1 and 8, probably others. Observed behaviour: With -v, when attempting to connect to a host which is not listening on the requested port, I noticed that the port number is reported as zero in the message: Secure connection to hostname on port 0 refused. Apparent cause: At line

Here's the appropriate output with blow-by-blow explanation embedded... I start by making a connection with X11 forwarding enabled: polycut:~> ssh -v -v -v -X dazel OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /opt/openssh-2.9.9p2/etc/ssh_config debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 23 msec debug3:

Hi, It's a shame that the sshd/sftp-server programs do not support chroot and sftp-only users. As far as I can tell, there's a patch availble that modifies OpenSSH to chroot() based on a specific entry in /etc/passwd. Since, I personally, do not enjoy applying unofficial patches to released programs, I was looking for an alternative but found none. I've written a small sample

I've discovered a problem with OpenSSH 2.9.9p2 under Solaris 2.5.1 . In auth.c, secure_filename() walks upwards toward the user's home directory or the filesystem root, verifying that no directories along the way are group or world writable. Solaris 2.5.1's dirname() function has a bug where dirname("/.ssh") returns an empty string instead of "/". This causes

I am using the openssh-2.1.0p3-1 RPM, but i seem to have a similar problem. the debug doesn't say anything about "X11 connection uses different authentication protocol." it just kicks me out. I can't figure it out. very strange. please CC me, because i am not subscribed. thanks, e:~> echo $XAUTHORITY XAUTHORITY: Undefined variable. e:~> xauth list

http://bugzilla.mindrot.org/show_bug.cgi?id=413 Summary: Port forwarding: [localhost:]localport:remotehost:remoteport Product: Portable OpenSSH Version: older versions Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo:

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

Currently, ~/.ssh/environment can set static environment variables, and ~/.ssh/rc can run initialization routines. But there is no way for sshrc to propagate changes to the environment to the user's shell or command. There is, however, a possible way to do this. If the PermitUserEnvironment option is set, sshd could treat the stdout of sshrc as additional assignment lines of the form