I've got a kind of obsessed to get xmove working in conjunction with
ssh. Pardon me if you think it is not sensible or worthy goal. A
couple of days ago I read about xmove and thought it might be great to
have it working. So...

ssh gruffi
xmove &
xlogo -display localhost:1

which gave

X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
xmove is not authorized to connect to server localhost:10.0.
Xlib: connection to "localhost:1.0" refused by server
Xlib: X11 connection rejected because of wrong authentication.
channel 2: chan_read_failed for istate 3
channel 2: chan_ibuf_empty for istate 3
Client is not authorized to connect to Server
Error: Can't open display: localhost:1

Well, I googled but what I found fits well under the subject "xauth +
xmove hell", e.g. many descriptions of the problem like above and
hardly any answers. Among the latter, which I read, I didn't find the
"ultimate" answer or the solution using which I might get xmove
working. So I had to experiment

Seeing the "xmove is not authorized to connect to server localhost:10.0." I did

$ ssh gruffi
$ xauth list | grep :10
$ gruffi/unix:10 MIT-MAGIC-COOKIE-1 KEY

Why xmove didn't use this cookie? Nevertheless I did

$ xauth add localhost:10 . KEY
$ xlogo -display localhost:1

and got in reply

X11 connection rejected because of wrong authentication.
Implementing MIT-MAGIC-COOKIE-1 user authentication
Xlib: connection to "localhost:1.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: localhost:1

That was better but not quite enough yet. So encouraged by my little
success I continued

$ xauth add localhost:1 . KEY
$ xlogo -display localhost:1

This gave me Xlogo working. Not bad. Here is I'd like to ask (1) if these
two "xauth add" commands are always necessary? The cookie generated by
ssh is always new and unless there is a way to tell xmove to watch it
I see not other alternative

Next I decided to move the running X application, xcalc this time (I
started it in the previous ssh connection, e.g. where DISPLAY variable
was localhost:10). I opened another ssh connection

$ ssh gruffi
$ echo $DISPLAY
localhost:11.0
$ xmovectrl localhost:1 -list
4 (no name) localhost:10

(2) Why "(no name)" here? I'd expected to see something more
meaningful like xcalc for example.

Now I was almost ready to move but one problem. I read in
using_xmove.txt, xmove.2.0beta2.tar.gz,
ftp://ftp.cs.columbia.edu/pub/xmove/

"When moving clients via xmovectrl -move or -moveall, don't specify
a display number. Just say -move machine, not machine:1 or
machine:0."

Should I use just "localhost"? I tried

$ xmovectrl localhost:1 -moveall localhost

The command just hung up forever without any error message. What was
worse is that xcalc and xmove was also flat-out hung. I reran them and
tried

$ xmovectrl localhost:1 -moveall localhost:11
X11 connection rejected because of wrong authentication.

Again, xmove, xcalc must have been restarted.

$ xauth list | grep :11
gruffi/unix:11 MIT-MAGIC-COOKIE-1 KEY
$ xauth add localhost:11 . KEY
$ xmovectrl localhost:1 -moveall localhost:11

This at last _moved_ the X application successfully. In the previous
ssh connection I saw

ETHAN: matching depth 16 to depth 16
XMOVE: switching client 1 to display localhost:11

Now you'll see my difficulties. I'd surmise them as I don't know the
reliable, documented, and _automated_ way to use xmove + ssh. On the
other hand there is still a possiblity to get it working (at least in
theory). The required keys should be looked for manually as well as
added each time I make a new ssh connection. If a configuration had
changed a little, for example I ran an X application locally then
ssh-ed to the same machine at tried to xmovectrl the application to
new $DISPLAY, the sequence of actions (like described above) would be
different. What is worse, any mistake kills the application and xmove.

Could you please shed some light on this?


--
Vladimir Zolotykh