0

I've been using X11 forwarding to "seamlessly" work on two machines at the same time and it's been working great. The one issue that I'm having is that the connection can be quite slow for some applications and I would like to speed it up. Since both machines are on my private home network I don't really care about the connection being secure, so my first approach was to either disable encryption or switching to a weaker cipher.

After a google search I found that I could get noticeably better performance by enabling trusted X11 forwarding (-Y) and compression (-C). However it appears that the weak but fast ciphers (arcfour and blowfish) have been removed from openssh a few versions ago.

So my questions are?

  1. Is it possible to enable/install these ciphers?
  2. If not, which of the currently available ciphers are the fastest?
  3. Are there any other settings that can be adjusted to speedup the connection?

EDIT: The remote pc is running Ubuntu 20.04 and the local is running Pop!_OS 19.10 (Based on Ubuntu 19.10). Both use GDM3 as their window manager.

Improve this question
4
  • 3
    If both hosts are on a LAN and you don't care about security, you don't have to forward X through SSH in the first place. You could have your clients connect directly to the server over the LAN.
    – Kenster
    Jun 2 '20 at 13:58
  • Nice suggestion, it didn't even pass through my mind. I'll look into it once I have some free time and maybe post an answer if I find some elegant way of doing this.
    – Aaron de Windt
    Jun 2 '20 at 18:54
  • The Xserver option to look for is -listen tcp, but the hard part is finding where your distribution and display manager has hidden it. Add those two details to your post above.
    – meuh
    Jun 2 '20 at 20:00
  • aes128-gcm@openssh.com is the fastest cipher on modern x86-64 processors, but unless you have a network faster than gigabit, every secure encryption/MAC pair is fast enough.
    – bk2204
    Jun 4 '20 at 1:58
0

For an internal network protected from external access, you can enable simple tcp connections to an Xserver. This used to be the default a long time ago, but no longer is, for security. If using gdm3 as display manager, you can edit file /etc/gdm3/custom.conf and add a line to the security stanza:

[security]
DisallowTCP=false

I don't know how to restart gdm3 so you may have to reboot to have this take effect. When you login you should see the Xserver running with option -listen tcp. Normally, this will be on display 0 which you will find listening on tcp port 6000. Ensure your firewall enables this port for tcp connections.

To check you can connect, you can temporarily allow all hosts to connect without authorization:

xhost +

On the client, run an X11 application with the display set to the remote server, eg (assuming the server is called remote) DISPLAY=remote:0 xlogo or xlogo -display remote:0. If this works, on the server reverse that setting, with xhost -, and either use other more limiting xhost options, or copy the MIT magic cookie key from the server's ~/.Xauthority file. To do this, on the server run

xauth list

and choose the line that has the server's name, e.g.

remote/unix:0  MIT-MAGIC-COOKIE-1  653dc9bd80294684b4944f2babf2fd0c

(There may be more lines, ensure you choose the right one). On the client, enter this key to the local authority file (using the name:display without the /unix since it is over tcp):

xauth add remote:0  MIT-MAGIC-COOKIE-1  2ac06b3b50200461378d0b8622f6d9f6

You should now be able to run applications again, just setting the display.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.