Xpra: Ticket #2696: --tcp-bind binds to 127.0.1.1 when using fdqn of the host

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.



Wed, 01 Apr 2020 04:24:15 GMT - Antoine Martin: owner, description changed

.. --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.


Wed, 01 Apr 2020 11:22:05 GMT - Red Wil:

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 for xpra 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?


Wed, 01 Apr 2020 13:35:40 GMT - Antoine Martin:

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)

Wed, 01 Apr 2020 16:03:54 GMT - Antoine Martin: milestone changed


Wed, 01 Apr 2020 19:26:48 GMT - Red Wil: summary changed

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


Thu, 02 Apr 2020 01:59:14 GMT - Antoine Martin: status changed; resolution set

not clear to me whether is an 'invalid' or maybe 'upstream' since it may be a system configuration issue

Both would be OK.

Thanks.


Sat, 23 Jan 2021 05:58:20 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2696