no X11 forwarding

Anna,

Yes - the machine you sit at needs to also request X11 when you ssh into the Xserve machine.

You can force this by typing ssh -Y Xserve or if your client is not up to date with 10.4.X - you might need ssh -X Xserve.

That being said, can you run Xterm or other x11 programs locally before you log into the Xserve? (to rule out X11 application not running on your mac or having problems locally)

Anna,

Ok - It's good that you are familiar with the options (but bad since that's such an easy "fix" if you didn't)

It does not matter how you get a command prompt on your mac. Terminal app, xterm or any other program that lets you invoke ssh will do.

This is really unlikely, but did you edit the /private/etc/ssh_config file on the mac you sit at with the display? If so - please post or duoble check the settings you have there. Mine looks like this...
<pre>Host makapuu
ForwardX11 yes

# Site-wide defaults for various options

Host *
# ForwardAgent no
ForwardX11 yes
</pre>

On the other hand, can you try ssh -v -Y (or two v if the first one doesn't make enough verbose output. You will want to look for messages relating to failures or X11 being set up after the password is entered...
<pre>debug2: x11 getproto: /usr/X11R6/bin/xauth list 😮.0 . 2>/dev/null
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0</pre>

Hi Anna,
This is just a guess but it doesn't seem like an X11 app invoked from a secure shell session invoked with "ssh -Y" should be trying to access the display, 😮. In a remote login, the startup scripts (like ~/.bashrc) are executed after secure shell configures the environment for the session. Thus, if you set the DISPLAY environment variable in a startup script on the remote server, it will override the configuration of the environment that secure shell creates.

If you need to set the DISPAY environment variable on the server under other circumstances, you can test for one of the classic secure shell environment variables, like SSH_CONNECTION, to know when not to set it.
--
Gary
~~~~
Senate, n.:
A body of elderly gentlemen charged with high
duties and misdemeanors.
-- Ambrose Bierce

Hi Anna,

> terminal.app does not allow window forwarding

Yes it does; I just tested it again to make sure. The only requirements are that X11 be running and that the DISPLAY environment variable be set correctly locally on the secure shell client before invoking "ssh -Y". Setting the DISPLAY is actually necessary in Apple's Terminal.app before invoking any X11 app locally. Secure shell needs it in order to be able to negotiate with the local X11 server and set up the tunnel. If the DISPLAY environment variable isn't set, ssh will ignore the "-Y" option and never set up the tunnel.

Setting the environment variable in an X11 terminal isn't usually necessary. Since that terminal is already using the X11 window server, it knows the correct DISPLAY and most set the environment accordingly.
--
Gary
~~~~
When I woke up this morning, my girlfriend asked if I
had slept well. I said, "No, I made a few mistakes."
-- Steven Wright

Ok so I changed my local sshd_config file but it
still didn't work. And anyway I've never had problems
with this when I remote login to the Solaris unix
server.

When you say "local" are you referring to the computer you are using, or the XServe you are trying to run Matlab on?

Assuming the computers you are using are named PowerMac and XServe, you need to edit PowerMac:/etc/ssh_config and XServe:/etc/sshd_config. The ssh_config file controls the ssh client that you run at the command line and the sshd_config file controls the ssh server on the computer you are logging into. Also, be sure to restart the ssh server on the XServe after editing the sshd_config file on it.

You can also test to see if this is simply an oddity of Matlab and only running on 😮 (the local graphics card on the XServe) by trying to run something much simpler in your ssh session. Try /usr/X11R6/bin/xlogo for starters.

Before you ssh to the XServe, "echo $DISPLAY" should show "😮" or "😮.0". After you ssh to the XServe, you should see something like "localhost:10.0". This means your display is virtual screen 10 on the XServe, which is intercepted, encrypted, sent through the ssh connection, decrypted, and shown on your local display.

Make sure these basic tests of looking at $DISPLAY and running something like xlogo, xclock, xeyes, etc.... before trying something more complex. This make debugging MUCH simpler.

MacBook Pro, iMac G5 Mac OS X (10.4.7)

Thanks, yes I realise what you are saying but here's
the thing, terminal.app does not allow window
forwarding, as far as I know it never has. Now in
order to run my apps in X11 I have to invoke X11 but
if terminal.app doesn't allow forwarding and I'm
logged straight into terminal.app on the remote
server how can I ever get this to work ?

Since my default shell is set to tcsh (accounts created under Tiger default to bash), I added the following to my .cshrc file to let me use Terminal.app to run my ssh sessions and tunnel X11 from our Solaris servers.

set path=($path /usr/X11R6/bin)
alias ssh "ssh -Y"
# Set $DISPLAY to the local screen if it's not set to something already
if !(${?DISPLAY}) then
setenv DISPLAY 😮
endif

If you were using sh/bash/ksh as your default shell, you would add something like the following to your .profile:

if [ "x$DISPLAY" = "x" ]; then
DISPLAY=:0
export DISPLAY
fi

By doing this, you can run all your Unix items inside Terminal and don't need to worry about wether you might need to ssh to another system and run X11.

Steve

MacBook Pro, iMac G5 Mac OS X (10.4.6)