After ssh'ing to another Debian box running squeeze with X11 connections
forwarded, running an X11 program (gvim in my case), then exiting from
the remote session, the ssh session hands until ^C is hit.  It you don't
start an X11 program the sessin ends normally.  Thus the sequence is:

  local$ ssh -Y user@machine
  remote$ gvim
  remote$ # exit out of gvim immediately, so it isn't running
  remote$ exit
  (ssh hangs as this point, rather then exiting and returning you to the
  local$ prompt)
  ^C
  local$

Such ssh hangs are not unusual.  They are caused by a program running
the background on the remote system holding a forwarded file descriptor
forwarded socket open.  However, In the above case there should be no
background process running.

To track down what process is holding the session open you log into the
remote system and do a few ps's:

  x@spare:~$ ps -ef | grep ssh
  root      3317     1  0 Aug01 ?        00:00:02 /usr/sbin/sshd
  root      6149  3317  0 09:49 ?        00:00:00 sshd: x [priv]
  x         6158  6149  0 09:49 ?        00:00:00 sshd: x@pts/0
  root      6249  3317  0 09:51 ?        00:00:00 sshd: x [priv]
  x         6257  6249  0 09:51 ?        00:00:00 sshd: x@notty
  x         6392  6159  0 09:59 pts/0    00:00:00 grep ssh
  x@spare:~$ ssu lsof -p 6257
  COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF    NODE NAME
     <snip>
  sshd    6257    x    3u  IPv4            5569095      0t0     TCP spare.brisbane.lube:ssh->russell-laptop.local:46950 (ESTABLISHED)
  sshd    6257    x   11u  unix 0xffff8801240d9e00      0t0 5569245 /tmp/ssh-iLDNYq6257/agent.6257
  sshd    6257    x   16u  IPv4            5569302      0t0     TCP localhost:6011->localhost:33811 (ESTABLISHED)
  sshd    6257    x   17u  IPv4            5569318      0t0     TCP localhost:6011->localhost:33812 (ESTABLISHED)
  x@spare:~$ ssu netstat -anp | grep -w 33811
  tcp        0      0 127.0.0.1:6011          127.0.0.1:33811 ESTABLISHED 6257/sshd: x@notty
  tcp        0      0 127.0.0.1:33811         127.0.0.1:6011 ESTABLISHED 6293/dbus-launch
  x@spare:~$ ssu ps -wwwwwwwlfp 6293
  F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY TIME CMD
  1 S x         6293     1  0  80   0 -  6559 -      09:51 ?  00:00:00 dbus-launch --autolaunch 69ddc558bb4fc5ec8641f0ce000001af --binary-syntax --close-stderr
  x@spare:~$

So, it would appear that gvim ran dbus-launch, but it didn't exit when
gvim did and is now holding the ssh connection open.  "kill 6293" did
cause the hung ssh to exit, which confirms this.

This is a duplicate of #623570.  But that is reported against openssh,
and I doubt it is an openssh problem.

Dear Maintainer,

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I made a connection and started a program. I expected "only" dbus-launch process, but there are some
kdeinit4 processes. In ssh connection (whith -v) I can see more than one channel opened:

debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 53094
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 53095
debug1: channel 2: new [x11]
debug1: confirm x11
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 53096
debug1: channel 3: new [x11]
debug1: confirm x11

debug1: client_input_channel_open: ctype x11 rchan 6 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 53097
debug1: channel 4: new [x11]
debug1: confirm x11
debug1: channel 3: FORCE input drain

[...]
debug1: channel 6: new [x11]
debug1: confirm x11
debug1: channel 3: FORCE input drain
debug1: channel 3: free: x11, nchannels 8
debug1: channel 6: FORCE input drain
debug1: channel 6: free: x11, nchannels 7

Killing stuck dbus and kdeinit4 processes unlocked the situatione and correctli returned
to source shell:

logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 7

debug1: channel 1: FORCE input drain
debug1: channel 2: FORCE input drain
debug1: channel 1: free: x11, nchannels 6
debug1: channel 2: free: x11, nchannels 5

debug1: channel 9: FORCE input drain
debug1: channel 9: free: x11, nchannels 4


debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 3
debug1: channel 3: FORCE input drain
debug1: channel 3: free: x11, nchannels 2
debug1: channel 7: FORCE input drain
debug1: channel 7: free: x11, nchannels 1

For further info I launched a qt program, but gtk software seems affected too (gvim as stated from Russel); simple
x11 programs seems not affected (e.g. xclock). Maybe the bug is related to desktop base or library
complexity

I see this problem also with ssh -CX iceweasel.
https://bugs.launchpad.net/bugs/592434 looks related.

Cheers,

Mark