Despite what the documentation says, I had to do this do ensure that ssh would not end up talking to the ssh agent:
export SSH_AUTH_SOCK=/dev/null export SSH_ASKPASS=/bin/false
Simply unsetting those env vars was not enough.
Then you get this:
$ xpra attach ssh:localhost:10 --ssh="ssh -l aree" --opengl=no ** Message: pygobject_register_sinkfunc is deprecated (GstObject) xpra client version 0.10.0 Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). 2013-07-15 11:47:41,725 read error for TwoFileConnection(ssh:localhost:10) Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 424, in _io_thread_loop callback() File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 472, in _read buf = self._conn.read(8192) File "/usr/lib64/python2.7/site-packages/xpra/net/bytestreams.py", line 70, in read self.may_abort("read") File "/usr/lib64/python2.7/site-packages/xpra/net/bytestreams.py", line 67, in may_abort self._abort_test(action) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 598, in abort_test raise IOError(error_message) IOError: cannot read using ['ssh', '-l', 'aree', '-T', 'localhost', '.xpra/run-xpra', '_proxy', ':10']: the SSH process has terminated with exit code=255 2013-07-15 11:47:41,737 write error for TwoFileConnection(ssh:localhost:10) Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 424, in _io_thread_loop callback() File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 458, in _write written = self._conn.write(buf) File "/usr/lib64/python2.7/site-packages/xpra/net/bytestreams.py", line 74, in write self.may_abort("write") File "/usr/lib64/python2.7/site-packages/xpra/net/bytestreams.py", line 67, in may_abort self._abort_test(action) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 598, in abort_test raise IOError(error_message) IOError: cannot write using ['ssh', '-l', 'aree', '-T', 'localhost', '.xpra/run-xpra', '_proxy', ':10']: the SSH process has terminated with exit code=255 2013-07-15 11:47:41,739 connection closed after 0 packets received (0 bytes) and 1 packets sent (0 bytes)
This was caused by #203 and r2029: running ssh in its own session allows us to make it outlive the xpra process... but also breaks password mode unless you use an authentication agent.
I am tempted to undo #203, or maybe make it clear that you must use a password agent? Or is there a better way?
Maybe defining our own SSH_ASKPASS
command if one is not defined already? (then we can keep the setsid
code..)
What makes this problem much much worse is that even when SSH_ASKPASS
is not defined, the system may still find a way to popup the password dialog (no idea how, this isn't documented), so we cannot use the lack of a SSH_ASKPASS
env var to decide what to do...
Which means that even doing something like this isn't terribly accurate or helpful:
--- src/xpra/scripts/main.py (revision 3849) +++ src/xpra/scripts/main.py (working copy) @@ -571,6 +571,9 @@ kwargs = {} kwargs["stderr"] = sys.stderr if os.name=="posix" and not sys.platform.startswith("darwin"): + askpass = os.environ.get("SSH_ASKPASS") + if not askpass: + sys.stderr.write("Warning: SSH_ASKPASS is not defined, SSH password authentication may not be available\n") def setsid(): #run in a new session os.setsid()
Ideas welcome.
Since it is impossible to have both, r5862 deals with this problem by giving the user the option of having keyboard interaction (--exit-ssh
- which is now the default) or having connection sharing (--no-exit-ssh
).
More information added here: wiki/SSH.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/380