View Full Version : SSH and remote apps
Don Benot
01-18-2003, 02:52 PM
I have a question about using SSH to remotely run apps. I've deduced from some of the threads here, that using X11, it is possible to run an app on a linux box and have the window show up on my mac. I tried doing this as follows:
[Dons-iBook:~] church% ssh -X don@192.168.1.100
don@192.168.1.100's password:
[don@localhost ~]$ mahjongg
Gtk-WARNING **: cannot open display: localhost:10.0
[don@localhost ~]$ lynx
[don@localhost ~]$ vi
[don@localhost ~]$ pan
Gtk-WARNING **: cannot open display: localhost:10.0
[don@localhost ~]$
lynx and vi both ran in the xterm window, so I know I'm connecting okay, but I get the GTK-WARNING on non-console apps. I'm too new at this to know if it's a Mac X11 problem or a linux problem. The linux box is running a stock version of Mandrake just for learning purposes.
Many thanks,
Don
yellow
01-18-2003, 03:34 PM
While the X flag is supposed to automatically negotiate the proper display privs maybe it's failing here. Try setting them the old way.
>> on localhost:
xhost 192.168.1.100
>> on 192.168.1.100:
setenv DISPLAY whatevertheIPaddressoflocalhostis:0.0
See if this will allow you to open your X11 apps properly.
Don Benot
01-18-2003, 03:48 PM
Thanks Yellow, but no luck yet.
Here's where I'm at.
[Dons-iBook:~] church% xhost 192.168.1.100
192.168.1.100 being added to access control list
[Dons-iBook:~] church% ssh -X don@192.168.1.100
don@192.168.1.100's password:
[don@localhost ~]$ setenv DISPLAY 192.168.1.102:0.0
[don@localhost ~]$ pan
Gtk-WARNING **: cannot open display: 192.168.1.102:0.0
[don@localhost ~]$ exit
logout
Connection to 192.168.1.100 closed.
[Dons-iBook:~] church% ssh -X don@192.168.1.100
don@192.168.1.100's password:
[don@localhost ~]$ pan
Gtk-WARNING **: cannot open display: localhost:10.0
[don@localhost ~]$ setenv DISPLAY 192.168.1.102:0.0
[don@localhost ~]$ mahjongg
Gtk-WARNING **: cannot open display: 192.168.1.102:0.0
What shall I try next?
Don
yellow
01-18-2003, 03:54 PM
Well, it appears that libraries that it needs to display such graphics locally aren't there on the host machine you're trying to display them on. Perhaps installing the gtk+package locally would make it happen? Fink is an excellent source to install gtk+.
try running something simple and cross-platformy like emacs. Does that display locally? Hell, even opening an xterm from your remote local might help narrow down the trouble.
Don Benot
01-18-2003, 04:05 PM
GTK+ is already installed via Fink and The GIMP works locally so it must be iworking. I tried running emacs at your suggestion and got the following:
[don@localhost ~]$ emacs
emacs: Cannot connect to X server 192.168.1.102:0.0.
Check the DISPLAY environment variable or use `-d'.
Also use the `xhost' program to verify that it is set to permit
connections from your machine.
[don@localhost ~]$
A little different this time.
Don
yellow
01-18-2003, 04:16 PM
Odd. Are you using Apple's X11 beta or Xdarwin? As you can see, ssh -X isn't doing it's work properly. I've never encountered it failing. Now is setting the display properties manually.
Just to be 100% sure, you are doing this from inside either X11 or XDarwin, right?
Oh, a thought. Are you using a firewall? Are the X11 ports allowed? Ports 6000-6063 should be allowed.
Please read the "X11: Frequently Asked Questions" forum:
28- Reflections on Firewall rule for X11 usage
about allowing Ports 6000-6063.
Don Benot
01-19-2003, 08:25 AM
I read that Sao and I'm still confused. :confused: First it says to open port 6000, not that I know how to do that offhand, and then, 2 paragraphs later, it says I don't need to do that if SSH is working, which I think it is.
Yes, these are commentaries by different people (reflections...)
Obviously several ways are discussed, and you must make your own conclusion of what works best for you.
I would choose to use 'Xforwarding' with ssh.
yellow
01-19-2003, 12:28 PM
He is using X forwarding (-X flag) and it's not working. In order to eliminate the possible problems here the best course of action is to allow those ports to be open and test to see if you can open Xapps the traditional way. If it does work, that narrows the problem down, if it doesn't work, it also narrows the problems down.
The points in the FAQ are correct, straight connections through ports 6000-6063 do send all information as clear text.
It seems to me that he's on a personal network behind a personal router of some kind (Linksys perhaps). Typically these routers have firewalls built into them so you should be protected from the outside world. Provided the firewall is up and running, you shouldn't have security concerns about your machines on your personal network when testing the X11 ports. While I wouldn't suggest keeping them open forever (there are exploits aimed at X11), it will be fine to open them for testing your problems.
Yellow wrote:
Provided the firewall is up and running, you shouldn't have security concerns about your machines on your personal network when testing the X11 ports. While I wouldn't suggest keeping them open forever (there are exploits aimed at X11), it will be fine to open them for testing your problems.
That's right. And it might help very well to find his problem.
Silly question, did he switched on "Remote login" in the "Sharing" System Preferences pane?
And, in case he has the "Firewall" activated in the same 'preferences pane', make sure the port "Remote login - SSH (22)" is enabled.
Don Benot
01-19-2003, 02:31 PM
Okay, "Remote Login" is on, "Firewall" is off. I am behind a firewall from the outside world so I'm willing to make the individual computers non-secure, at least for the moment. If you'll tell me how, I'll open up ports 6000 - 6063.
For a little less confusion, I renamed my linux box "mandrake".
Here's the latest console stuff:
[don@mandrake ~]$ emacs
Xlib: connection to "192.168.1.102:0.0" refused by server
Xlib: No protocol specified
emacs: Cannot connect to X server 192.168.1.102:0.0.
Check the DISPLAY environment variable or use `-d'.
Also use the `xhost' program to verify that it is set to permit
connections from your machine.
[don@mandrake ~]$
Thanks,
Don
yellow
01-19-2003, 03:22 PM
Greetings,
I need to clear up some details first.
How did you connect to mandrake? May I assume that you're sitting at your OS X box and ssh -X to mandrake? What version of LINUX is running on mandrake? Have you updated it's version of ssh to reflect the vulnerabilites found v3.3 and before? It could be possible that your version of the sshd running on mandrake doesn't support Xforwarding. You should take a look at the sshd man page on mandrake.
Which are you using? Apple's X11 or XDarwin?
On a side note:
As far as I know a personal router should act as a repeater and pass all information that comes from your side of the network to all other network connections it is supporting thru it's jacks. I really don't think that the built in firewall is blocking any traffic, at least it shouldn't.
Don't you need to edit /etc/sshd_config?
Change to:
X11_Forwarding yes
Then, sshd needs to restart, the easiest way is to reboot the machine.
yellow
01-19-2003, 03:36 PM
Yep, that's a possibility on his LINUX box. Still trying to get enough info. Newer versions of *NIX come with it on by default.
Don Benot
01-19-2003, 03:59 PM
I am sitting at my OS 10.2.3 box and ssh -X to mandrake.
Linux box is version 8.XX of Mandrake Linux. I don't know what kernal # that uses.
I installed openssh on it. I'm presuming its a newer version of it.
I'm using Apple's X11.
I checked /etc/ssh/sshd_config on mandrake and x11_forwarding is set to yes.
Thanks for your patience with me.
Don
yellow
01-19-2003, 06:37 PM
Hey no worries, if we can help, we will!
Let's start off keeping it simple.
xhost ipaddressofmandrake
ssh ipaddressofmandrake (don't use the -X flag yet)
[now at mandrake's prompt in the same window]
setenv DISPLAY ipaddressofmac:0.0
xterm
And what happens? This should open an xterm from mandrake to your Mac. If it does, then we're on the right track.
Don Benot
01-19-2003, 08:30 PM
We are on the right track. :) A mandrake xterm window opened on the Mac.
Don
yellow
01-19-2003, 09:00 PM
Excellent. Now try and open whatever it was that you wanted to open before, xmahjong was it?
Don Benot
01-19-2003, 09:09 PM
mahjong opened correctly as did pan. At the moment I'm trying to open OpenOffice on it. The problem there is command not found. Any way, will I need to go through that process every time or is there some way to make it/them hold those settings?
Don
yellow
01-19-2003, 09:30 PM
Well, yes and no. As Sao correctly noted earlier, any traffic that you pass using regular xhosting and environment setting is unencrypted. While it's doubtful that anyone could get into your personal network, it's certainly not impossible. And if that was done then it's possible that your machines would be open to some X11 vulnerabilities, or packet sniffing, amongst other things. While I doubt any packets sniffed of Xmahjong traffic would be useful, the errant root/admin password sent along the wire would certainly invite mischief. So unless there's no alternative, I think we should continue our efforts to make this work for us in a more secure way. I know you've done all this a hundred times, but please bare with and humor me. :)
So, getting back to where we were, go ahead and log out of mandrake, quit AX11 so we can start out fresh. If your logins are the same on your Mac and the LINUX box, you can skip the user@address part and just go with the address. If they are different, let's try to use the -l flag.
Open up AX11 and type:
ssh -X ipaddressofmandrake
or, if the user names are different:
ssh -X -l username ipaddressofmandrake
And hit return. Just to be sure, you are using a capital X, right? Now try and open an xterm. Did that work? If not, repeat whatever command you used above and try adding in a -v flag after the X flag. The v flag is for verbose mode to help us debug. How did we do?
*crosses fingers*
Don Benot
01-20-2003, 04:20 AM
We didn't do so well. I'm back where I was. At least now I know that the -l flag needs to come last in the sequence and why.
Verbose mode generated 58 lines of text. My unexperienced eye doesn't see anything wrong in there. What should I be looking for?
yellow
01-20-2003, 09:20 AM
Well, I'm not entirely sure. I've got 15 Jaguar boxes all running Xdarwin and using it for a very CPU/graphics card intense treatment planning system. Everyone uses ssh -X to connect to one of the servers (OSF, Solaris) and runs it from there. I've never had to use the -v flag to help debug.
How about this, try it again and then hit your console and system.log for the complaints in the same timeframe and email them to me and I'll see if there's anything strange that I can see.
yellow
01-20-2003, 02:18 PM
[don@mandrake ~]$ xterm
_X11TransSocketINETConnect: Can't get address for localhost
xterm Xt error: Can't open display: localhost:10.0
[don@mandrake ~]$
The only strange thing that I see here is that it's trying to open the xterm to 127.0.0.1 rather than whatever the address of you Mac is. However, port forwarding might be how tunneling thru ssh works. You'd have to take a peek at the logs on Mandrake to see if there's more info on what it's complaining about.
This probably won't effect the outcome either way, but try setting the sharing name of yor computer to the same static address that you have in the Network PrefsPane. Reboot. At least then the hostname will match the address. This is a real long shot.
Don Benot
01-20-2003, 02:29 PM
This probably won't effect the outcome either way, but try setting the sharing name of yor computer to the same static address that you have in the Network PrefsPane. Reboot. At least then the hostname will match the address. This is a real long shot.
Okay, you lost me here. Can you be more specific?
I'll see if I can read the mandrake logs.
yellow
01-20-2003, 02:46 PM
Sure. Like I said this is a longshot. It might not have any baring on it whatsoever. Well, I suppose that your Router could be doing DHCP. When you look in the Network PrefsPane on your Mac, is it configured to use DHCP?
If so:
Have you entered something for the DHCP Client ID? Make sure that's blank, then write down the IP address and go to the Sharing PrefsPane. Enter that IP address as the Computer Name. Reboot the computer.
If not:
Just take down the IP address, go to the Sharing PrefsPane and enter in the IP address in the Computer Name field. Reboot.
Once you've rebooted:
Now when you open up a terminal window type:
hostname
And what do you get? The hostname should now be the same as your IP address. Now open AX11 and try to ssh into Mandrake and get an xterm open. You can skip the -v flag this time.
Also, when on Mandrake, type:
ssh -V
to see what version of SSH we're dealing with here. It might be better (safer) to email that info to me.
At this point I'm not sure if it's AX11 that's not coping properly or SSH on Mandrake. I suspect that it's the sshd on Mandrake.
Don Benot
01-20-2003, 03:09 PM
Okay, I changed the computer name to 192.168.1.102 which is the static IP of the computer.
Rebooted.
Ran hostname:
Dons-iBook.local
Checked pack in sharing prefs.
Computer name is 192.168.1.102.
Rendezvous name is Dons-iBook.local
I cannot change Rendezvous name to a number. It only accepts letters.
The only thing I could find in the mandrake logs was in auth.log:
Jan 20 13:38:54 localhost sshd[19691]: Could not reverse map address 192.168.1.102.
Jan 20 13:38:59 localhost sshd[19691]: Accepted password for don from 192.168.1.102 port 49183 ssh2
Jan 20 13:38:59 localhost sshd(pam_unix)[19696]: session opened for user don by (uid=501)
Don Benot
01-20-2003, 03:16 PM
I tried running
ssh -V
while on mandrake and I got
command not found
so it very might well be mandrakes problem.
yellow
01-20-2003, 03:21 PM
Well, that just means most likely that ssh isn't in your path. Try typing:
/usr/bin/ssh -V
Don Benot
01-20-2003, 03:42 PM
Well, if nothing else, I'm learning my way around *nix file systems. ;)
I found "sshd" in /usr/sbin. It gave me this:
sshd: option requires an argument -- V
sshd version OpenSSH_3.4p1
along with a whole list of options none of which were v's.
yellow
01-20-2003, 04:29 PM
Well ssh on Mandrake is up to date. I must confess that I am at a loss. You'll need someone who is better versed in the intricacies of ssh to help you with this one.
While it's not secure at all, you can still use the 'old' way that we used earlier. The best and safest way would be to add the appropriate command as an alias on the appropriate machine. You can also add an xhost line to your .xsession. On your Mac there should be a file in your home directory called .tcshrc, into this file you can add aliases with the syntax:
alias aliasname "aliascommand"
Where aliasname is the name you want to alias the command to, and aliascommand is the command you want to do when you type the alias. I used double quotes (") around the aliascommand because it's safer to encase the command in it and easier to read. So you would enter something like:
alias xlinux "xhost IPaddressofmandrake"
Just be careful that you don't make an alias of an already existing command. Save the file and either source it or logout of AX11 and log back in (or just open a new xterm). Now on the LINUX side of things, you want to do basically the same thing with the setenv DISPLAY blah part. Now some will tell you that you could just add setenv DISPLAY blah into your .cshrc and be done with it, no aliases, but then whenever you want to log into Mandrake from any other place with and X11 protocol and tried to open a remote window to your local display, it would automatically try to open them to your OSX box. So stick to aliasing it. Now I'm not sure if the file that your looking for on Mandrake is called .cshrc or not. If you do a:
set | grep shell
and you get something to the effect of /usr/bin/csh, then there should be a .cshrc. Or if it's /usr/local/bin/tcsh, then there should be a .tcshrc. If not, then we'll figure it out. If it's bash or something else, then go ahead and type:
ls -laF | grep .
and email me the list and we'll find the resource file we're looking for.
Don Benot
01-20-2003, 04:47 PM
I thought I had a good idea. I went and jumped on my wife's mac which has XDarwin and tried it from there. I got the same error message as from my box. I thought aha, it is mandrake. To make sure, I'll just try doing from my mac to my wife's. I still can't do it. I get:
[Dons-iBook:~] church% ssh -Xl wife 192.168.1.101
wife@192.168.1.101's password:
Last login: Sat Jan 18 11:33:35 2003 from 192.168.1.104
Welcome to Darwin!
[Dons-G3:~] wife% xterm
xterm Xt error: Can't open display:
[Dons-G3:~] wife%
Do I do it the same way from mac to mac?
yellow
01-20-2003, 06:39 PM
Hmm I cannot get it to work either from Mac to Mac. I'm officially at a loss. I can get it to work not problem for me from Solaris and OSF boxes, but I don't have any Linux boxes to test from. Looks like it'll have to be done the 'old' way for the time being. Sorry!
DoubleEdd
01-20-2003, 07:10 PM
I don't know if this will be of any help. I really suspect it's your /etc/ssh/sshd_config file. I run X software of an mdk9.0 box with no problems - but I've had nightmares from slightly incorrect sshd_configs before.
First thing to do - someone told you to check 'X11_Forwarding yes' is there. You replied that, yes, 'x11_forwarding yes' was there. Well for starters if it's case sensitive you may have it wrong!
Secondly, mine is 'X11Forwarding yes'. Here's my full Mandrake sshd_config - see what the differences are and see if that's any help. Good luck!! (Don't forget # lines are comments so you can probably ignore those!)
---- BEGIN sshd_config ----
# $OpenBSD: sshd_config,v 1.56 2002/06/20 23:37:12 markus Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
# 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 change a
# default value.
#Port 22
Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 600
#PermitRootLogin yes
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# rhosts authentication should not be used
#RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#AFSTokenPassing no
# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no
# Set this to 'yes' to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#Compression yes
#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server
Don Benot
01-20-2003, 07:40 PM
Thanks DoubleEdd, but that was just poor typing on my part. Our "sshd_config" files are exactly the same.
There's only one file on mandrake I need and it's already copied over to my mac , so I'm thinking of wiping it and installing FreeBSD on it. The only OS's I have any emotional attachment to are Mac ones.
DoubleEdd
01-20-2003, 07:44 PM
Originally posted by Don Benot
Thanks DoubleEdd, but that was just poor typing on my part. Our "sshd_config" files are exactly the same.
There's only one file on mandrake I need and it's already copied over to my mac , so I'm thinking of wiping it and installing FreeBSD on it. The only OS's I have any emotional attachment to are Mac ones.
I quite understand that. I was converted completely in a matter of days!
Still, this whole thing's quite an enigma. I'd *love* to find out what was wrong.
Don Benot
01-20-2003, 07:54 PM
I'm in no hurry. I'll leave mandrake on there for a while longer in case anyone can think of something that's been missed. I don't want to screw up my Mac, but I'll try anything on the PC that doesn't kill the hardware. Who knows what else I may learn.
rzdroj
01-20-2003, 09:25 PM
1. I used a simple approach similar to that described above with an earlier version of OS X. This thread inspired me to get ssh -X working again after a clean install on OS X a while back as well as a clean install of RH 8.0 linux messed things up.
The commands entered from the OS X machine were the simple ones but there are two notes that may save problems for others.
xhost ipLinuxMachine
Note 1: The above only worked when it was entered in an X11 terminal window - not an OS X terminal. I don't know why.
ssh -X ipLinuxMachine
tcsh
Note 2: The [tcsh] command was needed because the Linux machine uses the bash shell. "setenv" works with tcsh but not bash. And then,
setenv DISPLAY ipOSXmachine:0.0
2. The command for OpenOffice is
/usr/bin/ooffice.
3. Additionally, I have this setup now with Apple X11 running on a separate virtual desktop by using Codetek Virtual Desktop. I can switch from Linux on the remote machine to OS X with just one click. The performance of Linux at the OS X machine is much more responsive that it was when I tried to accomplish the same thing in the past by using VNC.
Don Benot
01-20-2003, 10:21 PM
Two replies in one post.
rzdroj,
what you posted works, however, mandrake uses the tcsh shell. Also, oofice is not on my machine. I did a locate for it and came up with nothing. I can find soffice in several places, but none of them open it.
yellow,
I went looking for the .tcsh files on both machines before I started making aliases. I ran
set | grep shell
and mandrakes reply was:
shell /bin/tcsh
I then ran
ls -a
in my mandrake home directory to verify. .tcsh is not there. There is a .bashrc, which I'm going to assume is not getting read since I'm not using bash.
Shall I create a .tcsh file in my directory on mandrake?
Don Benot wrote:
[Dons-G3:~] wife% xterm
xterm Xt error: Can't open display:
Try removing any DISPLAY setting in the first machine and then run from the second machine ssh -X wife@192.168.1.101
Willy K.
01-21-2003, 01:33 AM
Hey there. I just stumbled across this thread, as I don't usually read the boards (in fact, had to sign up to post this!).
I have a theory about what might be happening here.
The way SSH XForwarding works, your login shell on the remote machine has the DISPLAY environment variable set to something like "localhost:10.0" That's how you know it's a secure connection. What's happening is that SSH is tunnelling any X11 requests headed for that display, and instead sending them back to your mac. Make sense so far? Stop me if I'm moving too fast. ;-)
So now, your mac sees X11 requests headed for its screen, coming off a local port (the near end of that SSH X-tunnel). My hunch is that maybe your mac is refusing those local connections.
Try some steps, and let's see how this goes:
mac$ xhost +localhost
localhost being added to access control list
mac$ ssh -X don@mandrake
don@mandrake$ xterm
If that works, then we win! Just to confirm, type
don@mandrake$ echo $DISPLAY
localhost:10.0
or something like that (11.0 or higher if you are trying this with more than one shell at a time, for example)
Does that help?!
This, by the way, is a secure mechanism for using xhost. Basically, the old way that worked (the one that we were concerned about because of security), you told all machines that they were allowed to write to your Mac's display. Now, we're saying only your mac is allowed to write to its own display (which is a no-brainer...of course that's safe), but since the SSH packets appear to be coming back on the localhost (because of SSH-trickery), that's all cool. The only other people who might be able to spoof this are people who are logged into your Mac at the time. They might possibly be able to set their environment DISPLAY=localhost:0.0 and put things up on your screen, but my guess is that's very unlikely given your networking setup.
How'd we do? I'll keep my fingers crossed while you try it.
-Will
(on the pretty-reasonable chance that this doesn't fix it either, please include output from the Console MacOSX application through the whole run, and post what appears there!)
Don Benot
01-21-2003, 07:03 AM
Sao,
Can you tell me how to remove the display settings? Part of my problem with this may be that I'm working on the edge of my *nix knowledge, which isn't wide, but it is growing.
Also, I want to make sure what machines we're talking about. Let's go with:
Machine 1 - iBook
Machine 2 - mandrake
machine 3 - G3 (wife)
that way, at least I'll be able to keep them straight.
Don Benot
01-21-2003, 07:20 AM
Wiily K.
I tried doing what you suggest and didn't get very far.
[Dons-iBook:~] church% xhost +localhost
xhost: unable to open display ""
Perhaps this is significant?
bluehz
01-21-2003, 07:44 AM
Another REALLY long shot - I had a fair amount of trouble logging in with SSH, X11, using scp, and various other apps on my Linux box a few months ago. I eventually tracked it down to a modified prompt on the Linux box. I had modified the prompt to be two lines and it was showing up as "dirty" in communications between various protocol. After returning to the standard single-line prompt I have not seen the problem since.
notmatt
01-21-2003, 08:14 AM
A quick note: doing something like this:
OSX % ssh -X me@mandrake
mandrake % setenv DISPLAY "OSXip:0.0"
(pardon me if I confuse shell dialects)
is completely counter-productive. The X display would just travel over the woefully-insecure standard X connection, rather than the ssh connection. To use X over ssh, the only display you should need to set should look like this:
OSX % setenv DISPLAY ":0"
The missing first 0 is completely deliberate.
the rest of the sequence *ought* to go something like this.
OSX % rm .Xauthority (optional - I've found that Apple's X11 sometimes doesn't seem to set these right, and rm'ing - or mv'ing if you're the cautious type - the file fixes that issue)
OSX % ssh -X me@mandrake
mandrake % echo $DISPLAY
localhost n:0
(n is usually but not necessarily 10ish)
mandrake % emacs
(in response to the last question, removing display settings is just like removing any other environment variable - unsetenv, for instance, but it depends on the shell you're using)
yellow
01-21-2003, 09:07 AM
Yes Don, you can create a .tcshrc in your home dir.
xhost ipLinuxMachine
Note 1: The above only worked when it was entered in an X11 terminal window - not an OS X terminal. I don't know why.
ssh -X ipLinuxMachine
tcsh
Note 2: The [tcsh] command was needed because the Linux machine uses the bash shell. "setenv" works with tcsh but not bash. And then,
setenv DISPLAY ipOSXmachine:0.0
This is just a reiteration of what I posted before. The IP forwarding flag in ssh takes care of (well in theory :)) the xhosting and display settings for you. Going ahead and xhosting and setting the display and then opening an app is still going to push the connection thru the X11 ports (6000-6063).
Willy K.
01-21-2003, 11:06 AM
>-----------------------------------------------------------------------
>Wiily K.
>
>I tried doing what you suggest and didn't get very far.
>
>[Dons-iBook:~] church% xhost +localhost
>xhost: unable to open display ""
>
>
>Perhaps this is significant?
>--------------------------------------------------------------------------
Yes, this is certainly significant. The xhost command is attempting to set permissions on some display (in this case the iBook's display), but it doesn't have a DISPLAY environment variable set.
So you need to have that variable set to "0:0" before you run the xhost command. If you have all that .tcshrc business working at this point, you can put a command in there:
setenv DISPLAY 0:0
Or you can just do it temporarily on the command-line (same command), and then run the xhost command.
To confirm that it looks right, you iBook session should look like this:
[don@iBook]$ echo $DISPLAY
0:0
[don@iBook]$ xhost +localhost
localhost being added to access control list
[don@iBook]$ xhost (no arguments, just to check the settings)
access control enabled, only authorized clients can connect
INET:localhost
Then move on with the ssh and other tests I suggested.
If you still get stuck at the beginning. That is, if it now says
xhost: unable to open display "0:0"
instead of
xhost: unable to open display ""
Then you know that the environment variable is getting picked up, but it can't talk to the XServer. So be certain X11 is running! (this is important in general. most of us learned this stuff in UNIX environments where X was necessarily running to be doing GUI stuff, but be sure you don't quit it or forget to launch it in OSX before running any of these tests, of course)
Good luck. Let us know how you make out.
-Will
rzdroj
01-21-2003, 11:20 AM
Don,
The local startup files that tcsh uses are .cshrc and .login. If .tcshrc exists, tcsh reads .tcshrc instead of .cshrc. If none of those exist in your home directory then tcsh starts up with the standard system settings. I don't have any of those three files in my home directory on the RedHat system. You only need them if you want to change things in your own environment.
midan23
01-21-2003, 12:19 PM
I just read all the thread ... confusing ...
But it helped me to get it working !
Here's my way :
1) Definitions
I have to maschines : a linux box (lets call it remote) and my iBook (call it local)
2) Variables
You should never set the DISPLAY variable in a script that is run at login !
3) remote sshd config
Check that "X11Forwarding" is set to yes.
You can also set "UseLogin" to no. (Having this value set to yes disables X11Forwarding !)
Also don't forget to restart the ssh server
4) local sshd config
You don't need it ...
5) Starting X11
Start X11 on your local maschine and open an xterm. Check that that the DISPLAY-variable is correct (Enter "echo $DISPLAY", should be ":0.0"
6) login to remote
enter something like "ssh -X user@remote-ip", enter password and check the DISPLAY-variable (should be "localhost:0.0)
7) Test
You can now make a test by starting any X11-application (a simple xterm can do it, but you can also try a program, that you don't have on your local maschine, just look at /usr/X11R6/bin)
Willy K.
01-21-2003, 12:33 PM
Midan23, glad you got it working!
There are 2 comments on your steps, just for completeness:
- In step 6, the DISPLAY will actually be set to something like :10.0 on the remote box, not :0.0. If it were :0.0 then application windows would be opening on the monitor attached to the linux box!, rather than on the iBook. That may just have been a typo. If it really is :0.0, then I better shut-up now, because I'll be totally confused! :-)
- In step 2, you mention that DISPLAY doesn't need to be set for you at login. This is correct, but only because of how you phrase step 5. You do it all from an X11 xterm, which automatically sets DISPLAY for you. I generally ssh from Terminal.app, which will not work unless I explicitly set DISPLAY=:0.0
Don, Midan has a good point though. In the interest of getting everything working with as little headache as possible, you might want to be running these commands from an X11 XTerm instead of from Terminal.app.
-Will
Don Benot
01-21-2003, 09:53 PM
Okay, here's the latest. A lot of stuff came through today, so if I missed a step that someone thinks is important. just remind me.
I haven't added a .tcsh file to mandrake yet, nor have I made any modifications to the one on iBook.
Here's what I ran tonight with still no results.
[Dons-iBook:~] church% unsetenv DISPLAY
[Dons-iBook:~] church% setenv DISPLAY 0:0
[Dons-iBook:~] church% echo $DISPLAY
0:0
[Dons-iBook:~] church% xhost +localhost
localhost being added to access control list
[Dons-iBook:~] church% ssh -Xl don 192.168.1.100
don@192.168.1.100's password:
[don@mandrake ~]$ xterm
_X11TransSocketINETConnect: Can't get address for localhost
xterm Xt error: Can't open display: localhost:10.0
[don@mandrake ~]$ echo $DISPLAY
localhost:10.0
[don@mandrake ~]$ exit
logout
Connection to 192.168.1.100 closed.
[Dons-iBook:~] church% xhost
access control enabled, only authorized clients can connect
INET:localhost
[Dons-iBook:~] church%
All commands are being run from an xterm inside of Apples X11.
Don Benot.
If you're using the Terminal you need to set $DISPLAY (locally) but if you are using X11's xterm it's already set.
carouzal
01-21-2003, 11:07 PM
Have you tried to add this to your local ssh config file on the client machine?
pico ~/.ssh/config
add the following lines (not the -----), if config doesnt exist in the .ssh directory create it (mine didn't exist)
-------------------------------------------------------
Host *
ForwardX11 yes
-------------------------------------------------------
now all I have to do is run (ssh name@host)
the (echo $DISPLAY) still errors for me but all of my Xapps run perfect.
Hope this helps
midan23
01-22-2003, 11:11 AM
Just to be sure that the value is correct, take a look at the file /etc/hosts on mandrake ...
If "localhost" isn't right, there may be some problems ...
---------
Something else :
If you use ssh you don't need xhosts, since ssh uses another way (xAuthority to be more precise ...)
The difference is that using xhosts everybody with the right ip-address can connect to your X-server. With Xauthority only poeple having the right magic cookie (in ther .Xauthority-file) can connect.
---------
Willy K.
step 2 : To be more precise : You should never set the DISPLAY-variable yourself ... that can lead to more problems than needed ...
step 6 : You are right, I made a typo ... it is "localhost:10.0" ...
Don Benot
01-22-2003, 06:56 PM
Well, I'm going to throw in the towel on this. I've tried everything multiple times, and while I haven't succeeded at resolving the problem, I have learned a little. Thank you for all of your help. I am now going to wipe mandrake and see if I can get freeBSD installed on it. If I succeed at that, I'll try again.
Regards,
Don
carouzal
01-23-2003, 07:09 AM
You might want to try installing mandrake 9, I wiped my iBook clean yesterday and installed mandrake 9 on a pc I had.
I installed mandrake and made sure that ssh was installed and I could connect through the terminal.app from my fresh install of OS 10.2.3.
Next I installed X11 and edited my /etc/ssh_config file (on the mac) and changed:
# ForwardX11 no
to
ForwardX11 yes
As soon as I saved the changes everthing worked. I tested KDE & GNOME apps as well as gimp, licq, gaim, etc....
So at least with mandrake 9 you only have to edit 1 file to get things working.
It may be an older version of SSH running in your version of mandrake.
Don Benot
01-24-2003, 09:43 AM
WooHoo! We have success. :D I wiped out Mandrake 8.0, attempted several failed installs of FreeBSD, and installed Mandrake 9.0. I had to edit my ~/.ssh/known_hosts file so the keys would work and then everything worked just the way its supposed to. It was not OS X's fault. It was Mandrake 8's.
Thank you for your patience and help with this. That's why the Mac community is so great.
Don :cool:
yellow
01-24-2003, 09:48 AM
YAY! Congrats :-)
Willy K.
01-24-2003, 10:36 AM
Congrats, Don. Who would've thought that a "mature" unix like Mandrake would be crippling a newcomer like X11onMacOSX?
Mac-addicts do have a special community, and the recent marriage of the *nix community to the Mac community has caused a uniquely patient and intelligent support-base for sure!
(But in this case, you get most of the credit. We were just along for your success-ride!)
Take care.
-Will
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.