Solved how to enable SSH X11 forwarding in freebsd14.2 ?

Dear all :
i have enabled X11forwarding function in my ssh server of freebsd14.2 with below ...
X11Forwarding yes
X11DisplayOffset 10

now , double freebsd14.2 machines with gnome GUI. one is ssh x11forwarding server, other is ssh client.
when i Launch a GNOME session from a client remote terminal through ssh. always got error : can not open display .

please help me . i want to use ssh open remote freebsd14.2 gnome-session in my client . thanks.

ssh server of freebsd 14.2 gnome GUI ,and enable X11 forwarding.

ssh client of freebsd14.2 gnome GUI , and running command in shell : ssh -X 192.168.200.2
error : can not open display

thanks.
 
Look I misunderstood your X11 port forwarding request and focused on the "post the output from env commnad" portion of SirDices answer. Guess, that you already know how to make a SSH connection and how to save the output from the 'env' CLI command.
My Bad, oops. Here is my long write up below. Sir Dice can delete if not relevant. I will now look deeper at your original 'Port Forward X11' portion of the question above, @ff2024g
Here are some example CLI commands to use and share. 'env' is just a simple command to print the environment settings
# date
# pwd
# whoami
# freebsd-version -kru
# env
# env >my_env_file.txt
# scp my_env_file.txt fred@10.0.0.159:my_env_file.txt I don't remember the simple syntax to copy file back to parent ssh client system computer with an IP4 number 10.0.0.159 Maybe your network IPV4 number is something like 192.168.1.5

fred@Ghost14-selfbuilt-rpi4B-nginx-tst1:~ $ env
SSH_CLIENT=173.11.5.249 53678 22
LOGNAME=fred
PAGER=less
LANG=en_US.UTF-8
MAIL=/var/mail/fred
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/fred/bin
EDITOR=vi
ENV=/home/fred/.shrc
PWD=/home/fred
TERM=linux
SSH_TTY=/dev/pts/0
HOME=/home/fred
USER=fred
SSH_CONNECTION=173.11.5.249 53678 10.0.0.159 22
CHARSET=UTF-8
SHELL=/bin/sh
MM_CHARSET=UTF-8
LC_ALL=en_US.UTF-8
BLOCKSIZE=K
fred@Ghost14-selfbuilt-rpi4B-nginx-tst1:~ $


~~~~~~~~~~~~~~~~~
Above is an example of printing out the values of the environment. How you copy from an SSH session and paste here is up to your knowledge of your system and software.

SirDice, I hope this wordy example is not too large, and that meets your wonderful standard for great answers.

I used JuiceSSH in a Chromebook to SSH connect with my Raspberry Pi 4B running FreeBSD 14.x aarch64
https://juicessh.com/ Here are details about Juice SSH.
Use SSH connection from another FreeBSD system or SSH from your favorite device (Like JuiceSSH on a chromebook) to make a SSH connection to your FreeBSD system under test.


# important lines to read and understand from the 'env' command

SSH_CLIENT=173.11.5.249 53678 22
SSH_TTY=/dev/pts/0
SSH_CONNECTION=173.11.5.249 53678 10.0.0.159 22

man ssh
man sshd

# files to examine and edit
/etc/ssh/ssh_config
/etc/ssh/sshd_config
/etc/rc.conf



I hope this helps you to get connected via SSH tools using Freebsd or JuiceSSH to your target computer system
Fred Finster https://ghostbsd-arm64.blogspot.com/2023/11/xfce-mouse-slim-problems-i-have-solved.html Some more details of using SSH daemon and a SSH connection. Have to edit /etc/rc.conf file on the target system.

You share back, what changes finally make SSH work for you. Read the FreeBSD handbook about setting up SSH and port forwarding on your router to your target system. Or just connect your laptop or chromebook to the same ethernet cabled network.
 
Use Google-Fu searching with 'FreeBSD X11 port forwarding'

Sir Dice older answer is in this forum post
 
ssh -vv -X <ip>, and check the debug output log. The remote host needs to have "xauth" package installed and allow ssh X11Forwarding enabled. Install xclock package and run "xclock" to test X11 forwarding.
 
# important lines to read and understand from the 'env' command
No, when X forwarding is enabled you should see a DISPLAY variable:
Code:
DISPLAY=localhost:10.0
If you don't get the DISPLAY variable Xforwarding isn't working as it's Xforwarding that sets this.
 
In my .ssh/config for each host I want to be able to do this:
ForwardX11Trusted "yes"
ForwardX11 "yes"
ObscureKeystrokeTiming "no"

echo $DISPLAY as said is a really quick way to check.
On the machine you are sshing from, you may want to try doing "xhost +"; not sure if it's needed, it's definitely a security hole, but if control the whole network it helps to debug.

adding extra "-v" for debugging information is also helpful.
I also found that I needed to be logged in on the remote Linux machine I think there are ways around this but it's not really a hassle for me.
 
