X11 forwarding not working with a Remote Login

I did the following on my iMac Pro 2017 running Ventura 13.4.1:


  • Installed XQuartz
  • Enabled Remote Login
  • Added `X11Forwarding yes` to /etc/ssh/sshd_config


I rebooted the computer and from a linux computer I can ssh into the mac using:

  • ssh -X imac1d


Commands work as expected, I get a command prompt and can execute various simple commands like `ls` or `vi file`. But if I try to execute `gitk .` in a git repository the X window appears on the mac not on the linux computer.


If I execute the `gitk .` in the same git repository on the mac itself it works fine. Also if I `ssh -X linux-computer` from the mac and then execute `gitk .` in a git repository on the linux computer that works fine.


Suggestions on what I can do?


iMac Pro (2017)

Posted on Jul 18, 2023 5:19 PM

Reply

Similar questions

30 replies

Jul 21, 2023 4:17 PM in response to winksaville

Latest update.


I decided to do some debugging, I learned how to get some logs from sshd as well as adding `LogLevel DEBUG` to /etc/ssh/sshd_config.


What I've learned is that if I `ssh -X <ip-mac-pro>` from my linux box and then execute `xclock` I get the following logs:


wink@Winks-iMac-Pro gitk % sudo log stream --level debug 2>&1 | grep 'X11'
2023-0 ...  sshd: debug1: channel 1: new [X11 inet listener]
2023-0 ...  sshd: debug1: channel 2: new [X11 inet listener ...
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple. ...
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple. ...
2023-0 ...  sshd: debug1: X11 connection requested.
2023-0 ...  sshd: debug1: channel 3: new [X11 connection fr ...
2023-0 ...  sshd: debug1: channel 3: free: X11 connection f ...
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple.
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple.


But if I do execute `gitk` I get:


wink@Winks-iMac-Pro gitk % sudo log stream --level debug 2>&1 | grep 'X11'
2023-0 ...  sshd: debug1: channel 1: new [X11 inet listener]
2023-0 ...  sshd: debug1: channel 2: new [X11 inet listener]
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple.l ...
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple.l ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  System Events: (LaunchServices) [com.apple.launc ...
2023-0 ...  System Events: (LaunchServices) [com.apple.launc ...
2023-0 ...  System Events: (LaunchServices) [com.apple.launc ...
2023-0 ...  System Events: (LaunchServices) [com.apple.launc ...
2023-0 ...  System Events: (LaunchServices) [com.apple.launc ...
2023-0 ...  System Events: (LaunchServices) [com.apple.launc ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  X11.bin: (HIToolbox) [com.apple.HIToolbox:MBHeig ...
2023-0 ...  X11.bin: (HIToolbox) [com.apple.HIToolbox:MBHeig ...
2023-0 ...  X11.bin: (HIToolbox) [com.apple.HIToolbox:MBHeig ...
2023-0 ...  X11.bin: (HIToolbox) [com.apple.HIToolbox:MBHeig ...
2023-0 ...  X11.bin: (LaunchServices) [com.apple.launchservi ...
2023-0 ...  X11.bin: (HIServices) [com.apple.hiservices:proc ..
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  loginwindow: (LaunchServices) [com.apple.launchs ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...
2023-0 ...  X11.bin: (HIToolbox) [com.apple.HIToolbox:MBHeig ...
2023-0 ...  X11.bin: (HIToolbox) [com.apple.HIToolbox:MBHeig ...
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple.l ...
2023-0 ...  ContextStoreAgent: (LaunchServices) [com.apple.l ...
2023-0 ...  loginwindow: (LaunchServices) [com.apple.launchs ...
2023-0 ...  runningboardd: (RunningBoard) [com.apple.running ...


When executing `xclock` I see the gui on the linux box, but when I execute `gitk` I see the gui on the  Mac! Also, when looking at the logs notice that there are 5 that the that have `sshd: ` when executing `xclock` but only 2 lines when executing `gitk`. The three missing lines, less the preamble, are:


sshd: debug1: X11 connection requested.
sshd: debug1: channel 3: new [X11 connection from ::1 port 49578]
sshd: debug1: channel 3: free: X11 connection from ::1 port 49578, nchannels 4


I cloned the openssh source code and used `rg` to search for 'connection requested' and I found:


wink@Winks-iMac-Pro ssh % rg 'connection requested'
channels.c
1655:	debug("X11 connection requested.");


If we look at what routine that  `debug` line is in, we see:


/* This is our fake X11 server socket. */
static void
channel_post_x11_listener(struct ssh *ssh, Channel *c)
{
	Channel *nc;
	struct sockaddr_storage addr;
	int r, newsock, oerrno, remote_port;
	socklen_t addrlen;
	char buf[16384], *remote_ipaddr;

	if ((c->io_ready & SSH_CHAN_IO_SOCK_R) == 0)
		return;

	debug("X11 connection requested.");


So I "know" that for some reason `gitk` didn't get connected to the "face X11 server" of sshd. So next step is to learn why `channel_post_x11_listener()` didn't get called.


Any clues would be appreciated :)

Jul 21, 2023 5:00 PM in response to winksaville

I’d suggest using screen sharing into the Mac, as using X is… entertaining.


I’ve done a whole lot of X11 among weird systems, and written some X11 apps, and you’re going to need to become familiar with the X11 log files on both ends of the connection when something goes weird.


With gitk, that’s based on GTK, and that adds its own: https://docs.gtk.org/gtk3/x11.html


Here, it’ll usually be the DISPLAY variable, though the display can be specified via the command line. Check that across all your test cases. This would be my initial suspicion, because the X11 client apps will display app output where the DISPLAY setting (or some other local analog) tells the app X11 display to connect.


I don’t know off-hand if whatever gitk and GTK you’re using is X11-capable, too. From some of your posting here, it seems like it does mostly work, though. Also see if you’re running into trust, by trying ssh -Y. That’s probably not the case here given the app X11 display shows up locally and not tossing an error, but I’ve bumped into a few weird X11 errors over the years.


Oh, and one other wrinkle that can cause confusion for new users. The X11 server usually has the graphics controller windows locally, while the X11 clients are the apps. Though it is possible to run the X11 window manager remotely on various platforms.


PS: Screen sharing is your friend. (More info)

Jul 18, 2023 10:12 PM in response to etresoft

I installed git with homebrew and I couldn't fine xclock on homebrew but it was on macports. So I installed macports and then xclock and low and behold xclock worked locally as well as from my remote linux box! I then installed git via macports but it still didn't work :(


I then went ahead and installed xeyes and xterm using macports and they both worked, although I could not resize xeyes from my linux box but it did resize locally. So "simple" programs worked, but git didn't. Also note currently I have three copies of git, LoL:


wink@imac1d 23-07-19T05:04:36.3NZ:~
$ /usr/bin/git --version
git version 2.39.2 (Apple Git-144)
wink@imac1d 23-07-19T05:04:52.3NZ:~
$ /usr/local/bin/git --version
git version 2.41.0
wink@imac1d 23-07-19T05:05:02.3NZ:~
$ /opt/local/bin/git --version
git version 2.41.0


I used which when logged in from my linux box, so "I know which" was being executed, and it was the homebrew version at ```/opt/local/bin/git```


I tended to use homebrew over macports for no real reason, just what I chose.


Which of those to is more "better" in your opinion?


Does it make sense that macports would work for xeyes, xclock but not git?


Txs, Wink

Jul 19, 2023 6:31 AM in response to winksaville

winksaville wrote:

I installed git with homebrew

As always, I stop reading at Homebrew. If you want tools and techniques that work fine out-of-the-box, and somehow break them with errors that no one has ever seen, I can't think of a better way than Homebrew. MacPorts is a close second, but Homebrew is definitely the new king.


Get rid of that junk, erase the hard drive and reinstall the operating system if you have to. Just get rid of them. Then things will work normally.

Jul 20, 2023 8:57 PM in response to etresoft

So here is the status, I erased the drive and reinstalled Ventura and installed xcode command line tools plus XQuartz and I can use the mac as an ssh client or server. And xclock works from with mac as ssh client and server. I then `git clone https://github.com/git/git.git` and tried to build it using `make` as it says to do here as the simplest method of building git. But it failed with an error that the compiler couldn't find `libintl.h`.


I then thought let me try macports again with this new install, funny the resulting gitk didn't properly work locally let alone using the mac as an ssh server. What it did was display the window but the "panels" in the window were black and you couldn't see any data!


So I then thought, what do I have to loose, I'll try homebrew, I uninstalled macports and installed homebrew. That was better than macports, locally gitk worked fine. But using it remotely (mac as a server) it behaved as before, the gitk window was rendered on server not on the remote linux client.


One last tidbit, after installing homebrew I thought I'd see if I could compile git from sources. Guess what the `make` and `make install` completed. Obviously the git dependencies were available now because of the macports & homebrew installs. But alas, the result was more like the macports version, but instead of black panels the panels were white. But again no data could be seen.


So a discouraging day, not sure where I go from here, need to noodle on it.


-- Wink




Jul 21, 2023 8:23 AM in response to winksaville

/System/Library/LaunchAgents/com.openssh.ssh-agent.plist

is on the read-only boot volume.


You should be able to enable ssh debugging using

/etc/ssh/sshd_config

You will need to stop and start System Settings -> Sharing -> Remote Login to get the changes to take effect.


I'm a programmer too. I've even work on different operating system kernels. That does not mean I want to play around with X11 based code 😱

Jul 21, 2023 8:57 AM in response to winksaville

As it is the Linux world is moving away from X11 to other display technology, such as Wayland.


Apple stopped developing the X11.app many years ago, and gave the sources to the XQuartz open source group.


And even XQuartz sometimes issues error messages when connecting to Linux systems and the GUI issues X11 messages it cannot handle properly.


I worked with the Mac OS Classic System 8 MacX developer years ago (late 80's). I was implementing an AppleTalk X11 protocol driver on a VAX/VMS system. I've used X11 for years, with Macs, VMS, AIX, Solaris, and Linux.


However, today, I limit my X11 use to 1 critical source code merge conflict GUI that my company uses on Linux. The alternatives are worse than just firing up XQuartz and putting up with the terrible latency between my Mac and a Linux system 2,000 miles away. But that is the only thing I bother to start XQuartz for (except for 1-off little tests when someone asks an Mac X11 type question).


NOTE: That same 2,000 mile separation does not affect current VNC clients, such as TigerVNC nearly as much as they used to for older VNC clients. I tend to not use VNC either, but that is because I can do all my work via iTerm2 and ssh connections with tmux to keep my remote sessions alive when ssh is disconnected. It is overall faster, and I have far less copy&paste issues than when using a VNC. But it is a personal preference, as I have many co-workers that do all their remote work via a VNC session (same 2,000 mile separation between us and the Linux development systems).

Jul 22, 2023 8:15 AM in response to winksaville

For issues with the git-gui stuff, chat with whoever is maintaining the port. Or debug this, and submit the fixes to the port or to git-gui.


Or better, wipe this Mac, and load Linux. That’s going to be easier, given the UI and tooling preferences here. Trying to use a Mac as a Linux workstation or Linux server is going to be an ongoing exercise in frustration.


Or load and use VNC/RDP/ARD, and use the Mac native tools and native GUI remotely. Not X11. (Yeah, I’ve been using X11 for thirty-some years, and the switch to VNC/RDP/ARD grated, but it works and I don’t have to write to the tooling to the X11 or Wayland APIs.)


And git… git works, and works well for the project it was intended for, but it was made available and stabilized before somebody was able to properly design the UI and tooling and syntax and productize it. Everybody’s been working around all that for some years now, too. Porting the git tooling away from Linux or near approximations is… entertaining, too. Screen-share and use Xcode, or screen-share or ssh and use the native git tooling and the command-line tools.

Jul 22, 2023 8:25 AM in response to MrHoffman

Leaning on what MrHoffman said. You could install Linux in a virtual machine (https://mac.getutm.app) and connect with the virtual machine for your git-gui stuff.


I really do not understand why you want to look at a Linux monitor, and treat macOS as a git server. It is a totally foreign concept to most of the Mac users in this forum. Keep in mind that at work, I spend hours ssh'ed into Linux hosted development systems, and ssh'ed into Linux test systems. But the difference between us, is I'm looking at a Mac monitor and using Mac terminal emulators. On the Linux system I use Linux commands and utilities. At most, I use scp and rsync to transfer files between my systems.

Jul 19, 2023 10:57 PM in response to etresoft

I removed homebrew and macports and then successfully compiled and installed bash from source!


But then I tried compiling git from source and ran into circular dependencies, like:

  • git -> autoconf -> m4 -> help2man, texinfo, autoconf, automake, autopoint


Note autoconf is a dependency of m4 (a circular dep)


But I forged a ahead and was able to build help2man, but then ran into a separate circular dep with texinfo:

  • texinfo -> aclocal -> automake -> autom4te -> autoconf


Searches seem to indicate the solution is to compile on a machine with the appropriate dependencies creating a binary which I could copy to my machine. Or use a package manager like homebrew or macports on the current machine.


I actually have an mac mini m1 but I'm not sure I can cross-compile and create i386 binaries on it, although brings in another level of complexity. @etresoft, what would you suggest?

Jul 20, 2023 11:51 AM in response to winksaville

git is already part of both Xcode and Apple's Command Line Tools. The same is true for m4. Perhaps your environment is still scrambled from Homebrew. It sure wouldn't be the first time.


I have built autoconf relatively recently with no problems. It sounds like either you haven't installed the Command Line Tools or Homebrew and/or Macports has irreversibly corrupted your environment. I recommend the Command Line tools for your use case. Xcode can work too, but it's a bigger download and you have to be a little more strict about platforms. Xcode is almost always a cross-compilation environment.

Jul 20, 2023 12:16 PM in response to etresoft

I've got an "old" 2017 iMac pro could that be an issue?


I actually installed all of Xcode, but after I deleted homebrew and macports so I should have all command line tools, I assume. But as u say something may be borked on my system. Also, gitk and git-gui didn't seem to be available on my system, maybe that's another indication I've done something else wrong.


Finally, can you confirm for me that you can`ssh -X your-mac` from a Linux box and use gitk and git-gui? It would sure be nice to know what I'm trying to do is actually possible :)


Txs again!

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

X11 forwarding not working with a Remote Login

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.