It looks like ssh -X no longer works to run remote programs
which display locally. The man pages for ssh imply that's
because of security concerns, but ssh -Y provides an insecure
workaround.

Far as I can tell, neither command works, both commands fail:

bob@raspberrypi:~ $ ssh -Y nemesis.zefox.com
Password for bob@nemesis.zefox.com:
X11 forwarding request failed on channel 0
Last login: Mon Mar 20 17:26:03 2023 from gateway.zefox.net
[usual login MOTD omitted]
bob@nemesis:~ % xterm -sb &
[1] 1384
bob@nemesis:~ % xterm: Xt error: Can't open display:
xterm: DISPLAY is not set

The host nemesis is FreeBSD -current, up to date as of this morning.
Prior to Bullseye it was possible to open an xterm or chromium
browser window on the Pi, and IIRC it also worked with Bullseye
but I'm not entirely certain.

Anybody got a hint, even if it's only as to which end is making
the problem?

Thanks for reading,

bob prohaska

On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
bob prohaska <bp@www.zefox.net> wrote:

> Anybody got a hint, even if it's only as to which end is making
> the problem?

It may have become necessary to enable it in .ssh/config - one of
my boxes has:

Host *
ForwardX11 yes

From a battle with X11 forwarding some time back.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On 21-03-2023 07:59, Ahem A Rivet's Shot wrote:
> On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
> bob prohaska <bp@www.zefox.net> wrote:
>
>> Anybody got a hint, even if it's only as to which end is making
>> the problem?
>
> It may have become necessary to enable it in .ssh/config - one of
> my boxes has:
>
> Host *
> ForwardX11 yes
>
> From a battle with X11 forwarding some time back.
>

That's the same as the -X commandline option.

I have no experience with this but here's a slim chance: perhaps you are
no longer running X11 but Wayland on either side. I thought it was still
an experimental option on the Pi, though. Check by locally running "echo
$XDG_SESSION_TYPE" in the GUI terminal, output should be either x11 or
wayland. Ssh -X or ssh -Y won't work with remote Wayland without the
XWayland extension; don't know about local, probably worse.

On 21-03-2023 09:50, A. Dumas wrote:
> On 21-03-2023 07:59, Ahem A Rivet's Shot wrote:
>> On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
>> bob prohaska <bp@www.zefox.net> wrote:
>>
>>> Anybody got a hint, even if it's only as to which end is making
>>> the problem?
>>
>>     It may have become necessary to enable it in .ssh/config - one of
>> my boxes has:
>>
>> Host *
>> ForwardX11 yes
>>
>>     From a battle with X11 forwarding some time back.
>>
>
> That's the same as the -X commandline option.
>
> I have no experience with this but here's a slim chance: perhaps you are
> no longer running X11 but Wayland on either side. I thought it was still
> an experimental option on the Pi, though. Check by locally running "echo
> $XDG_SESSION_TYPE" in the GUI terminal, output should be either x11 or
> wayland. Ssh -X or ssh -Y won't work with remote Wayland without the
> XWayland extension; don't know about local, probably worse.

Or maybe it was temporarily broken? I just updated on stock PiOS64 and
got updates for xserver-common and xserver-xorg-core.

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
> bob prohaska <bp@www.zefox.net> wrote:
>
> > Anybody got a hint, even if it's only as to which end is making
> > the problem?
>
> It may have become necessary to enable it in .ssh/config - one of
> my boxes has:
>
> Host *
> ForwardX11 yes

ITYM /etc/ssh/sshd_config for the server side (maybe be different location
on freebsd). A Ubuntu 22.04 install has:

X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes

but the first line may not have it turned on by default in FreeBSD.

Theo

A. Dumas <alexandre@dumas.fr.invalid> wrote:
> On 21-03-2023 07:59, Ahem A Rivet's Shot wrote:
> > On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
> > bob prohaska <bp@www.zefox.net> wrote:
> >
> >> Anybody got a hint, even if it's only as to which end is making
> >> the problem?
> >
> > It may have become necessary to enable it in .ssh/config - one of
> > my boxes has:
> >
> > Host *
> > ForwardX11 yes
> >
> > From a battle with X11 forwarding some time back.
> >
>
> That's the same as the -X commandline option.
>
> I have no experience with this but here's a slim chance: perhaps you are
> no longer running X11 but Wayland on either side. I thought it was still
> an experimental option on the Pi, though. Check by locally running "echo
> $XDG_SESSION_TYPE" in the GUI terminal, output should be either x11 or
> wayland. Ssh -X or ssh -Y won't work with remote Wayland without the
> XWayland extension; don't know about local, probably worse.
>