No, when X forwarding is enabled you should see a DISPLAY variable:
Code:
DISPLAY=localhost:10.0
If you don't get the DISPLAY variable Xforwarding isn't working as it's Xforwarding that sets this.
DEar sirdice :
fellow wb7odyfred 's guide ,
i have ssh -X 192.168.200.2 from my gnome-terminal . then i can open xclock and other program. but no gnome-session. i pasted output of ENV command in below . please check it. thanks.

env
SSH_CLIENT=192.168.200.3 28823 22
LOGNAME=game
PAGER=less
LANG=C.UTF-8
MAIL=/var/mail/game
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/game/bin
EDITOR=vi
ENV=/home/game/.shrc
DISPLAY=localhost:10.0
PWD=/home/game
TERM=xterm-256color
SSH_TTY=/dev/pts/0
HOME=/home/game
USER=game
SSH_CONNECTION=192.168.200.3 28823 192.168.200.2 22
SHELL=/bin/sh
MM_CHARSET=UTF-8
BLOCKSIZE=K

game@work1:~ $ echo $DISPLAY
localhost:10.0

2. when i login VT shell, then ssh -X 192.168.200.2 , EVN output in below .no DISPLAY
game@work1:~ $ echo $DISPLAY
nothing .

and that time ,i can't run xclock. and gnome-session.

my soul was how to run a gnome-session in VT shell ? thanks.
 
In my .ssh/config for each host I want to be able to do this:
ForwardX11Trusted "yes"
ForwardX11 "yes"
ObscureKeystrokeTiming "no"

echo $DISPLAY as said is a really quick way to check.
On the machine you are sshing from, you may want to try doing "xhost +"; not sure if it's needed, it's definitely a security hole, but if control the whole network it helps to debug.

adding extra "-v" for debugging information is also helpful.
I also found that I needed to be logged in on the remote Linux machine I think there are ways around this but it's not really a hassle for me.
DEar mer:
thanks for your help. now,
1. when i ssh -X 192.168.200.2 use gnome-terminal in GNOME GUI. in the terminal echo $DISPLAY was "localhost:10.0", i can run xclock. but gnome-session wasn't .

2. when i login my machine VT shell, in the vt shell ,i ssh -X 192.168.200.2 login the remote server. echo $DISPLAY , i got nothing. and in this time , i run xclock will get a error "can't open display "

my soul was : open the remote server gnome-session from my client VT shell.

server and client all have GNOME-GUI .and system was freebsd14.2 . thanks.
 
If you wish to access your Gnome desktop remotely maybe you want to have a look at xrdp or vnc (e.g. tigervnc or x11vnc).
 
You could access a VNC session through a SSH tunnel using port forwarding. I am not aware that you can access a complete Gnome desktop just using ssh xforwarding. So fare I have only used ssh xforwarding to display windows of single programs remotely.
 
You could access a VNC session through a SSH tunnel using port forwarding. I am not aware that you can access a complete Gnome desktop just using ssh xforwarding. So fare I have only used ssh xforwarding to display windows of single programs remotely.4

DEar markus:
how to access a vnc session through a ssh tunnel using port forwarding ?
1. i need to build a vnc server in my remote server first , right ?
2. then i will configure ssh port forwarding .
3. vnc xxxxhost portnumber ?
right ? thanks.
 
This works for me:

Remote machine:

Install the VNC Server package.

Code:
# pkg install tigervnc-server


Start the VNC Server. Please note, in my example I am starting a KDE Plasma session. You will have to find out the correct command for your Gnome session. Adjust the geometry as needed.

Code:
$ vncserver -xstartup /usr/local/bin/startplasma-x11 -geometry 800x600 :1

Client machine:

Install the VNC viewer package.

Code:
# pkg install tigervnc-viewer

Create the SSH portforwarding. Replace the user name and IP address with the ones of your remote machine.

Code:
$ ssh -L 5901:localhost:5901 markus@172.32.12.203

Connect to your VNC session.

Code:
$ vncviewer localhost:5901
 
  • Like
Reactions: drr
This works for me:

Remote machine:

Install the VNC Server package.

Code:
# pkg install tigervnc-server


Start the VNC Server. Please note, in my example I am starting a KDE Plasma session. You will have to find out the correct command for your Gnome session. Adjust the geometry as needed.

Code:
$ vncserver -xstartup /usr/local/bin/startplasma-x11 -geometry 800x600 :1

Client machine:

Install the VNC viewer package.

Code:
# pkg install tigervnc-viewer

Create the SSH portforwarding. Replace the user name and IP address with the ones of your remote machine.

Code:
$ ssh -L 5901:localhost:5901 markus@172.32.12.203

Connect to your VNC session.

Code:
$ vncviewer localhost:5901
thanks. maybe ssh x11forwarding was old , so , no much more people use it. thanks.
 
thanks. maybe ssh x11forwarding was old , so , no much more people use it. thanks.

I think X11 forwarding in ssh is more suitable for running a standalone X11 application remotely. Running a whole desktop session, gnome in your case, probably needs starting several other services, such as dbus, session management, etc. and remote desktop like vnc and rdp maybe the preferred solution, as the desktop session is still run on your host and you access its screen remotely. However, if you only intend to run a specific application from your gnome desktop, e.g. the nautilus file manager, that may very well be possible with X11 forwarding in ssh.
 
