Как диагностировать отказавшую передачу X11 с ssh?
Это работает на меня:
$ ls -rt | tail -1 | xargs vim
Но у Вас может быть каталог как последняя запись, в этом случае Вы могли бы хотеть отфильтровать каталоги:
$ ls -rt | grep -v "^d" | tail -1 | xargs vim
Попробуйте шаги здесь: http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-authentication/
Это могло бы быть ~/.Xauthority владение или /etc/ssh/sshd_config проблема. Также можно проверить $ tail /var/log/messages
Для меня это ранее помогло стереться .Xauthority- файлы. Необходимо, вероятно, создать резервную копию их.
mkdir ~/Xauth-old
mv ~/.X* ~/Xauth-old/
Далее, в ~/.ssh/config можно избежать некоторого другого горя с использованием аутентификации
ForwardX11Trusted yes
Добавление этой строки в / etc / ssh / sshd_config исправило это для меня:
X11UseLocalhost yes
Пожалуйста, кто-нибудь из экспертов по Unix, поправьте меня, если я ошибаюсь:
Это особенно сложно, потому что в большинстве ответов четко не объясняется, какая сторона соединение, которое вы должны изменить.
Для этого примера:
На хосте A работает X (иногда это сбивает с толку, потому что это дисплей-сервер)
На хосте B работает sshd (сервер защищенной оболочки).
Путаница начинается, если инструкции скажите «на сервере, выполните x», поэтому в этом примере мы называем их host-a и host-b
Вы пытаетесь ввести командную строку на Host A, и вы пытаетесь
user1@host-a:~$ ssh -v -X user2@host-b
Вы должны настроить демон ssh на host-b
Отредактировать / etc / ssh / sshd_config на host-b Добавить
AddressFamily inet
X11Forwarding yes
Перезапустить sshd на host-b
sudo restart ssh
Это должно работать now
Чтобы проверить, попробуйте:
user1@host-a:~$ ssh -v -X user2@host-b
Опять же, на этот раз echo $ DISPLAY должен показать значение DISPLAY , а xterm должен создать xterm на хосте-a