I'm having a problem accessing X apps from FC2 to Debian Etch using ssh. I can
ssh in to Etch ok, and can display stuff like lsmod on FC2's CLI, but if I
try to run Gedit, Kwrite, or any other Xapp it's a no go. I tried
in /etc/ssh_config on Etch uncommenting the line.
ForwardX11Trusted yes

This though hasn't resolved the problem.

Any suggestions?

Nigel.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nigel Henry <cave.dnb@tiscali.fr> wrote:

> I'm having a problem accessing X apps from FC2 to Debian Etch using
> ssh. I can ssh in to Etch ok, and can display stuff like lsmod on
> FC2's CLI, but if I try to run Gedit, Kwrite, or any other Xapp it's
> a no go. I tried in /etc/ssh_config on Etch uncommenting the line.
> ForwardX11Trusted yes
>
> This though hasn't resolved the problem.
>
> Any suggestions?

I think you need to tinker with /etc/ssh/sshd_config, especially the
option X11Forwarding. IIUC you need to alter ssh_config on the client
side, not server side.

If this doesn't work please also provide error messages from when you
try to start X apps, ssh_config on client and sshd_config on server
side.

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Mar 28, 2007 at 09:29:46PM +0200, Nigel Henry wrote:
> I'm having a problem accessing X apps from FC2 to Debian Etch using ssh. I can
> ssh in to Etch ok, and can display stuff like lsmod on FC2's CLI, but if I
> try to run Gedit, Kwrite, or any other Xapp it's a no go. I tried
> in /etc/ssh_config on Etch uncommenting the line.
> ForwardX11Trusted yes
>
> This though hasn't resolved the problem.
>
Umm, what error messages are you getting? Does anything show up in the
logs on the server?

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGCt961snWssAFC08RAtnnAJ96NJBbZolc2Yjz7wiOap dFN3+GUQCcDubM
wERgSCwZXmFh5C/mqKuLmqc=
=kH1K
-----END PGP SIGNATURE-----

On Wednesday 28 March 2007 21:48, Andrei Popescu wrote:
> Nigel Henry <cave.dnb@tiscali.fr> wrote:
> > I'm having a problem accessing X apps from FC2 to Debian Etch using
> > ssh. I can ssh in to Etch ok, and can display stuff like lsmod on
> > FC2's CLI, but if I try to run Gedit, Kwrite, or any other Xapp it's
> > a no go. I tried in /etc/ssh_config on Etch uncommenting the line.
> > ForwardX11Trusted yes
> >
> > This though hasn't resolved the problem.
> >
> > Any suggestions?
>
> I think you need to tinker with /etc/ssh/sshd_config, especially the
> option X11Forwarding. IIUC you need to alter ssh_config on the client
> side, not server side.
>
> If this doesn't work please also provide error messages from when you
> try to start X apps, ssh_config on client and sshd_config on server
> side.
>
> Regards,
> Andrei

I have to admit that I am confused when discussing clients, and servers with
working with SSH.

Anyway here goes. I can ssh from Etch (192.168.0.8) to either FC1
(192.168.0.228), or FC2 (192.168.0.230), and get stuff from Etch displayed on
the CLI on FC1, and 2, and also get X apps, gedit for example displayed.

The other way from FC1, or FC2, ssh'ing to debian, I can can ssh into Debian
(192.168.0.8), and view anything I want on the CLI, but have problems with
opening X apps.

In /etc/ssh/ssh_config I have tried changing "ForwardX11" no to yes, and have
also tried changing "ForwardX11Trusted" from no to yes, and obviously
uncommenting them, but still no success.

These are the sort of complaints I get when trying to access Etch from FC1, or
FC2. SSH'ing into Etch isn't the problem. The CLI stuff works ok, it's just
the X apps that complain. See below.

Last login: Thu Mar 29 22:23:34 2007 from 192.168.0.228
djmons@debian:~$ gedit
cannot open display: (null)
Run 'gedit --' to see a full list of available command line options.
djmons@debian:~$ kwrite
kwrite: cannot connect to X server
djmons@debian:~$ cheesetracker
cheesetracker: cannot connect to X server
djmons@debian:~$

This is all I get, and doesn't say anything.

So this is the way it stands at the moment. I can ssh from Etch into FC1, or
FC2, access the CLI on Etch, and also open Xapps.

Going the other way from FC1, or FC2 to Etch. I can access the CLI on Etch ok,
but cannot access any Xapps.

All a bit puzzling.

