[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Raspbian: After update from buster to bookworm, X11Forwarding in ssh connection stopped working



On Montag, 7. August 2023 16:33:26 CEST you wrote:
> On Montag, 7. August 2023 15:19:49 CEST you wrote:
> > Dear all,
> >
> > I just dist-upgraded my Raspberry Pi from buster to bookworm, and while
> >
> > ssh -Y...
> >
> > worked like a charm in before the update and I could start any X11 program
> > over ssh, it doesn't work anymore since then. Executing
> >
> > ssh -Y -C -l myUser otherHostname.local -v
> >
> > I get
> >
> > ...
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: Sending environment.
> > debug1: channel 0: setting env LANG = "en_US.UTF-8"
> > debug1: channel 0: setting env LC_MONETARY = "de_CH.UTF-8"
> > debug1: channel 0: setting env LC_MEASUREMENT = "de_CH.UTF-8"
> > debug1: channel 0: setting env LC_TIME = "de_CH.UTF-8"
> > debug1: channel 0: setting env LC_ALL = ""
> > debug1: channel 0: setting env LC_COLLATE = "C"
> > debug1: channel 0: setting env LC_NUMERIC = "de_CH.UTF-8"
> > X11 forwarding request failed on channel 0
> > ...
> >
> > From /etc/ssh/sshd_config on the server:
> >
> > AddressFamily inet
> > X11Forwarding yes
> > X11UseLocalhost no
> >
> > Interestingly, when connecting for the first time I got a warning:
> > WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
> > and I did just
> > ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "otherHostname"
> > which I did.
> >
> > xauth is installed on the server.
> >
> > What can be the reason, that I cannot use X11 forwarding anymore?
> >
> > Thank you.
> >
> > Best,
> > Bernd
>
> Sorry, correction: I didn't upgrade from buster to bookworm but from
> bullseye.

Just for the record: I could solve the problem, and it was sitting somewhere
else...

It's a Raspberry Pi running Raspbian with full sd card encryption, and
headless. Therefore there is dropbear used as small ssh server during boot
(built into initramfs), later ssh-server is used. After the update, dropbear
was also running and my connections where to dropbear, not sshd. Disabling
dropbear therefore solved the problem and my configuration of sshd was
perfectly fine.



Reply to: