0

Host: Raspberry Pi 4B Host Display: Osoyoo 3.5" DSI Touch Screen Host OS: Raspbian (Buster) Client: MacBook Air 2011 Client OS: MacOS Big Sur Client App: Terminal Connection string: ssh -Y pi@pihost.local

What happened: a broken pipe occurred due to loss of wi-fi connection. Consequence: "X11 connection rejected because of wrong authentication." appears each time I try to run my python3 code that was fully functional before losing the X connection.

I've tried several reported solutions listed on this and other sites and none have worked so far. xeyes works fine. I'm the only user on ssh. Here's my xauth output after renaming my ~/.Xauthority and reconnecting.

pi@pihost:~ $ xauth list
pihost/unix:10  MIT-MAGIC-COOKIE-1  495386a19d88503faea5d118e41ce73e

Before the rename and reconnect, my ~/.Xauthority file had similar lines for :11 and :12 as well as a more generic looking line. This change didn't seem to change anything.

I stepped through the solution shown at the following URL and it also had no visible effect.

[https://superuser.com/questions/805725/how-do-i-debug-x11-connection-rejected-because-of-wrong-authentication][1]

Here's my active sessions list:

pi@pihost:~ $ w
 18:44:12 up  6:25,  3 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
pi       tty7     :0               12:19    6:25m 10.71s  0.88s /usr/bin/lxsession -s LXDE-pi -e LXDE
pi       tty1     -                12:19    6:25m  0.12s  0.09s -bash
pi       pts/0    <<hidden IP>>: 18:20    2.00s  0.14s  0.04s w
pi@pihost:~ $

Note: The actual host name and IP address are replaced here for security purposes.

I previously had a similar problem and had to build my raspbian installation all over again, with several add-ons I need for this project. I'm hoping there's an easier solution this time around, as it took several days to get that all installed and working before. I'm still in the process of creating a shell script to do the full installation, so it'll mean piecemeal installation for now and a great loss of time if I have to repeat that.

Any further ideas would be greatly appreciated.

zenmaster43
  • 1
  • 3
  • What does you "python code" do exactly? Does it try to run an X program on an existing `DISPLAY` or what? Are you even actually making use of the X forwarding over ssh? Also, how about logging out the GUI session of `pi` and remove `~/.Xauthority` from its `HOME` (e.g. from console), and re-login? Apparently you are making use of `:0` as the `DISPLAY`? – Tom Yan Jul 12 '21 at 05:07

1 Answers1

0

I've found a solution at https://www.raspberrypi.org/forums/viewtopic.php?t=97451. I entered the command line: sudo xauth add $(xauth -f ~pi/.Xauthority list|tail -1) and it now runs correctly. For regular use, I've added that command line in ~/.bashrc.

zenmaster43
  • 1
  • 3
  • If this worked for you, please upvote, so I can tag this as the solution. – zenmaster43 Jul 12 '21 at 06:47
  • It's probably better to just set and/or preserve the `XAUTHORITY` env var. Perhaps even a symlink if you are essentially just using one user (root and system users excluded). Besides I don't see how it is related to `macOS client` or `after a connection loss`. – Tom Yan Jul 12 '21 at 07:02
  • Tom Yan: Thanks for the feedback. I'm still pretty new to xauth/.Xauthority, so if you could show an example of how to do that, I'd appreciate it. I didn't know either if the client or connection loss were relevant, since it wasn't clear to me what exactly was happening to cause the error. – zenmaster43 Jul 13 '21 at 12:36
  • I have no idea what `~pi` is, but for example, normally `.Xauthority` is in `~` (i.e. `$HOME`) of a user. Suppose the user is named `pi`, you can do something like `export XAUTHORITY=/home/pi/.Xauthority` in its shell rc or profile file (e.g. `~/.bashrc` or `~/.bash_profile`). In a graphical session, whatever starts X for you should set the env var for you as well. However, in a ssh session, normally nothing sets it for you out-of-the-box. Either way, you can check with `printenv XAUTHORITY`. – Tom Yan Jul 13 '21 at 13:13
  • `sudo` apparently by default preserve the env var (it may or may not be the case of your distro build though). `su` seems to depend on whether you use `-`. Anyway, both of them have option for you to preserve it. See their man pages for details. (For sudo you can make that happen with setting in the `sudoer` file as well.) – Tom Yan Jul 13 '21 at 13:15
  • If you prefer an "uglier" but perhaps more "convenient" approach (like the one you used), you can have `export XAUTHORITY=/home/pi/.Xauthority` in e.g. `/root/.bashrc` or `/root/.bash_profile` instead. As you can see, the reason it is ugly is that it statically assume the X server you are accessing with `root` is started by the user `pi`. As an alternative, you can also make a symlink targeting `/home/pi/.Xauthority` in `/root/` with the same name. – Tom Yan Jul 13 '21 at 13:18
  • Actually the approach is mostly necessary/useful only if you are logging in as root directly from console / ssh instead of relying on `sudo`/`su`, as in the latter cases it could be overriden by env var preservation. – Tom Yan Jul 13 '21 at 13:24
  • By the way the above only applies for rootless X. I'm not sure if that's the case on current rasbian (since IIRC that requires kernel-mode setting) or if you use a display manager. – Tom Yan Jul 13 '21 at 14:02