SSH X11 не работает

У меня есть домашний и рабочий компьютер, домашний компьютер имеет статический IP-адрес.

Если я ssh со своего рабочего компьютера на домашний компьютер, соединение ssh работает, но приложения X11 не отображаются.

По моему /etc/ssh/sshd_configдома:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

На работе я попробовал следующие команды:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Мой /etc/ssh/ssh_configна работе:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Мой ~/.ssh/configна работе:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Мой ~/.Xauthorityна работе:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Мой ~/.Xauthorityдома:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Но это не работает

После того, как я сделаю ssh соединение с домом:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Я пользуюсь iptablesдома, но разрешил порт 22. Согласно тому, что я прочитал, это все, что мне нужно.

UPD. С-vvv

...
debug2: запуск обратного вызова
debug2: x11_get_proto: / usr / bin / xauth list: 0 2> / dev / null
debug1: запрос перенаправления X11 с подменой аутентификации.
debug2: канал 1: запрос x11-req, подтверждение 1
debug2: client_session2_setup: id 1
debug2: настройка fd 3 TCP_NODELAY
debug2: канал 1: запрос pty-req подтверждения 1
...

Когда попробуйте запустить kate:

debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: запрос от 127.0.0.1 55486
debug2: настройка fd 8 O_NONBLOCK
debug3: fd 8 - это O_NONBLOCK
debug1: канал 2: новый [x11]
debug1: подтвердить x11
debug2: соединение X11 использует другой протокол аутентификации.
X11 соединение отклонено из-за неправильной аутентификации.
debug2: X11 отклонил 2 i0 / o0
debug2: канал 2: чтение не удалось
debug2: канал 2: close_read
debug2: канал 2: вход открыт -> сток
debug2: канал 2: ibuf пуст
debug2: канал 2: отправить eof
debug2: канал 2: входной сток -> закрыт
debug2: канал 2: запись не удалась
debug2: канал 2: close_write
debug2: канал 2: выход открыт -> закрыт
debug2: X11 закрыт 2 i3 / o3
debug2: канал 2: отправить закрыть
debug2: канал 2: закрытие rcvd
debug2: канал 2: мертв
debug2: канал 2: сборщик мусора
debug1: канал 2: свободный: x11, nchannels 3
debug3: канал 2: статус: открыты следующие соединения:
  # 1 клиентская сессия (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# То же, что и выше, повторить примерно 7 раз

Кейт: не может подключиться к X-серверу localhost: 10.0

UPD2 Пожалуйста, укажите ваш дистрибутив Linux и номер версии.
Используете ли вы стандартную среду GNOME или KDE для X или что-то еще, что вы настроили сами?

azat: ~ $ kded4-версия
Qt: 4.7.4
Платформа разработки KDE: 4.6.5 (4.6.5)
Демон KDE: $ Id $

Вы вызываете ssh напрямую из командной строки из командной строки?
Какой терминал вы используете? xterm, гном-терминал или?
Как вы запустили терминал, работающий в среде X? Из меню? Горячая клавиша? или ?

Из эмулятора терминала `якуаке`
Вручную нажмите `Ctrl + N` и напишите команды

Можете ли вы запустить xeyes из того же окна терминала, где ssh -X не работает?

`xeyes` - не устанавливается
Но `kate` или другое приложение kde запущено

Вы вызываете команду ssh от имени того же пользователя, под которым вы вошли в сеанс X?
From the same user

UPD3

Я также загружаю sshисходники и с помощью команды debug2()write пишу, почему сообщается, что версия отличается.
Она видит некоторые файлы cookie, и один из них пуст, другой -MIT-MAGIC-COOKIE-1

Причиной переадресации ssh X было то, что у меня есть /etc/ssh/sshrcфайл конфигурации.

Конец sshd(8)страницы руководства гласит:

Если ~/.ssh/rcсуществует, запускает его; иначе, если /etc/ssh/sshrcсуществует, запускает его; в противном случае работает Xauth

Поэтому я добавляю следующие команды /etc/ssh/sshrc(также со страницы руководства sshd) на стороне сервера:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

И это работает!

Каждый раз, когда у вас возникают проблемы с ssh, первое, что вы должны сделать, это запустить клиент с -vвозможностью предоставить этот вывод для проверки другими:

ssh -v user@somewhere

Я собираюсь догадаться, что проблема в вашей локальной системе. Как вы вызываете команду ssh? Вы запускаете его вручную в оболочке? Или это выполняется как часть сценария? В любом случае вы захотите убедиться, что в вашей локальной системе DISPLAYправильно настроена среда. Он также должен быть правильно установлен на удаленной стороне, но это значение будет отличаться на удаленной стороне от локальной стороны.

Из того, что вы написали, кажется, что он правильно установлен на удаленном хосте (и, соответственно, пересылка X11 корректно устанавливается с помощью ssh). В удаленной системе у вас есть:

$ echo $DISPLAY
localhost:10.0