It may also be that using xhost to allow specific systems and/or users
X access could help.

--
Chris Green
·

On 2023-03-21, Chris Green <cl@isbd.net> wrote:
> A. Dumas <alexandre@dumas.fr.invalid> wrote:
>> On 21-03-2023 07:59, Ahem A Rivet's Shot wrote:
>> > On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
>> > bob prohaska <bp@www.zefox.net> wrote:
>> >
>> >> Anybody got a hint, even if it's only as to which end is making
>> >> the problem?
>> >
>> > It may have become necessary to enable it in .ssh/config - one of
>> > my boxes has:
>> >
>> > Host *
>> > ForwardX11 yes
>> >
>> > From a battle with X11 forwarding some time back.
>> >
>>
>> That's the same as the -X commandline option.
>>
>> I have no experience with this but here's a slim chance: perhaps you are
>> no longer running X11 but Wayland on either side. I thought it was still
>> an experimental option on the Pi, though. Check by locally running "echo
>> $XDG_SESSION_TYPE" in the GUI terminal, output should be either x11 or
>> wayland. Ssh -X or ssh -Y won't work with remote Wayland without the
>> XWayland extension; don't know about local, probably worse.
>>
>
> It may also be that using xhost to allow specific systems and/or users
> X access could help.

AFAIK that is irrelevant to using x forwarding with ssh

It looks like SSH can't connect to your X server for one reason or
another.

I had a similar problem not too long ago, and I seem to remember it was
due to access control issues.

Since I was running my X server by manually invoking Xorg at the time, I
just disabled access control on my X server by running Xorg with the -ac
command line option. This almost certainly isn't a good idea for various
security reasons, but it worked for the 15 minutes I used it.

I also set my $DISPLAY to 'localhost:0' before attempting to ssh
into the remote machine.
--
"If you can't explain it simply, you don't understand it well enough."
- Attributed to Albert Einstein

Jim Jackson <jj@franjam.org.uk> wrote:
> On 2023-03-21, Chris Green <cl@isbd.net> wrote:
> > A. Dumas <alexandre@dumas.fr.invalid> wrote:
> >> On 21-03-2023 07:59, Ahem A Rivet's Shot wrote:
> >> > On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
> >> > bob prohaska <bp@www.zefox.net> wrote:
> >> >
> >> >> Anybody got a hint, even if it's only as to which end is making
> >> >> the problem?
> >> >
> >> > It may have become necessary to enable it in .ssh/config - one of
> >> > my boxes has:
> >> >
> >> > Host *
> >> > ForwardX11 yes
> >> >
> >> > From a battle with X11 forwarding some time back.
> >> >
> >>
> >> That's the same as the -X commandline option.
> >>
> >> I have no experience with this but here's a slim chance: perhaps you are
> >> no longer running X11 but Wayland on either side. I thought it was still
> >> an experimental option on the Pi, though. Check by locally running "echo
> >> $XDG_SESSION_TYPE" in the GUI terminal, output should be either x11 or
> >> wayland. Ssh -X or ssh -Y won't work with remote Wayland without the
> >> XWayland extension; don't know about local, probably worse.
> >>
> >
> > It may also be that using xhost to allow specific systems and/or users
> > X access could help.
>
> AFAIK that is irrelevant to using x forwarding with ssh

Yes, you're probably right! :-)

--
Chris Green
·

On 21/03/2023 10:30, Theo wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
>> bob prohaska <bp@www.zefox.net> wrote:
>>
>>> Anybody got a hint, even if it's only as to which end is making
>>> the problem?
>>
>> It may have become necessary to enable it in .ssh/config - one of
>> my boxes has:
>>
>> Host *
>> ForwardX11 yes
>
> ITYM /etc/ssh/sshd_config for the server side (maybe be different location
> on freebsd). A Ubuntu 22.04 install has:
>
> X11Forwarding yes
> #X11DisplayOffset 10
> #X11UseLocalhost yes
>
> but the first line may not have it turned on by default in FreeBSD.
>
> Theo

Just did 'ssh -X my-fbsd-server' followed by 'truss xterm' on that server.

That throws up:
connect(3,{ AF_INET 192.168.0.9:6000 },16) ERR#61 'Connection refused'