I think X11 forwarding in ssh is more suitable for running a standalone X11 application remotely. Running a whole desktop session, gnome in your case, probably needs starting several other services, such as dbus, session management, etc. and remote desktop like vnc and rdp maybe the preferred solution, as the desktop session is still run on your host and you access its screen remotely. However, if you only intend to run a specific application from your gnome desktop, e.g. the nautilus file manager, that may very well be possible with X11 forwarding in ssh.
I totally agree with you. But since the OP was not satisfied with being able to run one application, in his example xclock, remotely, I thought he might want to access the complete Gnome session remotely. It is probably a comprehension problem between two non-native English speakers.

Maybe @fff2024g can try to explain in other words, what he really wants to achieve.
 
  • Thanks
Reactions: drr
I think X11 forwarding in ssh is more suitable for running a standalone X11 application remotely. Running a whole desktop session, gnome in your case, probably needs starting several other services, such as dbus, session management, etc. and remote desktop like vnc and rdp maybe the preferred solution, as the desktop session is still run on your host and you access its screen remotely. However, if you only intend to run a specific application from your gnome desktop, e.g. the nautilus file manager, that may very well be possible with X11 forwarding in ssh.
DEar drr:
thanks for your reply. when i run a chrome , or thunderbird ,etc from remote server through ssh x11forwarding in internet. that was so slowly. not a good solutions. thanks.
 
I totally agree with you. But since the OP was not satisfied with being able to run one application, in his example xclock, remotely, I thought he might want to access the complete Gnome session remotely. It is probably a comprehension problem between two non-native English speakers.

Maybe @fff2024g can try to explain in other words, what he really wants to achieve.
thanks. my soul was full control gnome-GUI from remote through ssh in internet. but the speed was so slowly. thanks.
so, i will use wireguard tunnel with vnc to solve this issue. thanks.
 
This kind of reminds me of "Reflection X", a Windows-based program that brought the XDM-based login screen to Windows - via SSH... MobaXterm is another example with that kind of capacity. You do need to configure XDM to allow remote connections (xdmcp.conf, if memory serves me).

I remember being completely lost in troubleshooting, because the design was VERY counter-intuitive - the stuff running on the remote host is the client, while locally it's the server part. Once you get used to that, it's easier to know what to put into the .conf files to allow the remote UNIX desktop to appear on your local screen.
 
  • Like
Reactions: drr
Reflection X ... I think I used that in the late 90s :). Now that you mention it, I remember how I also had problems understanding the client server concept of the X server in the beginning :).
 
  • Like
Reactions: drr
Not exactly FreeBSD to FreeBSD, but this is the forum post that came up during my research of Linux -> FreeBSD, so leaving what I found here for posterity.

To enable Linux (from where you ssh, and where you want the X windows to appear, aka X11 server) to FreeBSD (to where you ssh into and run X programs, aka X11 client) X Forwarding, there was some surprising turn needed that was not mentioned in other forums/sources in one place. So:

- pkg install xauth (if was not yet present)
- You need to edit the /etc/ssh/sshd_config, and enable the X11Forwarding (either globally or for the given user using the Match User section, at the end there is an example). service sshd reload. So far standard.
- Do _not_ change X11UseLocalhost to 'no'. The standard 'yes' is good there (means that the ssh forwarding will bind to localhost, and not to wildcard. Which is good, the x-client apps will try to connect via localhost, as instructed by the properly set DISPLAY variable)

At this point, if you have an old-ish Linux, things should work (but read below). As a checkpoint, after ssh -X-ing to your FreeBSD host, you should verify:
- `env` prints DISPLAY=localhost:10.0 or similar (11.0 etc)
- `netstat -an` prints an ipv4 listener on 127.0.0.1:6010 (or 6011 etc)

If you try xclock, and it works, all good. If you get a cryptic message `connect /tmp/.X11-unix/X0: No such file or directory`, as it turns out, this is not originating from the host-ran x-client program, but rather from ssh itself as a debug info (if you started ssh with -vv, you would also get messages indicating that ssh detected the attempt that FreeBSD client wants to connect through the forwarded port).

So, that cryptic path, which is a Unix Domain Socket path, is on your X-server machine (here, Linux). If you read up, indeed that is where X should be listening. So what gives that ssh client has trouble connecting to it?

As https://unix.stackexchange.com/a/57143 reveals, there's a thing called "abstract namespace" UDS, which https://man7.org/linux/man-pages/man7/unix.7.html reveals to be a Linux-only thing. As https://unix.stackexchange.com/a/735951 reveals, ssh doesn't support connecting to the abstract namespace'd UDS, and also provides a nice workaround: start socat on your Linux to forward the non-abstract UDS path to the abstract UDS path.

So, on a modern Linux, for this to work (maybe probably even from modern Linux -> Linux too, not just FreeBSD):
- fire up socat as hinted in that SO post: socat UNIX-LISTEN:/tmp/.X11-unix/X${DISPLAY#*:},fork,reuseaddr ABSTRACT-CONNECT:/tmp/.X11-unix/X${DISPLAY#*:}
- and then do the ssh -X. 😅
 
Back
Top