LinuxQuestions.org - [SOLVED] Is X forwarding possible on a host machine if it is already running an x session?

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - Is X forwarding possible on a host machine if it is already running an x session? (https://www.linuxquestions.org/questions/linux-software-2/is-x-forwarding-possible-on-a-host-machine-if-it-is-already-running-an-x-session-4175643703/)

Is X forwarding possible on a host machine if it is already running an x session?

So I am running Deb 9.6 and XFCE and I often ssh into it from my MacBook, because the battery on it isn’t that great so I leave it plugged in , in another room. I would like to try x forwarding. I tried looking at solutions such as editing my sshd confit but I still get an error. My question is can I x forward if there’s an instance of an X session already running? If not, what steps should I take?

Your post is a bit funny: Can I do this, if not what should I take....
Yes, you can do that, but without knowing your config hard to say anything. So please post relevant info like how did you edit your sshd config, what error did you get ....

Quote:

Originally Posted by Coop_012 (Post 5933651)

My question is can I x forward if there’s an instance of an X session already running?

The existing instance of X is irrelevant.
Are you trying to see your desktop, or see a particular app?
If you want to see a desktop, you need something like VNC. But that's probably pointless.

If you can ssh into the remote machine, try a graphic command like these. The final & will run it in the background so you get your prompt back. If X is being forwarded, it'll run remotely but display on the local desktop (though any browser will be sluggish).

Code:

firefox &

display ~/Pictures/someimg.jpg &

Another thing you can do instead, that might be better, is to install sshfs (or fuse-sshfs) and try this command. Substitute your actual remote machine name for "machine". "Videos" can be any directory on the remote machine. The local "remv" directory can be anything you want.

Code:

mkdir ~/remv

sshfs machine:Videos ~/remv

Now you can watch videos stored on the remote machine. In a local shell (not via ssh), run the command

Code:

mplayer ~/remv/some-movie.mp4

Enjoy!

Heres my config, or at least the section I assume you're interested in.

Code:

#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

X11Forwarding yes

#X11DisplayOffset 10

#X11UseLocalhost yes

#PermitTTY yes

PrintMotd no

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#UsePrivilegeSeparation sandbox

#PermitUserEnvironment no

#Compression delayed

And when I try to run an X app, I get this, same if I use sudo.

Code:

coop@coop:~$ xclock

Error: Can't open display:

Log into your remote machine with ssh. In the remote shell, enter this command:

Code:

echo $DISPLAY

If X is not forwarded, it'll be blank. If X is forwarded, you should see something like this:

Code:

localhost:11.0

Thanks ken, I just tried it, and it came back blank.

I assume the configuration file you posted above is the server i.e. etc/ssh/sshd_config. You still need to allow forwarding by setting a similar setting in the system wide configuration /etc/ssh/ssh_config, users ~/.ssh/config file or via the command line option -X.

Did you restart the ssh server after making changes to the sshd_config file.

Just to lend a helping hand...

Thanks I’ll try that! Do I have to uncomment those lines?

Well, the client setting is configured on the client computer i.e. your Mac and what I posted is for linux but should be similar.

I would try the -X command line option first.

ssh -X username@server_name

Code:

coop@coop:~$ echo $DISPLAY



coop@coop:~$

heres client /etc/ssh/ssh_config

Code:

coopmba:~ cooper$ cat /etc/ssh/ssh_config 

#        $OpenBSD: ssh_config,v 1.33 2017/05/07 23:12:57 djm Exp $



# This is the ssh client system-wide configuration file.  See

# ssh_config(5) for more information.  This file provides defaults for

# users, and the values can be changed in per-user configuration files

# or on the command line.



# Configuration data is parsed as follows:

#  1. command line options

#  2. user-specific file

#  3. system-wide file

# Any configuration value is only changed the first time it is set.

# Thus, host-specific definitions should be at the beginning of the

# configuration file, and defaults at the end.



# Site-wide defaults for some commonly used options.  For a comprehensive

# list of available options, their meanings and defaults, please see the

# ssh_config(5) man page.



# Host *

    ForwardAgent yes

    ForwardX11 yes

#  PasswordAuthentication yes

#  HostbasedAuthentication no

#  GSSAPIAuthentication no

#  GSSAPIDelegateCredentials no

#  BatchMode no

#  CheckHostIP yes

#  AddressFamily any

#  ConnectTimeout 0

#  StrictHostKeyChecking ask

#  IdentityFile ~/.ssh/id_rsa

#  IdentityFile ~/.ssh/id_dsa

#  IdentityFile ~/.ssh/id_ecdsa

#  IdentityFile ~/.ssh/id_ed25519

#  Port 22

#  Protocol 2

#  Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc

#  MACs hmac-md5,hmac-sha1,umac-64@openssh.com

#  EscapeChar ~

#  Tunnel no

#  TunnelDevice any:any

#  PermitLocalCommand no

#  VisualHostKey no

#  ProxyCommand ssh -q -W %h:%p gateway.example.com

#  RekeyLimit 1G 1h



Host *

        SendEnv LANG LC_*

coopmba:~ cooper$

heres server (/etc/ssh/sshd_config

Code:

coop@coop:~$ cat /etc/ssh/sshd_config 

#        $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $



# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.



# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin



# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options override the

# default value.



#Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::



#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key



# Ciphers and keying

#RekeyLimit default none



# Logging

#SyslogFacility AUTH

#LogLevel INFO



# Authentication:



#LoginGraceTime 2m

#PermitRootLogin prohibit-password

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10



#PubkeyAuthentication yes



# Expect .ssh/authorized_keys2 to be disregarded by default in future.

#AuthorizedKeysFile        .ssh/authorized_keys .ssh/authorized_keys2



#AuthorizedPrincipalsFile none



#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody



# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes



# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no



# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication no



# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no



# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

#GSSAPIStrictAcceptorCheck yes

#GSSAPIKeyExchange no



# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes



AllowAgentForwarding yes

AllowTcpForwarding yes

#GatewayPorts no

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

#PermitTTY yes

PrintMotd no

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#UsePrivilegeSeparation sandbox

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS no

#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none



# no default banner path

#Banner none



# Allow client to pass locale environment variables

AcceptEnv LANG LC_*



# override default of no subsystems

Subsystem        sftp        /usr/lib/openssh/sftp-server



# Example of overriding settings on a per-user basis

#Match User anoncvs

#        X11Forwarding no

#        AllowTcpForwarding no

#        PermitTTY no

#        ForceCommand cvs server

coop@coop:~$

Quote:

Originally Posted by Coop_012 (Post 5933836)

heres client /etc/ssh/ssh_config
...
heres server (/etc/ssh/sshd_config

"Client" and "server" get confusing.
Your remote machine is the ssh server, running a daemon, but is the X window client.
Your local machine is the ssh client but is the X window server.

The sshd_config file you showed seems to have X11Forwarding set correctly. It should be on the remote machine.
And ssh_config has ForwardX11 set correctly. It should be on the local machine.

If you edited sshd_config on the remote machine but haven't restarted the daemon, you need to do that. If your system uses systemctl, this command should do that (on the remote machine):

Code:

sudo systemctl restart sshd.service

Ah yes I flipped them thanks for the clarification. I'll amend it and report back.

okay so I've mirrored both the ssh and sshd configs on both systems to be safe. I also have restarted the daemons on both systems, yet I still get

Code:

coop@coop:~$ xclock

Error: Can't open display:

Code:

coop@coop:~$ echo $DISPLAY



coop@coop:~$

One more thing you can do is use -v to verify that you see:
debug1: Requesting X11 forwarding with authentication spoofing.
If you don't see that, add the -X switch.
If you still don't see it, your remote machine isn't requesting X.

Then verify you see either:
X11 forwarding request failed on channel 0
or (you'll have to use -vv to see this):
debug2: X11 forwarding request accepted on channel 0

If the request failed, then the remote machine has an issue.
If the request is accepted and you still can't use X, that's odd.

how did you get that shell (where you executed xclock)?