But xterm shouldn't be trying to access that. On the fbsd end, I see that
DISPLAY=192.168.0.9:0

when it should be along the lines of
DISPLAY=localhost:10.0
(which is what I get doing 'ssh -X my-Mint-box' and allows the ssh
server end to forward X requests.)

I've tried fiddling with the sshd_config and ssh_config files to no
avail. Maybe I've missed something, but presumably my Mint client has
correct config's or it wouldn't work at all.

FWIW the Mint client and server have the same configs, where:

mike@troi ~ $ grep -r X /etc/ssh/ssh*_config*
/etc/ssh/ssh_config:# ForwardX11 no
/etc/ssh/ssh_config:# ForwardX11Trusted yes
/etc/ssh/sshd_config:X11Forwarding yes
/etc/ssh/sshd_config:#X11DisplayOffset 10
/etc/ssh/sshd_config:#X11UseLocalhost yes
/etc/ssh/sshd_config:# X11Forwarding no

I've double-checked the fbsd server. That has (with my trial edits)
root@kirk:/home/mike # grep -r X /etc/ssh/ssh*_config*
/etc/ssh/ssh_config:ForwardX11 yes
/etc/ssh/ssh_config:X11Forwarding yes
/etc/ssh/sshd_config:X11Forwarding yes
/etc/ssh/sshd_config:#X11DisplayOffset 10
/etc/ssh/sshd_config:#X11UseLocalhost yes
/etc/ssh/sshd_config:# X11Forwarding no

but the ssh sessions still leaves
DISPLAY=192.168.0.9:0

--
Mike Scott
Harlow, England

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
>> bob prohaska <bp@www.zefox.net> wrote:
>>
>> > Anybody got a hint, even if it's only as to which end is making
>> > the problem?
>>
>> It may have become necessary to enable it in .ssh/config - one of
>> my boxes has:
>>
>> Host *
>> ForwardX11 yes
>
> ITYM /etc/ssh/sshd_config for the server side (maybe be different location
> on freebsd). A Ubuntu 22.04 install has:
>
> X11Forwarding yes
> #X11DisplayOffset 10
> #X11UseLocalhost yes
>
> but the first line may not have it turned on by default in FreeBSD.

The lines above are found on the RasPiOS (display server), but the
remote side (FreeBSD-current) has no matching settings, implying
they're default. According to the man page ssh -Y should work, so
I guess my problem is the FreeBSD side.

Thanks to everyone for reading and replying!

bob prohaska

bob prohaska <bp@www.zefox.net> wrote:
> Theo <theom+news@chiark.greenend.org.uk> wrote:
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>> On Tue, 21 Mar 2023 00:37:49 -0000 (UTC)
>>> bob prohaska <bp@www.zefox.net> wrote:
>>>
>>> > Anybody got a hint, even if it's only as to which end is making
>>> > the problem?
>>>
>>> It may have become necessary to enable it in .ssh/config - one of
>>> my boxes has:
>>>
>>> Host *
>>> ForwardX11 yes
>>
>> ITYM /etc/ssh/sshd_config for the server side (maybe be different location
>> on freebsd). A Ubuntu 22.04 install has:
>>
>> X11Forwarding yes
>> #X11DisplayOffset 10
>> #X11UseLocalhost yes
>>
>> but the first line may not have it turned on by default in FreeBSD.
>
> The lines above are found on the RasPiOS (display server), but the
> remote side (FreeBSD-current) has no matching settings, implying
> they're default.

That means the SSH server is running on the FreeBSD system. If it's
running OpenSSH, then I see this in the sshd_config man page on
Debian Linux:

"X11Forwarding
Specifies whether X11 forwarding is permitted. The argument must
be yes or no. The default is no."

That explicitly states that "X11Forwarding yes" is _not_
the default if there are "no matching settings" in the config file,
unless it's different on FreeBSD for some reason (I doubt it).

> According to the man page ssh -Y should work, so
> I guess my problem is the FreeBSD side.

If "X11Forwarding no", then ssh -Y won't work either, as I
understand it. The ssh man page says it's something to do with the
"ForwardX11Trusted" option.

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
>
> That means the SSH server is running on the FreeBSD system. If it's
> running OpenSSH, then I see this in the sshd_config man page on
> Debian Linux:
>
> "X11Forwarding
> Specifies whether X11 forwarding is permitted. The argument must
> be yes or no. The default is no."
>
> That explicitly states that "X11Forwarding yes" is _not_
> the default if there are "no matching settings" in the config file,
> unless it's different on FreeBSD for some reason (I doubt it).
>
>> According to the man page ssh -Y should work, so
>> I guess my problem is the FreeBSD side.
>
> If "X11Forwarding no", then ssh -Y won't work either, as I
> understand it. The ssh man page says it's something to do with the
> "ForwardX11Trusted" option.

