# How to do a X11 Forward (Linux/FreeBSD) ?



## honeybear (Nov 17, 2022)

Hello,

A raspberry pi and here it goes, it fails to X11 forward:

```
$  ssh -Y -C -p 22 darkstar@localhost
Password for darkstar@:
Last login: Thu Nov 17 10:34:00 2022 from 192.168.1.2
/usr/local/bin/xauth:  file /home/darkstar/.Xauthority does not exist
/usr/local/bin/xauth: (stdin):1:  bad display name "unix:10.0" in "remove" command
/usr/local/bin/xauth: (stdin):2:  bad display name "unix:10.0" in "add" command
You can `set autologout = 30' to have tcsh log you off automatically
if you leave the shell idle for more than 30 minutes.
darkstar@:~ $ xterm
X11 connection rejected because of wrong authentication.
xterm: Xt error: Can't open display: localhost:10.0
darkstar@:~ $
```
My monitor is a linux raspberry pi
My server is a SSH /FreeBSD machine with 22 sshd running and healthy.
Maybe sshd config ?


```
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 22916
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed
debug2: channel 1: write failed
debug2: channel 1: close_write
```


----------



## SirDice (Nov 17, 2022)

This is an xauth(1) issue, has nothing to do with your SSH configuration (client or server).


----------



## Alain De Vos (Nov 17, 2022)

Check the package "xauth" is installed on the both pc's.


----------



## honeybear (Nov 17, 2022)

```
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 22916
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug3: send packet: type 91
debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed
debug2: channel 1: write failed
debug2: channel 1: close_write
```


what is the linux ssh protocol ? 

what is the freebsd ssh protocol?

how to ask linux to use the one of freebsd ?


----------



## honeybear (Nov 17, 2022)

```
debug1: Connection established.
debug1: SELinux support disabled
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/darkstar/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u7
```


----------



## Alain De Vos (Nov 17, 2022)

There is no linux-ssh-protocol & there is no freebsd-ssh-protocol as far as i know, there is only aan ssh-protocol.
Does it work without "-Y" ?


----------



## chrbr (Nov 17, 2022)

Dear honeybear,
may be https://forums.freebsd.org/threads/...-in-a-jail-using-iocage-and-ssh-jailme.53362/ is of some help. One part of the howtodo is about X11 forwarding. The main topic is about jail, but it should make no difference if the ip connection is to a jail or an external device.


----------



## SirDice (Nov 17, 2022)

Alain De Vos said:


> There is no linux-ssh-protocol & there is no freebsd-ssh-protocol as far as i know, there is only aan ssh-protocol.


Correct. The entire issue has nothing to do with SSH in any case. 

As I said before, it's an X Window authorization issue. If you don't have an active X session running on the host you're connecting to, just remove that ~/.Xauthority file.


----------



## tux2bsd (Nov 17, 2022)

SirDice is trying too hard to be the rtfm guy... 

Alain De Vos gave helpful advice.


----------



## honeybear (Nov 18, 2022)

tux2bsd said:


> SirDice is trying too hard to be the rtfm guy...
> 
> Alain De Vos gave helpful advice.


useless info ^  

The PI raspbian is the machine to display the xterm.


----------



## honeybear (Nov 18, 2022)

Alain De Vos said:


> There is no linux-ssh-protocol & there is no freebsd-ssh-protocol as far as i know, there is only aan ssh-protocol.
> Does it work without "-Y" ?



Hallo Alain,

The -Y does not work.

If I recall well, it was working under netbsd, but maybe the SSH protocoll of Linux isnt available into the sshd server?
Only for BSD?

copying .xauthority didnt help either.
ssh keygen didnt help either.

The links does not help 








						How To: Execute Firefox in a jail using iocage and ssh/jailme
					

Motivations  The main reason to put a browser in a jail is quite simple : browsers cannot be trusted. They are too much exposed. Executing a browser inside a jail is a way to be sure that the damages induced by a malicious software are contained (as much as possible). I decided to write this...




					forums.freebsd.org


----------



## SirDice (Nov 18, 2022)

honeybear said:


> If I recall well, it was working under netbsd, but maybe the SSH protocol of Linux isn't available into the sshd server?


You're still too focused on SSH, that's not the problem. There is NO difference between Linux and BSD with regards to the SSH protocol. There is only one SSH protocol.

Just `rm ~/.Xauthority` and login again.


----------



## honeybear (Nov 18, 2022)

SirDice said:


> You're still too focused on SSH, that's not the problem. There is NO difference between Linux and BSD with regards to the SSH protocol. There is only one SSH protocol.
> 
> Just `rm ~/.Xauthority` and login again.


ok, rm done, 


please give me a sshd_config that would or should work. If you likely tried, please can you give me a working sshd_config file config ?


----------



## SirDice (Nov 18, 2022)

honeybear said:


> please give me a sshd_config that would or should work.


Works fine with the default configuration, X forwarding is enabled by default. Again, you are still focusing on SSH, that's not where the issue is!

Your biggest problem is that you're trying to connect to yourself (localhost) and that session has already been authorized. Why are you connecting to the loopback address to 'remotely' start an application when you can just start that application in your current X session?

Looking a little closer, you also appear to be logging in with a different username. You have an active X session as "userA" and are now trying to open an application as "userB". That's not allowed. If userB could simply start an application in userA's session that would be a major security risk. Now, you could ignore all that and run `xhost +`, but I really, really recommend against doing that.


----------



## tux2bsd (Nov 18, 2022)

honeybear said:


> maybe the SSH protocoll of Linux isnt available into the sshd server


Inexperienced user ^

Like SirDice has said, it makes no sense that you are attempting this via localhost.   Unless you're doing something complicated like running two X servers but if that were the case you wouldn't be asking, you'd know what you were doing.


----------



## tux2bsd (Nov 18, 2022)

The most basic for you is:

```
#can you actually ssh in the first place? Try it:
user@pi$ ssh user@freebsd-server

#if that works then:

#this is in a terminal in your desktop environment on your pi
user@pi$ ssh -X user@freebsd-server xterm
```

The "useless info" is something you might need to check on again.


----------



## honeybear (Nov 29, 2022)

I reinstalled freebsd 13 i386.

It works out of the box with SSH - X -Y 

!!! 
thank you 

SOLVED


----------



## sko (Nov 29, 2022)

honeybear said:


> I reinstalled freebsd 13 i386.



13.0 has been EOL for almost 3 months now (31. August 2022). Also why are you using the i386 build? I doubt you are using such an ancient machine, otherwise running it as a server, let alone as an X11 server won't make any sense...



> It works out of the box with SSH - X -Y


you don't need -X when already specifying -Y; see ssh(1)


----------



## honeybear (Dec 2, 2022)

sko said:


> 13.0 has been EOL for almost 3 months now (31. August 2022). Also why are you using the i386 build? I doubt you are using such an ancient machine, otherwise running it as a server, let alone as an X11 server won't make any sense...
> 
> 
> you don't need -X when already specifying -Y; see ssh(1)


i tried i386, it seems to work.

the one that didnt was amd64, but likely it is my install. 
I need to give a try again.


----------



## sko (Dec 2, 2022)

i386 has been moved to Tier 2 support for 13.x, so ports/packages *might* break from time to time and new features aren't necessarily ported in a timely manner (or at all). So there's really no sense in installing i386 unless you really have to deal with such an ancient piece of equipment...

If the amd64 image for 13.1-RELEASE won't boot, maybe try a 12.3-RELEASE image as there were some changes to the bootloader with 13.x that broke booting on older machines. Those should have been ironed out by now, but it's still worth a try...


----------

