Short:
the command on the server logged in as <user>
xpra start :100 --start-child=rxvt --bind-tcp=<host fdqn>:10100 --tcp-auth=file:filename=<user home>/.xpra/pw.txt \ --exit-with-children=yes --terminate-children=yes --password-file=<user home>/.xpra/pw.txt \ --systemd-run=no --start-via-proxy=no
used to bind to the external address of the <host fdqn>
as return by the command: host <host fdqn>
A bit of background: I am using xpra only on internal network as a remote display better than X11 xdmcp Don't need encryption only some form of authentication. Already have my ssh set up for public key access
Hence about 2 years ago this kind of hybrid solution
using ssh to setup/find a xpra session and then connect to it with a random generated password which is pass back to client through ssh session then client can attach with:
xpra attach tcp:<remote host>:10100 \ --tcp-auth=file:filename=<client home>/.xpra/<remote user>@<remote host>/pw.txt \ --password-file=<client home>/.xpra/<remote user>@<remote host>/pw.txt \ --pulseaudio=no --tray=off --system-tray=no --opengl=yes
Server: xpra v3.0.8-r25879 host Ubuntu 18.04.04 LTS kernel 4.15.0-91-lowlatency
BTW: if you have a better idea how to achieve my goal. Obviously it may be me that I do not know how to use it please be gentle.
..
--bind-tcp=<host fdqn>:10100
.. used to bind to the external address
Why not just use --bind-tcp=0.0.0.0:10100
?
Already have my ssh set up for public key access
Why use tcp with password (which is susceptible to MITM attacks) instead of just using ssh?
xpra attach .. --tcp-auth=... --pulseaudio=no
tcp-auth
and --pulseaudio=no
are meaningless for xpra attach
.
These two options are only used by the server.
Thanks for editing and the hint to use formating
Why not just use
--bind-tcp=0.0.0.0:10100
?
I have way to many interfaces and do not want to listen on all of them. Prefer only one or specified list.
Why use tcp with password (which is susceptible to MITM attacks) instead of just using ssh?
Reduces the bandwidth hence lags and occasional spinning wheels. You are right about MITM but there is no concern about that in this particular case.
tcp-auth
and--pulseaudio=no
are meaningless forxpra attach
. These two options are only used by the server.
Thank you for mentioning it. Did not understood the docs.
tcp-auth
how then to specify the authentication method when attaching?--pulseaudio=no
wanted to have no audio on the attached side
BTW authentication: now if I use xpra attach ... --tcp-bind=<ip>:<port>
the server responds but have an authentication window pop-up. I want authentication done programmatically. Besides that windows asks me to authenticate as the local user not as the remote one which is a bit confusing for me. Do you want me to open another ticket?
how then to specify the authentication method when attaching?
--challenge-handlers=CHALLENGE_HANDLERS
, more details under challenge-handlers
in the manual.
My guess is that you want --challenge-handlers=file,filename=password.txt
.
The --password-file=password.txt
switch is deprecated, but should also work.
wanted to have no audio on the attached side
Use: --speaker=off
.
now if I use
xpra attach ... --tcp-bind=<ip>:<port>
This is not a valid syntax, and the tcp-bind
will not do anything in the current version you have.
I want authentication done programmatically.
I assume you mean without prompts? See challenge-handlers
above.
Besides that windows asks me to authenticate as the local user not as the remote one which is a bit confusing for me.
I don't know how you configured the remote username since you're not showing your updated command lines, so I can't tell you if that's right or not with 100% certainty.
But if you're using bind-tcp
with a simple password file authentication module, the username is immaterial and will be ignored by the server.
As for your original query, I've just tested on my system and using a specific hostname does bind to the interface for that hostname.
Tested on Fedora 31 with -d network
:
$ xpra start --start=xterm --no-daemon --bind-tcp=desktop-eth0:10000 -d network get_enabled_encoders(('rencode', 'bencode', 'yaml')) enabled=['rencode', 'bencode', 'yaml'] setting up tcp sockets: (('desktop-eth0', 10000), {}) <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 0)>.bind(('desktop-eth0', 10000)) tcp: desktop-eth0:10000 : <module 'socket' from '/usr/lib64/python3.7/socket.py'> ... $ lsof -i -n -P | grep 10000 python3 483311 antoine 4u IPv4 6353438 0t0 TCP 192.168.99.1:10000 (LISTEN) $ lsof -i -P | grep 10000 python3 483311 antoine 4u IPv4 6394532 0t0 TCP desktop-eth0:10000 (LISTEN)
Changed the summary to read ... to 127.0.1.1
instead of 127.0.0.1
Sorry not seeing that before.
It seems that Ubuntu (and maybe other distros) have an explicit line in the /etc/hosts
reading
127.0.1.1 foo.bar.tld foo
so if using hostname -i
or any other function that uses hosts
before resolving through dns will return 127.0.1.1
as IP of foo
commenting that line out (I am not quite sure when it creeped in) would render this as non issue maybe.
All works as before without any changes in my scripts. I will have to look into a way to have maximum bandwidth with only one authenticated client attached at one time.
I am letting you change the status since is not clear to me whether is an 'invalid' or maybe 'upstream' since it may be a system configuration issue. Thanks
not clear to me whether is an 'invalid' or maybe 'upstream' since it may be a system configuration issue
Both would be OK.
Thanks.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2696