Anybody got a hint, even if it's only as to which end is making
the problem?
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.
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 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
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.
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.
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
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
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 <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.
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
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.
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.
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.
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.
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,
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.
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?...
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
(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.
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 <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.
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.
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
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.
Are you sure that FreeBSD's SSHd is reading the configuration file
that you think it is? Maybe the config file location, set at build
time, moved in the past and you replaced and old copy of the config
file that wasn't being used anymore.
Failing that, I'd try setting both ends (client and server) to
defaults (empty config file) except for the one line enabling X11
forwarding in SSHd, and see if that works.
On 27/03/2023 22:34, Computer Nerd Kev wrote:
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
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.
Are you sure that FreeBSD's SSHd is reading the configuration file
that you think it is? Maybe the config file location, set at build
time, moved in the past and you replaced and old copy of the config
file that wasn't being used anymore.
Failing that, I'd try setting both ends (client and server) to
defaults (empty config file) except for the one line enabling X11
forwarding in SSHd, and see if that works.
Thanks for the comment.
Yes, I'm sure the files are right; nevertheless I've tried a fresh almost-empty config file:
root@kirk:/etc/ssh # cat sshd_TEST
X11Forwarding yes
And I /still/ get on the client end:
mike@spock ~ $ ssh -X -v -F /dev/null kirk
.....
debug1: Requesting X11 forwarding with authentication spoofing.
.....
Running /usr/local/bin/xauth remove unix:11.0
/usr/local/bin/xauth add unix:11.0 MIT-MAGIC-COOKIE-1 f6a4308d2f8fd240103a0454872782ec
Erase set to backspace.
On kirk.scotts remote display set to 192.168.0.9:0
(which is wrong)
I've also tried a raspberry OS client in place of mint; same problem unsurprisingly.
(BTW, I have no personal config files on either client or server; just
the system ones in /etc/ssh)
On 2023-03-28, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
On 27/03/2023 22:34, Computer Nerd Kev wrote:
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
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.
Are you sure that FreeBSD's SSHd is reading the configuration file
that you think it is? Maybe the config file location, set at build
time, moved in the past and you replaced and old copy of the config
file that wasn't being used anymore.
Failing that, I'd try setting both ends (client and server) to
defaults (empty config file) except for the one line enabling X11
forwarding in SSHd, and see if that works.
Thanks for the comment.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 162:20:00 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,501 |