To see windows of programs running on other machines, I used to on local_machine type "xhost +" ssh into remote machine and type "export DISPLAY=local_machine_address:0" then I would run the program on the remote machine and receive the window on the local machine I see that it doesn't work anymore with SUSE 9.1. What changed? Ah, and I know about ssh -X, that works, but I don't really need encryption, just speed.
On Tue, 2004-05-25 at 07:43, Silviu Marin-Caea wrote:
To see windows of programs running on other machines, I used to
on local_machine type "xhost +" ssh into remote machine and type "export DISPLAY=local_machine_address:0" then I would run the program on the remote machine and receive the window on the local machine
I see that it doesn't work anymore with SUSE 9.1. What changed?
Ah, and I know about ssh -X, that works, but I don't really need encryption, just speed.
The "-X" does not supply the encryption that's what ssh does. "-X" allows you to see the remote programs on your local display. -- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
Ken Schneider wrote:
The "-X" does not supply the encryption that's what ssh does. "-X" allows you to see the remote programs on your local display.
Actually, it does encrypt. see man ssh, search for X11 and TCP forwarding So, if I don't need encryption, I would use the export & xhost procedure, but why doesn't it work anymore?
The command looks good... Just a minute I'll confirm that it works on my machines... You are right, the command fails from SuSE 9.1 to SuSE 9.1... Jerry P.S. I use ssh -X because it allows me to start a program on a remote machine from an ICON on the desktop.... On Tue, 2004-05-25 at 16:12, Silviu Marin-Caea wrote:
Ken Schneider wrote:
The "-X" does not supply the encryption that's what ssh does. "-X" allows you to see the remote programs on your local display.
Actually, it does encrypt.
see man ssh, search for X11 and TCP forwarding
So, if I don't need encryption, I would use the export & xhost procedure, but why doesn't it work anymore?
On Tuesday 25 May 2004 18.33, Jerome R. Westrick wrote:
The command looks good... Just a minute I'll confirm that it works on my machines...
You are right, the command fails from SuSE 9.1 to SuSE 9.1...
If you guys really want to use this, edit /etc/opt/kde3/share/config/kdm/Xservers and remove the "-nolisten tcp" from the X command lines in there. And yes, that is new for 9.1
On Tue, 2004-05-25 at 12:38, Anders Johansson wrote:
On Tuesday 25 May 2004 18.33, Jerome R. Westrick wrote:
The command looks good... Just a minute I'll confirm that it works on my machines...
You are right, the command fails from SuSE 9.1 to SuSE 9.1...
If you guys really want to use this, edit /etc/opt/kde3/share/config/kdm/Xservers and remove the "-nolisten tcp" from the X command lines in there. And yes, that is new for 9.1
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN? I'm all for security but I still need functionality. I also don't go through life being paranoid. -- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN?
I'm all for security but I still need functionality. I also don't go through life being paranoid.
Ken just because you don't need the added security don't mean you can't use it 8-), And I don't really remember there being a diference in speed between the 2. What I do remember (and use) is that adding -C parameter improves speed on low bandwidth connections. (It compresses the X-Windows data) Jerry
On Tue, 2004-05-25 at 13:52, Jerome R. Westrick wrote:
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN?
I'm all for security but I still need functionality. I also don't go through life being paranoid.
Ken just because you don't need the added security don't mean you can't use it 8-), And I don't really remember there being a diference in speed between the 2. What I do remember (and use) is that adding -C parameter improves speed on low bandwidth connections. (It compresses the X-Windows data)
Jerry
Thats all well and good. I still use ssh -X to connect but need to run "X" programs on my local display. And bandwidth is also not an issue. This particular site houses our backup servers with two full T1 connections going to it. My only point here is if someone else had not brought up the subject I would have been lost as to why I could not display remote "X" apps on my local display using xhost +<hostname> and exporting the display on the other end. And I firmly believe this is much safer than running VNC connections. -- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
On Tuesday 25 May 2004 20.08, Ken Schneider wrote:
My only point here is if someone else had not brought up the subject I would have been lost as to why I could not display remote "X" apps on my local display using xhost +<hostname> and exporting the display on the other end. And I firmly believe this is much safer than running VNC connections.
Based on what, for chrissake? Both are unencrypted, both are susceptible to sniffing
Well you now know how to do it... To each his own... I guess... Jerry On Tue, 2004-05-25 at 20:08, Ken Schneider wrote:
On Tue, 2004-05-25 at 13:52, Jerome R. Westrick wrote:
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN?
I'm all for security but I still need functionality. I also don't go through life being paranoid.
Ken just because you don't need the added security don't mean you can't use it 8-), And I don't really remember there being a diference in speed between the 2. What I do remember (and use) is that adding -C parameter improves speed on low bandwidth connections. (It compresses the X-Windows data)
Jerry
Thats all well and good. I still use ssh -X to connect but need to run "X" programs on my local display. And bandwidth is also not an issue. This particular site houses our backup servers with two full T1 connections going to it. My only point here is if someone else had not brought up the subject I would have been lost as to why I could not display remote "X" apps on my local display using xhost +<hostname> and exporting the display on the other end. And I firmly believe this is much safer than running VNC connections.
-- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
On Tuesday 25 May 2004 19.43, Ken Schneider wrote:
On Tue, 2004-05-25 at 12:38, Anders Johansson wrote:
On Tuesday 25 May 2004 18.33, Jerome R. Westrick wrote:
The command looks good... Just a minute I'll confirm that it works on my machines...
You are right, the command fails from SuSE 9.1 to SuSE 9.1...
If you guys really want to use this, edit /etc/opt/kde3/share/config/kdm/Xservers and remove the "-nolisten tcp" from the X command lines in there. And yes, that is new for 9.1
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN?
SCO? Hmmmmmmm, oh well ssh -X NoMachine's NX VNC ssh command line telnet command line webmin IBM Patrol something else I'm sure I'm forgetting about, all depending on your level of experience and competence, funding, and your need for encryption
On Tue, 2004-05-25 at 13:54, Anders Johansson wrote:
On Tuesday 25 May 2004 19.43, Ken Schneider wrote:
On Tue, 2004-05-25 at 12:38, Anders Johansson wrote:
On Tuesday 25 May 2004 18.33, Jerome R. Westrick wrote:
The command looks good... Just a minute I'll confirm that it works on my machines...
You are right, the command fails from SuSE 9.1 to SuSE 9.1...
If you guys really want to use this, edit /etc/opt/kde3/share/config/kdm/Xservers and remove the "-nolisten tcp" from the X command lines in there. And yes, that is new for 9.1
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN?
SCO? Hmmmmmmm, oh well
Not my choice.
ssh -X
Use it all the time
NoMachine's NX
VNC
Don't consider it as safe as ssh -X
ssh command line
When possible.
telnet command line
Not on your life or mine.
webmin
Sometimes but not as safe as ssh -X and does not offer as much functionality.
IBM Patrol
something else I'm sure I'm forgetting about,
all depending on your level of experience and competence, funding, and your need for encryption
-- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
On Tuesday 25 May 2004 20.12, Ken Schneider wrote:
ssh -X
Use it all the time
NoMachine's NX
VNC
Don't consider it as safe as ssh -X
Forgive me, but I fail to see the problem then. Are you perhaps under the impression that remote X using DISPLAY travels over ssh just because you logged in with ssh -X when you ran it? It doesn't ssh -X will keep working even with -nolisten tcp as an option to X
On Tue, 2004-05-25 at 15:27, Anders Johansson wrote:
On Tuesday 25 May 2004 20.12, Ken Schneider wrote:
ssh -X
Use it all the time
NoMachine's NX
VNC
Don't consider it as safe as ssh -X
Forgive me, but I fail to see the problem then. Are you perhaps under the impression that remote X using DISPLAY travels over ssh just because you logged in with ssh -X when you ran it?
It doesn't
ssh -X will keep working even with -nolisten tcp as an option to X
Further investigation is indeed showing this, but SCO does not play fair (as if we didn't already know that) unless I am missing something and I will not seek help here for anything that requires SCO connections. I would rather report to my boss that another thing is broken in the hopes that we can trash it all together. If it were in my power I would trash the two SCO boxes and load SuSE linux. -- Ken Schneider unix user since 1989 linux user since 1994 SuSE user since 1998 (5.2)
Anders Johansson wrote:
On Tuesday 25 May 2004 20.12, Ken Schneider wrote:
ssh -X
Use it all the time
NoMachine's NX
VNC
Don't consider it as safe as ssh -X
Forgive me, but I fail to see the problem then. Are you perhaps under the impression that remote X using DISPLAY travels over ssh just because you logged in with ssh -X when you ran it?
It doesn't
ssh -X will keep working even with -nolisten tcp as an option to X
"man ssh" gives that impression -------- X11 and TCP forwarding If the ForwardX11 variable is set to “yes” (or see the description of the -X and -x options described later) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is auto matically forwarded to the remote side in such a way that any X11 pro grams started from the shell (or command) will go through the encrypted ======================= channel, and the connection to the real X server will be made from the ========= local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files. ------------------------------------------------------------------------------------------- Then it says ========== -X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file. X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring. Now I'm a bit puzzled. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer Linux Only Shop.
On Wednesday 26 May 2004 01.14, Sid Boyce wrote:
Anders Johansson wrote:
Forgive me, but I fail to see the problem then. Are you perhaps under the impression that remote X using DISPLAY travels over ssh just because you logged in with ssh -X when you ran it?
It doesn't
ssh -X will keep working even with -nolisten tcp as an option to X
"man ssh" gives that impression -------- X11 and TCP forwarding If the ForwardX11 variable is set to “yes” (or see the description of the -X and -x options described later) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is auto matically forwarded to the remote side in such a way that any X11 pro grams started from the shell (or command) will go through the encrypted ======================= channel, and the connection to the real X server will be made from the ========= local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files. --------------------------------------------------------------------------- ---------------- Then it says ========== -X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
Now I'm a bit puzzled.
So am I. I don't understand your question. When you log in with ssh -X, the ssh server will set up what you might call a 'peudo X' server, and set the DISPLAY variable to point to it. This is normally localhost:10.0 or something. When an X application tries to contact the X server through that address, ssh will take care of forwarding the X calls to your locally running X server. If you manually change the DISPLAY variable to point directly to the local machine you will be bypassing ssh and its encryption completely. The security note at the end simply means that any user with sufficient permissions on the remote end will be able to access your local X server through your ssh connection as though he were you, because ssh doesn't protect you on the remote machine, it only protects the packets in transit between the machines.
On Tuesday 25 May 2004 15:14, Sid Boyce wrote:
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
Now I'm a bit puzzled.
Users with the ability to bypass file permissions put you at risk of being owned, and X11 forwarding will not be an issue nor will absense of it be a problem for said hackers. -- _____________________________________ John Andersen
John Andersen wrote:
On Tuesday 25 May 2004 15:14, Sid Boyce wrote:
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
Now I'm a bit puzzled.
Users with the ability to bypass file permissions put you at risk of being owned, and X11 forwarding will not be an issue nor will absense of it be a problem for said hackers.
That makes general sense, it was just that the manpage seemed to highlight this as a problem only associated with ssh -X. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer Linux Only Shop.
On Wed, May 26, 2004 at 12:34:11PM +0100, Sid Boyce wrote:
John Andersen wrote:
Users with the ability to bypass file permissions put you at risk of being owned, and X11 forwarding will not be an issue nor will absense of it be a problem for said hackers.
That makes general sense, it was just that the manpage seemed to highlight this as a problem only associated with ssh -X. Regards Sid.
I think that the point is that users able to bypass (the X authority) file permissions on the remote machine put you at risk of being owned on that machine; however, if you use X forwarding, they can then attack you back through that tunnel and own your local machine as well, since any connection to the 'pseudo-X-server' on the remote machine will be forwarded directly to your local X server, and /your/ X server will treat it as if it were _you_ trying to make the access. HTH... -- David Smith | Tel: +44 (0)1454 462380 Home: +44 (0)1454 616963 STMicroelectronics | Fax: +44 (0)1454 462305 Mobile: +44 (0)7932 642724 1000 Aztec West | TINA: 065 2380 GPG Key: 0xF13192F2 Almondsbury | Work Email: Dave.Smith@st.com BRISTOL, BS32 4SQ | Home Email: David.Smith@ds-electronics.co.uk
On Tuesday 25 May 2004 09:43, Ken Schneider wrote:
On Tue, 2004-05-25 at 12:38, Anders Johansson wrote:
On Tuesday 25 May 2004 18.33, Jerome R. Westrick wrote:
The command looks good... Just a minute I'll confirm that it works on my machines...
You are right, the command fails from SuSE 9.1 to SuSE 9.1...
If you guys really want to use this, edit /etc/opt/kde3/share/config/kdm/Xservers and remove the "-nolisten tcp" from the X command lines in there. And yes, that is new for 9.1
Can you explain another way to remote admin a machine (SCO) 2000 miles away connected through a private WAN?
I'm all for security but I still need functionality. I also don't go through life being paranoid.
You mean sco does not support the -X argument to the ssh command?!! The normal way to do this is to set the sshd in the remote host to "11XForwarding yes" in /etc/ssh/sshd_config and also set the local machine to "ForwardX11 yes" in /etc/ssh/ssh_config. That way you don't even need the -X argument when connecting. Is your SCO setup such that it won't honor these??? -- _____________________________________ John Andersen
On Tuesday 25 May 2004 12:33 pm, Jerome R. Westrick wrote:
The command looks good... Just a minute I'll confirm that it works on my machines...
You are right, the command fails from SuSE 9.1 to SuSE 9.1...
SLP 9.1 x86 $ ps aux | grep X root 5233 12.9 4.3 76536 22340 ? S May24 208:03 /usr/X11R6/bin/X -nolisten tcp -br vt7 -auth /var/lib/xdm/authdir/authfiles/OMMITTED X11 is configured by default to NOT listen to port 6000/TCP. GREAT, IMO. /etc/opt/kde3/share/config/kdm/Xservers controls this, I believe. I cannot guarantee. -- _/_/_/ Bob Pearson gottadoit@mailsnare.net _/_/_/ "Logic is in the eye of the logician." - Gloria Steinem _/_/_/ "Logic is a tool. It is directed reasoning and not Truth. _/_/_/ What is logical is not necessarily correct." - me
tisdag 25 maj 2004 13:52 skrev Ken Schneider:
The "-X" does not supply the encryption that's what ssh does. "-X" allows you to see the remote programs on your local display.
What he's referring to, is that if you do 'ssh remote_machine', that connection is encrypted. But if you there, do 'xterm -display local_machine:0', the X connection will not be through the tunnel, as it would if opened with 'ssh -X'. He doesn't want the overhead of the tunnel encryption, for the X.
On Tuesday 25 May 2004 09:36, Örn Hansen wrote:
tisdag 25 maj 2004 13:52 skrev Ken Schneider:
The "-X" does not supply the encryption that's what ssh does. "-X" allows you to see the remote programs on your local display.
What he's referring to, is that if you do 'ssh remote_machine', that connection is encrypted. But if you there, do 'xterm -display local_machine:0', the X connection will not be through the tunnel, as it would if opened with 'ssh -X'. He doesn't want the overhead of the tunnel encryption, for the X.
I didn't read that he didn't want it, I read the original post as him not knowing that ssh would automatically forward X connections for him. On any modern hardware the encrption time is nil, and even in local networks the compression usually makes up for it by sending less total data. In my tests on a 100meg local eathernet there is simply NO REASON to ever allow xterm -display someothermachine:0. Put it all thru ssh and be done with it. -- _____________________________________ John Andersen
Silviu Did you get this solved? Jerry On Tue, 2004-05-25 at 13:43, Silviu Marin-Caea wrote:
To see windows of programs running on other machines, I used to
on local_machine type "xhost +" ssh into remote machine and type "export DISPLAY=local_machine_address:0" then I would run the program on the remote machine and receive the window on the local machine
I see that it doesn't work anymore with SUSE 9.1. What changed?
Ah, and I know about ssh -X, that works, but I don't really need encryption, just speed.
participants (9)
-
Anders Johansson -
Bob Pearson -
Dave Smith -
Jerome R. Westrick -
John Andersen -
Ken Schneider -
Sid Boyce -
Silviu Marin-Caea -
Örn Hansen