Что это показывает на местной стороне? Это должно быть легко проверить, если вы находитесь в оболочке, повторяя значение, а также запуская приложение X из этой оболочки ... вы всегда можете использовать venerable xeyesдля такого рода тестирования, конечно же! :)

С другой стороны, если вы вызываете команду ssh из сценария или присоединяетесь к горячей клавише, она может не наследовать ожидаемую среду, поэтому DISPLAYпеременная среды на локальной стороне может вообще не устанавливаться.

Кроме того, поскольку это звучит так, как будто вы возились со своим .Xauthorityфайлом, вы можете полностью удалить его, затем выйдите из сеанса X и войдите снова, чтобы он автоматически воссоздал его. Редко возникает необходимость гадить с вашим .Xauthority, поэтому попытка сделать это, скорее всего, просто отчаянная мера, которая не поможет.

Что вы должны увидеть на местной стороне:

$ echo $DISPLAY
:0.0

В правильно настроенной системе, если вы открываете оболочку, вам не нужно устанавливать ее вручную, она должна быть унаследована от среды, которая запустила вашу оболочку. Однако я видел конфигурации оконного менеджера / горячих клавиш, которые неправильно обрабатывают наследование переменных среды. Если у вас запущена система Linux gnome-sessionили kde-sessionвы используете ее для запуска оболочек или сценариев, то переменные среды вашего сеанса X должны быть установлены правильно, как описано в документации по Ubuntu о наследовании переменных среды :

Когда родительский процесс создает дочерний процесс, например, когда мы запускаем команду «gedit» из терминала, а «bash» (родительский процесс) создает «gedit» (дочерний процесс), дочерний процесс наследует все переменные среды и значения родительского процесса.

...

Примечание. В среде графического рабочего стола Gnome сеанс gnome является родительским процессом всех процессов, запущенных на рабочем столе. Этот факт (наряду с принципом наследования) является ключом к нашей способности влиять на работу нашего рабочего стола с переменными среды. Эквивалентным процессом в KDE является kde-session.

ОБНОВЛЕНО

Спасибо за публикацию вывода от ssh -vvv. В этом случае полезна дополнительная многословность по -vvvсравнению с просто -v. Выходные данные отладки говорят мне, что перенаправление X11 настроено правильно:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Но :0первая строка заставляет меня поверить, что на локальной стороне все еще есть ошибка конфигурации при вызове ssh. Во многих системах значение по умолчанию DISPLAYявляется :0.0не :0. Вы как-то сами устанавливаете значение DISPLAYвручную перед вызовом команды ssh?

На этом этапе было бы полезно получить дополнительную информацию о вашей локальной системе и о том, как вы вызываете команду ssh.

• Пожалуйста, укажите ваш дистрибутив Linux и номер версии.
• Используете ли вы стандартную среду GNOME или KDE для X или что-то еще, что вы настроили сами?
• Вы вызываете ssh напрямую из командной строки из командной строки?
• Какой терминал вы используете? xterm, гном-терминал или?
• Как вы запустили терминал, работающий в среде X? Из меню? Горячая клавиша? или ?
• Можете ли вы запустить xeyesиз того же окна терминала, где происходит ssh -Xсбой?
• Вы вызываете команду ssh от имени того же пользователя, под которым вы вошли в сеанс X?

Этот последний пункт важен. Если вы запускаете ssh от имени другого пользователя (например, если вы открыли окно корневого терминала вместо окна пользовательского терминала), вы столкнетесь с этой проблемой, даже если вы явно настраиваете, DISPLAY=:0поскольку у вас нет прав на подключиться к X-серверу по умолчанию как другой пользователь (даже как root!)

Ваши конфиги вроде бы в порядке, но попробуйте "ssh -X home", как предложили Agemen.

Кроме того, если ничего не помогает, попробуйте это:

После того, как вы поехали на свою домашнюю машину с работы, по «домашнему» типу:

xauth list

Затем на «работа», введите

xauth

Что даст вам приглашение "xauth>". Отсюда введите «add», затем скопируйте и вставьте выходные данные «xauth list», по одной строке за раз (каждая строка начинается с «add»). Например:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Дайте нам знать.

Я не понимаю, хотите ли вы, чтобы ваши удаленные приложения отображались на локальном дисплее ( work) или вы хотите отображать их в удаленной системе ( home).

В первом случае, я думаю, ssh -X hostдолжно быть достаточно, без использования xhost.

Во втором случае система, в которой вам нужно использовать xhost, - homeи этого недостаточно, вам также необходимо экспортировать переменную отображения.

xhost +work
export DISPLAY=:0.0

Я не совсем уверен в том, что вы хотите сделать ... и поскольку я не знаю, какие различия существуют между вашей системой и моей, с одной стороны, и точной конфигурацией, необходимой для вашего случая, с другой стороны (как Я не специалист ^ _ ^). Надеюсь, это поможет вам в некотором роде, так как эта конфигурация сработала для меня.