Nigel.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, 2007-03-30 at 01:14 +0200, Nigel Henry wrote:
> I have to admit that I am confused when discussing clients, and servers with
> working with SSH.
>
> Anyway here goes. I can ssh from Etch (192.168.0.8) to either FC1
> (192.168.0.228), or FC2 (192.168.0.230), and get stuff from Etch displayed on
> the CLI on FC1, and 2, and also get X apps, gedit for example displayed.
>
> The other way from FC1, or FC2, ssh'ing to debian, I can can ssh into Debian
> (192.168.0.8), and view anything I want on the CLI, but have problems with
> opening X apps.
>
> In /etc/ssh/ssh_config I have tried changing "ForwardX11" no to yes, and have
> also tried changing "ForwardX11Trusted" from no to yes, and obviously
> uncommenting them, but still no success.
>
> These are the sort of complaints I get when trying to access Etch from FC1, or
> FC2. SSH'ing into Etch isn't the problem. The CLI stuff works ok, it's just
> the X apps that complain. See below.
>
> Last login: Thu Mar 29 22:23:34 2007 from 192.168.0.228
> djmons@debian:~$ gedit
> cannot open display: (null)
> Run 'gedit --' to see a full list of available command line options.
> djmons@debian:~$ kwrite
> kwrite: cannot connect to X server
> djmons@debian:~$ cheesetracker
> cheesetracker: cannot connect to X server
> djmons@debian:~$
>
> This is all I get, and doesn't say anything.
>
> So this is the way it stands at the moment. I can ssh from Etch into FC1, or
> FC2, access the CLI on Etch, and also open Xapps.
>
> Going the other way from FC1, or FC2 to Etch. I can access the CLI on Etch ok,
> but cannot access any Xapps.
>
> All a bit puzzling.

Okay. You local GUI is the X-Server. It runs the display and all the GUI
functions associated with it.

When you execute a GUI application it becomes an X-Server client. It
sends display info to the X-Server. The X-Server Renders it. In this
case there is no remote machine.

Now, let us say, you have your FC2 machine which you are sitting at. It
has the X-Server running the GUI display. Let us call this the local
machine. You have another machine sitting in the Data Center... lets
call this the remote machine. In actuality you consider this to be the
server, as all the *work* gets done there. Well, it is and it isn't.
*IF* you want to display a GUI application on your local machine, the
remote machine is then a client to your X-Server. This is were most
people get confused. X is opposite of what you regularly think of. The
GUI application started on the "server" is in reality a client to the
X-server or the local GUI Display.

Okay, try this form your FC2 machine:

ssh -X debian

The -X tells ssh to ask for an X forwarded session and sets a remotely
local $DISPLAY, usually with an X offset of 10 or 20, so it look like:

DISPLAY=localhost:10

This is an X forwarded display on the remote machine to send all input
to your local X-Server.

Now right after that:

gedit &

You should now get a gedit window on your local display which is the *X
Server*. Remember gedit is an X-client (remote) to your X-Server
(local).

Now, remember this. If you want to automagically have this on Debian
machine you sit at and use as an X-Server, you will need to set the
config to carry the "-X" as a default.

On the machine you sit at(the local machine)... the
"/etc/ssh/ssh_config" will have to have a line like this:

ForwardX11 yes

On the machine you ssh into (the remote machine), you will need to make
sure an entry in "/etc/ssh/sshd_config" has entries that look like this:

X11Forwarding yes
X11DisplayOffset 10

after changing the sshd_config, you will have to restart the openssh
server using "/etc/init.d/ssh restart"

It they both do not conform to these settings, you will not be able to
get displays working the way you want.

Remember please do not confuse the two files on the local and remote
machines. They are:

/etc/ssh/ssh_config on the local machine.

/etc/ssh/sshd_config on the remote machine.

If you still have issues, please respond back to this e-mail.
--
greg, greg@gregfolkert.net