That was it. Added X11Forwarding yes to sshd's config file,
on the FreeBSD host, all is well.

Thank you!

bob prohaska

On 22/03/2023 17:14, bob prohaska wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>>
>> That means the SSH server is running on the FreeBSD system. If it's
>> running OpenSSH, then I see this in the sshd_config man page on
>> Debian Linux:
>>
>> "X11Forwarding
>> Specifies whether X11 forwarding is permitted. The argument must
>> be yes or no. The default is no."
>>
>> That explicitly states that "X11Forwarding yes" is _not_
>> the default if there are "no matching settings" in the config file,
>> unless it's different on FreeBSD for some reason (I doubt it).
>>
>>> According to the man page ssh -Y should work, so
>>> I guess my problem is the FreeBSD side.
>>
>> If "X11Forwarding no", then ssh -Y won't work either, as I
>> understand it. The ssh man page says it's something to do with the
>> "ForwardX11Trusted" option.
>
> That was it. Added X11Forwarding yes to sshd's config file,
> on the FreeBSD host, all is well.
>
> Thank you!
>
> bob prohaska
>

I'm a bit late here, but FWIW I didn't see any mention of running the
ssh client with -v or -vv options to produce debugging information. You
can either trawl back through the terminal output or redirect stderr to
a file by appending 2>some_log_file.

--
Mouse.
Where Morse meets House.

On 22-03-2023 18:14, bob prohaska wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> If "X11Forwarding no", then ssh -Y won't work either, as I
>> understand it. The ssh man page says it's something to do with the
>> "ForwardX11Trusted" option.
>
> That was it. Added X11Forwarding yes to sshd's config file,
> on the FreeBSD host, all is well.

That's great. But this means that something definitely changed on the
remote freebsd side. I could not have guessed that from your OP:

> The host nemesis is FreeBSD -current, up to date as of this morning.
> Prior to Bullseye it was possible to open an xterm or chromium
> browser window on the Pi, and IIRC it also worked with Bullseye
> but I'm not entirely certain.

Was it a new install with new defaults, or did they silently remove the
X11Forwarding option with an automatic update? That would piss me off
enormously.

A. non Eyemouse <somewhere@work.invalid> wrote:
> I'm a bit late here, but FWIW I didn't see any mention of running the
> ssh client with -v or -vv options to produce debugging information. You
> can either trawl back through the terminal output or redirect stderr to
> a file by appending 2>some_log_file.

Really you want the log from the server side, which tells you why it refused
certain features. For debugging authentication issues /var/log/auth.log is
useful, but I'm not sure what the equivalent is for X11 troubles. You can
always increase the logging level in /etc/ssh/sshd_config and then that'll
show in syslog (journalctl -xe in systemd land), but I'm not sure whether
there's a place sshd logs things apart from syslog.

Theo

On 23/03/2023 09:55, Theo wrote:
> A. non Eyemouse <somewhere@work.invalid> wrote:
>> I'm a bit late here, but FWIW I didn't see any mention of running the
>> ssh client with -v or -vv options to produce debugging information. You
>> can either trawl back through the terminal output or redirect stderr to
>> a file by appending 2>some_log_file.
>
> Really you want the log from the server side, which tells you why it refused
> certain features. For debugging authentication issues /var/log/auth.log is
> useful, but I'm not sure what the equivalent is for X11 troubles. You can
> always increase the logging level in /etc/ssh/sshd_config and then that'll
> show in syslog (journalctl -xe in systemd land), but I'm not sure whether
> there's a place sshd logs things apart from syslog.

man 5 ssh_config mentions LogLevel and LogVerbose, by default ssh logs
to stderr but it can be pointed at the syslog. As you mentioned systemd
(which isn't used on FreeBSD) I prefer journalctl -f -u sshd (-u selects
only the following unit entries).

The client debug is incredibly useful, particularly when a newer version
of ssh has defaults which refuse to connect to older ssh servers due to
cypher/key mismatches. This usually requires some overrides in
~./ssh/config.

--
Mouse.
Where Morse meets House.

