4

I'm trying to use ssh -Y/X ManjaroHost from my Mac, but get "X11 Forwarding request failed". I've searched for the solution for two weeks, and have tried many methods suggested by similar posts. It would be a great help to point out my mistakes!

Here are some experiments I've done. To make everything clear, I always ssh from HostA to HostB. HostA is the X server and ssh client, while HostB is the ssh server.

Experiment 1

HostA: My Macbook.
HostB: Another Linux cluster.
It works, perfectly, GUI windows will popup on my Mac.
In HostA, echo $DISPLAY --> /private/tmp/com.apple.launchd.6AxM1TJrRh/org.xquartz:0 In HostB, echo $DISPLAY --> localhost:10.0 So I think my Mac end works good.

Experiment 2

HostA: My Macbook. HostB: Manjaro Linux Lenovo.
HostA: DISPLAY is /private/tmp/com.apple.launchd.6AxM1TJrRh/org.xquartz:0 HostB: DISPLAY is empty.
Here is the debug information from ssh -Yvvv

... ... ... debug1: Requesting X11 forwarding with authentication spoofing. debug1: Requesting authentication agent forwarding. debug1: Sending environment. debug1: channel 2: setting env LC_TERMINAL_VERSION = "3.4.15" debug1: channel 2: setting env LANG = "en_US.UTF-8" debug1: channel 2: setting env LC_TERMINAL = "iTerm2" debug1: mux_client_request_session: master session id: 2 Last login: Wed Nov 9 13:55:34 2022 from 192.168.0.194 X11 forwarding request failed

Experiment 3

In case this is because of some internet setup, I tried to ssh -Y 127.0.0.1 in Manjaro Linux Lenovo

HostA = HostB = Manjaro Linux Lenovo

HostA: DISPLAY = :0

HostB (after ssh): DISPLAY is empty.

The debug information from ssh -Yvvv is

 ssh -Yvvv 127.0.0.1 ... ... ... debug1: client_input_hostkeys: no new or deprecated keys from server debug3: receive packet: type 91 debug2: channel_input_open_confirmation: channel 0: callback start debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 1 debug3: send packet: type 98 debug2: fd 3 setting TCP_NODELAY debug3: set_sock_tos: set socket 3 IP_TOS 0x48 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: send packet: type 98 debug2: channel 0: request shell confirm 1 debug3: send packet: type 98 debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: receive packet: type 100 debug2: channel_input_status_confirm: type 100 id 0 **X11 forwarding request failed on channel 0** debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Wed Nov 9 14:43:39 2022 from 127.0.0.1

It still shows "X11 forwarding request failed on channel 0"

Here is my Manjaro sshd_config file

X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost no AllowTcpForwarding yes AllowAgentForwarding yes PermitRootLogin yes

ssh_config file

HOST * #ServerAliveInterval 60 #ServerAliveCountMax 5 ForwardAgent yes ForwardX11 yes #ControlPersist yes ControlMaster auto ForwardX11Trusted yes

My Mac ssh_config file

HOST * ServerAliveInterval 60 ServerAliveCountMax 5 ForwardAgent yes ForwardX11 yes ControlPersist yes ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p ForwardX11Trusted yes identityfile ~/.ssh/id_rsa_gmail

I think I've tried everything I can, but fail to figure out the issue. Appreciated if someone could help!

Improve this question

3 Answers 3

Reset to default
4

I my case the cause for the ssh client message "X11 forwarding request failed" was that the ssh daemon (on the server) was not able to bind to any port 6000+ (the X11 forwarding port range), because it tried only IPv6, and that wasn't working (it was in a docker container and probably switched-off).

The solution was to change a line in /etc/sshd_config: from AddressFamily any (the default) to AddressFamily inet (i.e., no inet6).

Improve this answer
1
  • Thanks man - recently disabled ipv6 for security reasons and this was my case Commented Dec 22, 2023 at 19:37
3

The most common cause is that the xauth package and thus executable are missing on the server. Run which xauth to find out. Usually you can install with apt install xauth or such.

If it is installed and X11 forwarding still fails: you can enable sshd debugging on the server side too.

Assuming you have root access on the server, find the script starting sshd. On a modern system using systemd, you can do sudo systemctl status ssh to find it. Mine is called /lib/systemd/system/ssh.service. Look for a line starting with ExecStart=. The debugging option for sshd is -d.

You can check the server logfile with journalctl -b -a -u ssh.

Good luck.

Improve this answer
2
  • Thanks very much for the suggestion of debugging! It helps! Commented Nov 11, 2022 at 1:10
  • Thanks @Jdehan for your great help! Now it works! With sudo, I setup the debug mode for sshd in the remote server. From the debug information, I found that the sshd service is only loading /etc/ssh/sshd_config file, without loading .ssh/sshd_config file! So all my edit on ~/.ssh/sshd_config had never been really loaded into the system. In ~/.ssh folder, only the keys and know_host file, and config works. But the ssh_config, sshd_config in .ssh does not, only if you explicitly using -f to load the files Commented Nov 11, 2022 at 1:21
0

Thanks @Jdehan for his great help! Now it works!

With sudo, I setup the debug mode for sshd in the remote server. From the debug information, I found that the sshd service is only loading /etc/ssh/sshd_config file, without loading .ssh/sshd_config file! So all my edit on ~/.ssh/sshd_config had never been really loaded into the system.

In ~/.ssh folder, only the keys and know_host file, and config works. But the ssh_config, sshd_config in .ssh does not, only if you explicitly using -f to load the files.

Improve this answer
1
  • Glad it helped. The /etc/ssh/sshd_config is meant just for the server process sshd. Your ~/.ssh/config is used by the outgoing ssh client process. There is no overlap in usage either way, unless you force them, which is definitely not recommended. Commented Nov 11, 2022 at 17:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.