similar to: Major documentation bug

Versions: openssh-3.8p1-33, heimdal-0.6.1rc3-51, XFree86-4.3.99.902-40, tk-8.4.6-37, all from SuSE 9.1 (unhacked); back-version peers have openssh-3.5p1, XFree86-4.3.0-115, etc. from SuSE 8.2. Symptoms: 1. When the client and server versions are unequal, the Kerberos ticket is not accepted for authentication. All the clients have PreferredAuthentications gssapi-with-mic, gssapi, others. 2.

Folks, This morning I downloaded and installed a security update for my MAC G5. I am running MAC OSX 10.3.9. Friday March 16 I was able to ssh -X me at targetcpu and launch my application this morning March 19 I get this error: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) Atom id in failed request: 0x25 Serial number

I am running Fedora 3 on a Dell 600. The version of OpenSSH is OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 I am connect to a Sparc Solaris 9 uname -a SunOS mycomp 5.9 Generic_117171-07 sun4u sparc SUNW,Ultra-250 I use ssh to get from Fedora to the Sparc ssh -X root at mycomp mycomp password: And I am logged in. For this example I run xterm, but it also fails with xemacs Run xterm The terminal

http://bugzilla.mindrot.org/show_bug.cgi?id=851 Summary: some X11 prgs generate ``BadAtom (invalid Atom parameter)'' in X_GetProperty when using X11 forwarding Product: Portable OpenSSH Version: 3.8.1p1 Platform: All OS/Version: Solaris Status: NEW Severity: normal Priority: P2

Hello i have a problem on CentOS 4 with starting remote x application on remote CentOS 3 od Solaris 9 boxes. The problem is: When I run it from CentOS 3 it's OK form CentOS 4 I cannot find a bad word in logs ... My local machine stoping firewall [root at klima-pc ~]# service iptables stop [root at klima-pc ~]# iptables-save [root at klima-pc ~]# SELinux is OFF I am connecting by ssh

Has anybody else experienced weird X11 forwarding problems such as the one below: andreas at teste10:~> x3270 X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 3 (X_GetWindowAttributes) Resource id in failed request: 0x404372 Serial number of failed request: 833 Current serial number in output stream: 834 or andreas at teste10:~>

http://bugzilla.mindrot.org/show_bug.cgi?id=832 Summary: X forwarding crashes on some applications Product: Portable OpenSSH Version: 3.8p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org ReportedBy: ktaylor

On Mon, 6 Jul 2015, Liam O'Toole wrote: > On 2015-07-05, Gordon Messmer > <gordon.messmer at gmail.com> wrote: >> On 07/05/2015 04:51 AM, Liam O'Toole wrote: >> >> At this point, I don't think it's even possible to set >> ForwardX11Trusted=no any more. The X SECURITY extension was replaced >> with "X Access Control Extension"

On 2005-01-11 at 6:36:13 Darren Tucker said: > kochera at postfinance.ch wrote: > > We upgraded from 3.7.1p2 to 3.9p1. The behaviour of the X11 forwarding > > changed significantly, it is much slower. See below the truss output > > (server side which runs 3.7.1p2) an check for the timestamp (6 seconds > > delay). Do you have any idea what may causes this behaviour?

OpenSSH 3.8 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or

OpenSSH 3.8 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or

On 07/05/2015 04:51 AM, Liam O'Toole wrote: > One practical difference I have seen is the improved performance of -Y > over -X. I have long attributed that to the relaxation of security > controls in the former case. When and how did you measure that? The -Y change was introduced in Fedora Core 3, in November 2004. The default was changed to ForwardX11Trusted=yes just a month or

X11 forwarding is not working. It has unstable behaviour, X clients often have lost connections (cannot find window). Typical example - gimp, launched from remote host. Tested latest snapshots.

https://bugzilla.mindrot.org/show_bug.cgi?id=1785 Summary: configurable timeout for x11 cookies Product: Portable OpenSSH Version: 5.5p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

i tried running a couple apps in wine remotely, piping X to my powerbook w/ OS 10.4.6 which otherwise works fine. thus i think this is wine- or app-specific. i get similar errors (see below) in different apps. on the surface, looks like bad window or pointer. i figure wine can't find the right libs for display on the client... do i just need a PATH to my the libs on my client? e.g.

I'm running into an a problem with x11 forwarding over ssh I'm trying to run an application (rasmol - molecule viewing program) which when using the the default setup for x11 forwarding causes the following error: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 132 (MIT-SHM) Minor opcode of failed request: 1

Since packaging OpenSSH 3.8p1 for Debian, I've got a flood of bug reports and confusion about the new untrusted X client configuration. At least part of this seems to be the short (2 minutes!) timeout on the cookie, so that if you're impatient like me and open a connection to a machine that takes a little while to do the key exchange, go off and do something in another window in the

Hello, I know this is likely to give me a brute force attack hit, but the only thing anyone can accomplish by ssh-ing to my machine is to provide me with a tunnel into your machine. So don't bother. Anyway, my server machine is running this: /usr/bin/ssh -X -R ${port}:localhost:22 -o BatchMode=yes \ -o StrictHostKeyChecking=no ${user}@${my_home_machine} On my local machine: ssh -vvv -X

I've fixed the original report and Tom's first. Someone had incorrrectly arranged for most of the initialization to be done only once per session. I did ask before 1.3.0 what the intention was .... For pseudocolor devices at least this was biting since the palette was not re-initialized. I don't see point two on my system, and Martin's point about interruption was first shown

This change allows use of untrusted X11 forwarding (which is more secure) without requiring users to choose a finite timeout after which to refuse new connections. This matches the semantics of the X11 security extension itself, which also treat a validity timeout of 0 on an authentication cookie as indefinite. Signed-off-by: Trixie Able <table at inventati.org> --- clientloop.c | 12