SSH -X doesn't seem to work.

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.

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

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.

Yes, you're probably right! :-)

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

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

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).

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.

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

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.

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

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.

No, an old install after upgrade from source.

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

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