3

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!

3 Answers 3

3

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

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

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.

2
  • Thanks very much for the suggestion of debugging! It helps!
    – jing chen
    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
    – jing chen
    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.

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.
    – JdeHaan
    Nov 11, 2022 at 17:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .