проблема с удаленным запуском графических приложений

Возникла надобность на удаленном сервере запустить приложение в грфической оболочке. Настроил ssh со стороны сервера и клиента
на клиентской стороне в ssh-config:
ForwardX11 yes
ForwardX11Trusted yes
на стороне сервера в sshd-config:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Запускаю ssh, пишу gimp &, система отвечает: Cannot open display.
В ответ на запрос: echo $DISPLAY - пустая строка

Пробовал в .bashrc добавлять:
if [ ! $DISPLAY ] ; then
if [ "$SSH_CLIENT" ] ; then
export DISPLAY=`echo $SSH_CLIENT|cut -f1 -d\ `:0.0
fi
fi
не помогло.

Если на сервере запустить startx, получаем:

artem:/etc/ssh # startx
xauth: file /root/.serverauth.26688 does not exist
xauth: file /root/.Xauthority does not exist
xauth: file /root/.Xauthority does not exist


Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.


Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.

Invalid MIT-MAGIC-COOKIE-1 keyxinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
-------------------------------------------------------------------------------------------
xinit failed. /usr/bin/Xorg is not setuid, maybe that's the reason?
If so either use a display manager (strongly recommended) or adjust /etc/permissions.local

На сервере стоит OpenSUSE 11.4, на клиенте - Ubuntu 12.04

Подскажите пожалуйста, чего делать чтобы наступило счастье?

А если подключаться командой ssh -X?

"selotus" написал:

Запускаю ssh, пишу gimp &, система отвечает: Cannot open display.
В ответ на запрос: echo $DISPLAY - пустая строка

Пробовал в .bashrc добавлять:
if [ ! $DISPLAY ] ; then
if [ "$SSH_CLIENT" ] ; then
export DISPLAY=`echo $SSH_CLIENT|cut -f1 -d\ `:0.0
fi
fi
не помогло.

для начала на сервере:
xhost +
на клиенте:
ssh -X user@host

подключение запускаю командой: ssh -X -p №порта username@hostname
пробовал на сервере запустить xost, система отвечает:
xhost: unable to open display ""

А если закомментировать опции (и не забудь перезапустить службу после этого)?

X11DisplayOffset 10
X11UseLocalhost yes

Зачем они тебе?

Закомментировал, перезапустил (sudo /etc/init.d/sshd restart), не помогло, по прежнему проблема:
user@artem:/> gimp &
[1] 27986
user@artem:/> Cannot open display:

ssh просто настраивал как написано здесь: http://mydebianblog.blogspot.ru/2006/12/ssh.html.

А в логах ничего нет?

"selotus" написал:

user@artem:/>

покажи тогда: echo $DISPLAY

http://tr.opensuse.org/SDB:X_Client_Produces_%22Can%27t_open_display%22_Error

selotus написал:

Закомментировал, перезапустил (sudo /etc/init.d/sshd restart), не помогло, по прежнему проблема:
user@artem:/> gimp &
[1] 27986
user@artem:/> Cannot open display:

ssh просто настраивал как написано здесь: http://mydebianblog.blogspot.ru/2006/12/ssh.html.

вот так попробуй :

ssh -X user@host DISPLAY=:0 'gimp'

где DISPLAY=:0 текущее имя дисплея(он может быть и 1 и 2 и 0.1 и т.д.

В ответ на echo $DISPLAY - пустая строчка

если пишу: ssh -X -p №порта имя@хост DISPLAY=:0
система отвечает: X11 forwarding request failed on channel 0

пробовал менять /etc/sysconfig/displaymanager
DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes"
не помогает

а логи какие смотреть?
не может файервол блокирует запуск X-window через ssh?

Плясал неделю назад на похожей грабле. А именно:
Делал простенький сервис антивирусной защиты. Ну, каталог Загрузки и Документы по inotifywait контролировать на всякий пожарный, чтобы не стать источником расползания заразы. И в конце проверки, если вирус найден, zenity отпысывает юзеру, что он есть нехороший человек и так далее.
Если запускаю скрипт монитора от юзера руками - всё работает. Как только он запускается как сервис (уже от рута) - опаньки. Симптомы один в один. Не хочет zenity из сервиса ничего говорить. Несмотря ни на какие DYSPLAY=:0. Решение оказалось простым - надо было zenity запускать не от рута, а от конкретного юзера, то есть: su username -c "zenity ....". То есть, у рута не настроено же никакой графики, почти пустой хомяк.

Может и в данном случае ремутный юзер хочет получить графику на ненастроенном под это дело хомяке? Самое простое - залогиниться один раз этим юзером локально. Чтобы все каталоги и конфиги графические под него создались.

Приведу свой конфиг домашнего сервера.
/etc/ssh/sshd_config

# Лучше на нестандартном
Port 25886
Protocol 2
SyslogFacility AUTH
LogLevel INFO
# Тут осторожно!
PermitRootLogin yes
# Включаем аутентификацию по открытому ключу
PubkeyAuthentication yes
AuthorizedKeysFile   .ssh/authorized_keys
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
# Отключаем .rhost и обычную аутентификацию по паролю
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
UsePAM no
Subsystem       sftp    /usr/lib64/misc/sftp-server

Руту можно по ssh, это не безопасно, но у меня доступ к ssh есть только из внутренней сетки.
Вход по ssh настроен только по ключам.
Для удобства использую альясы в ~/.ssh/config.
В итоге иксовую программу запускаю примерно так:

ssh -X alias firefox

ssh -Y alias firefox

Для того, чтобы в эмулятор терминала сыпалась отладочная информация, опция -v (verbose), вот как у меня это выглядит:

$ssh -v -Y zj deluge
OpenSSH_6.1p1-hpn13v11, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/zenon/.ssh/config
debug1: /home/zenon/.ssh/config line 1: Applying options for zj
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.0.1 [192.168.0.1] port 4535.
debug1: Connection established.
debug1: identity file /home/zenon/.ssh/zenon_dsa type 2
debug1: identity file /home/zenon/.ssh/zenon_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1-hpn13v11lpk
debug1: match: OpenSSH_5.9p1-hpn13v11lpk pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1-hpn13v11
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 15:c6:44:27:3c:93:bc:9d:7d:93:d7:69:3c:5b:39:fc
debug1: Host '[192.168.0.1]:4535' is known and matches the ECDSA host key.
debug1: Found key in /home/zenon/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/zenon/.ssh/zenon_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.0.1 ([192.168.0.1]:4535).
debug1: HPN to Non-HPN Connection
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 0, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LC_TIME = POSIX
debug1: Sending env LC_NUMERIC = POSIX
debug1: Sending env LC_MESSAGES = C
debug1: Sending env LANG = ru_RU.UTF-8
debug1: Sending env LC_ALL = ru_RU.UTF-8
debug1: Sending command: deluge
debug1: client_input_channel_open: ctype x11 rchan 3 win 87380 max 16384
debug1: client_request_x11: request from ::1 36870
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 2
debug1: channel 1: free: x11, nchannels 1
Transferred: sent 19648, received 6224 bytes, in 2.5 seconds
Bytes per second: sent 7761.7, received 2458.7
debug1: Exit status 0

Проблема решилась, на машине просто иксы не настроены. Спасибо Cruiser78.