A. Dumas <alexandre@dumas.fr.invalid> wrote:
> On 22-03-2023 18:14, bob prohaska wrote:
> That's great. But this means that something definitely changed on the
> remote freebsd side. I could not have guessed that from your OP:
>
>> The host nemesis is FreeBSD -current, up to date as of this morning.
>> Prior to Bullseye it was possible to open an xterm or chromium
>> browser window on the Pi, and IIRC it also worked with Bullseye
>> but I'm not entirely certain.

> Was it a new install with new defaults,

No, an old install after upgrade from source.

> or did they silently remove the
> X11Forwarding option with an automatic update? That would piss me off
> enormously.

The giveaway is "-current". That's the R&D branch of FreeBSD, where
new things are tried. After a bit of looking it developed that the -X
option for ssh had been disabled but implied that a -Y option had
been introduced as an override, restoring original behavior. It now
appears that the override was either fumbled or mis-documented.

Compounding the problem was my somewhat hasty and therefore inaccurate
reading of the man pages. Kev's more careful eye corrected my errors.

Thanks for reading!

bob prohaska

bob prohaska <bp@www.zefox.net> wrote:
> The giveaway is "-current". That's the R&D branch of FreeBSD, where
> new things are tried. After a bit of looking it developed that the -X
> option for ssh had been disabled but implied that a -Y option had
> been introduced as an override, restoring original behavior. It now
> appears that the override was either fumbled or mis-documented.

Right, but that's not quite it: the change was in sshd, not ssh. (But
probably the same thing there.)

A. Dumas <alexandre@dumas.fr.invalid> wrote:
> bob prohaska <bp@www.zefox.net> wrote:
>> The giveaway is "-current". That's the R&D branch of FreeBSD, where
>> new things are tried. After a bit of looking it developed that the -X
>> option for ssh had been disabled but implied that a -Y option had
>> been introduced as an override, restoring original behavior. It now
>> appears that the override was either fumbled or mis-documented.
>
> Right, but that's not quite it: the change was in sshd, not ssh. (But
> probably the same thing there.)

Sigh, case of right hand versus left hand?...

bob prohaska

On 24-03-2023 17:37, bob prohaska wrote:
> A. Dumas <alexandre@dumas.fr.invalid> wrote:
>> bob prohaska <bp@www.zefox.net> wrote:
>>> The giveaway is "-current". That's the R&D branch of FreeBSD, where
>>> new things are tried. After a bit of looking it developed that the -X
>>> option for ssh had been disabled but implied that a -Y option had
>>> been introduced as an override, restoring original behavior. It now
>>> appears that the override was either fumbled or mis-documented.
>>
>> Right, but that's not quite it: the change was in sshd, not ssh. (But
>> probably the same thing there.)
>
> Sigh, case of right hand versus left hand?...

Are you saying it was a typo? But command line options like -X and -Y
are to do with ssh, not sshd. I can believe the same setting was
disabled in sshd, but using any option with ssh won't fix that. So I
think you were still confused about the real source of the trouble.

A. Dumas <alexandre@dumas.fr.invalid> wrote:
> So I
> think you were still confused about the real source of the trouble.

Indeed, I am confused. But, one shouldn't be surprised when an experimental
branch of an OS doesn't behave as expected. It's a little surprising that
I got more and better help from this group than from the freebsd lists I
subscribe to. The fix was simple, explictly turn on X11Forwarding in
sshd.conf, something not needed up to this point.

Thanks for reading,

bob prohaska

On 27/03/2023 00:06, bob prohaska wrote:
> A. Dumas <alexandre@dumas.fr.invalid> wrote:
>> So I
>> think you were still confused about the real source of the trouble.
>
> Indeed, I am confused. But, one shouldn't be surprised when an experimental
> branch of an OS doesn't behave as expected. It's a little surprising that
> I got more and better help from this group than from the freebsd lists I
> subscribe to. The fix was simple, explictly turn on X11Forwarding in
> sshd.conf, something not needed up to this point.
>
> Thanks for reading,
>
> bob prohaska

(TLDR tail -8)

I'm now very confused. I have much the same sort of setup: a headless
pi4 running freebsd, plus some linux mint workstations.

I simply /cannot/ ssh into the linux box and get X11 forwarded back to
the workstation. ssh mint <-> mint, and all works as expected, with
DISPLAY set to localhost:10.0 (ie forwarded over the ssh connection).

With ssh from mint -> freebsd, I get DISPLAY set to 192.168.0.9:0, ie
X11 not forwarded over ssh.