I don't mow my lawn anymore. I just intimidate it into not growing.
Though it is quite hard to intimidate grass, it has been around a long time
and has quite an attitude about it.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Friday 30 March 2007 03:57, Greg Folkert wrote:
> On Fri, 2007-03-30 at 01:14 +0200, Nigel Henry wrote:
> > I have to admit that I am confused when discussing clients, and servers
> > with working with SSH.
<Greg>
> Okay. You local GUI is the X-Server. It runs the display and all the GUI
> functions associated with it.
>
> When you execute a GUI application it becomes an X-Server client. It
> sends display info to the X-Server. The X-Server Renders it. In this
> case there is no remote machine.
>
> Now, let us say, you have your FC2 machine which you are sitting at. It
> has the X-Server running the GUI display. Let us call this the local
> machine. You have another machine sitting in the Data Center... lets
> call this the remote machine. In actuality you consider this to be the
> server, as all the *work* gets done there. Well, it is and it isn't.
> *IF* you want to display a GUI application on your local machine, the
> remote machine is then a client to your X-Server. This is were most
> people get confused. X is opposite of what you regularly think of. The
> GUI application started on the "server" is in reality a client to the
> X-server or the local GUI Display.
>
> Okay, try this form your FC2 machine:
>
> ssh -X debian
>
> The -X tells ssh to ask for an X forwarded session and sets a remotely
> local $DISPLAY, usually with an X offset of 10 or 20, so it look like:
>
> DISPLAY=localhost:10
>
> This is an X forwarded display on the remote machine to send all input
> to your local X-Server.
>
> Now right after that:
>
> gedit &
>
> You should now get a gedit window on your local display which is the *X
> Server*. Remember gedit is an X-client (remote) to your X-Server
> (local).
>
> Now, remember this. If you want to automagically have this on Debian
> machine you sit at and use as an X-Server, you will need to set the
> config to carry the "-X" as a default.
>
> On the machine you sit at(the local machine)... the
> "/etc/ssh/ssh_config" will have to have a line like this:
>
> ForwardX11 yes
>
> On the machine you ssh into (the remote machine), you will need to make
> sure an entry in "/etc/ssh/sshd_config" has entries that look like this:
>
> X11Forwarding yes
> X11DisplayOffset 10
>
> after changing the sshd_config, you will have to restart the openssh
> server using "/etc/init.d/ssh restart"
>
> It they both do not conform to these settings, you will not be able to
> get displays working the way you want.
>
> Remember please do not confuse the two files on the local and remote
> machines. They are:
>
> /etc/ssh/ssh_config on the local machine.
>
> /etc/ssh/sshd_config on the remote machine.
>
> If you still have issues, please respond back to this e-mail.
> --
> greg, greg@gregfolkert.net

Hi Greg. That was an easy fix. Thanks for the very good explanation.
Everything is crystal clear now. While I was at it I changed the "Allow Root
Login" line from yes to no, as I'd seen on a previous thread that this was
not a good idea, and "yes" seems to be the default. I can always su to root
once logged in, if I need to do anything as root.

Many thanks.

Nigel.
>
> I don't mow my lawn anymore. I just intimidate it into not growing.
> Though it is quite hard to intimidate grass, it has been around a long time
> and has quite an attitude about it.

Goats are good to keep the grass mowed, and if you have the one with the
correct bits underneath it, you can turn your grass into milk, and cheese.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, Mar 30, 2007 at 05:17:04PM +0200, Nigel Henry wrote:
>
> Hi Greg. That was an easy fix. Thanks for the very good explanation.
> Everything is crystal clear now. While I was at it I changed the "Allow Root
> Login" line from yes to no, as I'd seen on a previous thread that this was
> not a good idea, and "yes" seems to be the default. I can always su to root
> once logged in, if I need to do anything as root.
>
Also, if you know for sure that you will always be accessing the machine
from the same few hosts, you might want to consider disabling password
logins altogether and only allowing public key logins. It is
significantly more secure, since it is impossible for a dictionary
attach to succeed against a server which only allows public key login.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGDSrv1snWssAFC08RAtutAKCGmv3ArzXfnJ0+VxANUi Qwd5FNQQCggN/D
Zh68wsLQN4h6KEHYiSv6e+4=
=xIpQ
-----END PGP SIGNATURE-----

On Fri, 30 Mar 2007 11:21:19 -0400
Roberto C. Sánchez <roberto@connexer.com> wrote:

> On Fri, Mar 30, 2007 at 05:17:04PM +0200, Nigel Henry wrote:
> >
> > Hi Greg. That was an easy fix. Thanks for the very good explanation.
> > Everything is crystal clear now. While I was at it I changed the "AllowRoot
> > Login" line from yes to no, as I'd seen on a previous thread that this was
> > not a good idea, and "yes" seems to be the default. I can always su to root
> > once logged in, if I need to do anything as root.
> >
> Also, if you know for sure that you will always be accessing the machine
> from the same few hosts, you might want to consider disabling password
> logins altogether and only allowing public key logins. It is
> significantly more secure, since it is impossible for a dictionary
> attach to succeed against a server which only allows public key login.

You can do this even with unlimited hosts, if you carry your key
(encrypted, of course) on a USB flash drive.

Celejar