The linux config files are presumably correct since it all works as
expected between the mint boxes. I've tried replacing the freebsd
sshd_config with that from linux (and had to fix up
KbdInteractiveAuthentication to log in at all), and it /still/ does not
allow X11 forwarding.

With ssh -v -X, I always seem to get
debug1: Requesting X11 forwarding with authentication spoofing.
so clearly the server isn't allowing it.

On the server end, with sshd -Dd, I see in particular
debug1: active: key options: agent-forwarding port-forwarding pty
user-rc x11-forwarding
....
debug1: server_input_channel_req: channel 0 request x11-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: channel 1: new [X11 inet listener]
debug1: channel 2: new [X11 inet listener]
....
which doesn't help me at all :-{

The pi4, BTW, is on 13.1-RELEASE-p7; mint is at 21 Vanessa.

Bob, would it be possible to post your working sshd config file please?

Thanks.

--
Mike Scott
Harlow, England

Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
> (TLDR tail -8)
> ^
[What's that|?]

> I'm now very confused. I have much the same sort of setup: a headless
> pi4 running freebsd, plus some linux mint workstations.
>
> I simply /cannot/ ssh into the linux box and get X11 forwarded back to
> the workstation.

That's the mirror image of what I'm doing: My ssh -X runs on the Pi,
with FreeBSD answering via sshd. Shouldn't matter, but it might
be interesting to try it both ways. I can't, since the router
won't forward incoming packets without an existing connection.

> ssh mint <-> mint, and all works as expected, with
> DISPLAY set to localhost:10.0 (ie forwarded over the ssh connection).
>
> With ssh from mint -> freebsd, I get DISPLAY set to 192.168.0.9:0, ie
> X11 not forwarded over ssh.
>

My setup includes a router between public and private networks.
The FreeBSD host is on a public net, the RasPiOS workstation is
on a 192.168.... net. I'd expect that to make matters worse,
not better, but in my case it didn't seem to matter. If you have
a router in your setup it might be a worthy suspect.

My router is a DI524, old and cheap. FreeBSD is -current, up to
date as of a day or so ago. RasPiOS is Bullseye, also up to date.

Signal path is RasPi internal Wifi to router Wifi, then wired
connection to to the Pi4.

hth,

bob prohaska

> The linux config files are presumably correct since it all works as
> expected between the mint boxes. I've tried replacing the freebsd
> sshd_config with that from linux (and had to fix up
> KbdInteractiveAuthentication to log in at all), and it /still/ does not
> allow X11 forwarding.
>
> With ssh -v -X, I always seem to get
> debug1: Requesting X11 forwarding with authentication spoofing.
> so clearly the server isn't allowing it.
>
> On the server end, with sshd -Dd, I see in particular
> debug1: active: key options: agent-forwarding port-forwarding pty
> user-rc x11-forwarding
> ...
> debug1: server_input_channel_req: channel 0 request x11-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req x11-req
> debug1: channel 1: new [X11 inet listener]
> debug1: channel 2: new [X11 inet listener]
> ...
> which doesn't help me at all :-{
>
>
> The pi4, BTW, is on 13.1-RELEASE-p7; mint is at 21 Vanessa.
>
>
> Bob, would it be possible to post your working sshd config file please?
>
> Thanks.
>

On 27/03/2023 17:26, bob prohaska wrote:
> Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>> (TLDR tail -8)
>> ^
> [What's that|?]

Me being cryptic - Too Long Don't Read, so head to the last 8 lines. Sorry.

>
>> I'm now very confused. I have much the same sort of setup: a headless
>> pi4 running freebsd, plus some linux mint workstations.
>>
>> I simply /cannot/ ssh into the linux box and get X11 forwarded back to
>> the workstation.
>
> That's the mirror image of what I'm doing: My ssh -X runs on the Pi,
> with FreeBSD answering via sshd. Shouldn't matter, but it might
> be interesting to try it both ways. I can't, since the router
> won't forward incoming packets without an existing connection.

I see; but we're both trying to run ssh -X on linux and have a freebsd
sshd respond. I think. It shouldn't matter what the exact hardware is.

I'm just on my home LAN at the moment, which ought to make life easier;
no routers involved and everything's visible at one desk.

What I don't get is that since the sshd programs on linux and fbsd are
essentially the same code, just why, with the same configuration file,
one works and the other not.

Maybe I need to diff the sources from the two systems.

--
Mike Scott
Harlow, England