ОСТЕРЕГАЙТЕСЬ (надоело читать неполные ответы, которые приводят к недостатку безопасности)

1 / использование ssh -Y означает наличие поддельной информации о xauth, что плохо!

2/ ssh -X должен работать, так как XQuartz, когда он включен, использует xauth. Единственная проблема в том, что ssh ищет xauth в /usr/X11R6/bin, а на macos с XQuartz он находится в /opt/X11/bin

Безопасное решение:

1 / Включите первую опцию на вкладке " Безопасность " в настройках (Cmd-,), которая включает аутентифицированные соединения

2/ добавить

XAuthLocation /opt/X11/bin/xauth

в $ HOME /.ssh / config

3 / ssh -X you_server работает в безопасном месте

Если вы приедете сюда в 2015 году: даже если все остальное настроено правильно, это также может произойти в Mac OS X 10.10 Yosemite, при использовании ssh -X и запуск версии XQuartz <= 2.7.7. Основная причина заключается в том, что экранные сокеты X11 записываются вне пути поиска xauth: проблема #2068 в трекере XQuartz.

Редактировать: исправленный XQuartz был выпущен на новой домашней странице, https://www.xquartz.org/, и установка последней версии оттуда (в настоящее время 2.7.9) поможет обойти эту проблему.

"Ненадежный" в этом контексте означает, что вы не доверяете соединению. SSH будет использовать дополнительные меры безопасности, чтобы попытаться сделать пересылку X11 более безопасной. "Доверенный" означает, что вы абсолютно уверены, что никто на удаленном хосте не получит доступ к вашим данным Xauth и будет использовать его, например, для отслеживания нажатий клавиш.

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

"Ненадежное" соединение пытается ограничить то, что черная шляпа могла бы сделать для вас, задействовав расширение безопасности X11 и отключив другие расширения, которые вам (надеюсь) не нужны. Вероятно, поэтому RandR отключен с помощью -X. Нужно ли вам иметь возможность вращать X-дисплей с удаленного хоста?

Также важно отметить, что "ненадежная" переадресация X11 отключается через определенное время, чтобы вы не могли случайно оставить его включенным. Новые попытки открыть окна после этого просто потерпят неудачу. Это укусило меня несколько раз, прежде чем я прочитал достаточно документов, чтобы понять, что происходит.

Если вы получаете то же сообщение даже при использовании -Y, xauth Программа может отсутствовать на сервере. На Debian-подобных системах вам нужно xauth пакет. На RedHat-подобных системах вам нужно xorg-x11-xauth пакет.

Исключите проблемы на стороне сервера

Во-первых, вы должны исключить любые проблемы на стороне сервера. Вы в состоянии ssh -X с любого другого хоста успешно? Есть ли ssh -Y работать пока ssh -X не делает? В любом случае предположим, что ssh + X11 правильно настроен на вашем сервере и перейдите к следующему разделу.

Если вы не можете это проверить (скажем, у вас есть только один ноутбук с X11), вы можете ssh от сервера к себе, используя поддельный сеанс:

1. export DISPLAY=:44 # (Оболочка Борна) или
   setenv DISPLAY :44 # (csh / tcsh)
2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Фальшивое печенье только для этого теста
3. ssh -X localhost env |grep DISPLAY

Ожидаемый результат: переменная DISPLAY должна быть установлена ​​на удаленном конце сеанса ssh-to-self. Если вы не получите результата, ваш сервер, вероятно, неправильно настроен (например, библиотеки X11 и / или xauth команда может отсутствовать; или в конфигурации sshd можно запретить доступ к X11)

На Mac: убедитесь, что Xquartz обновлен

Согласно ответу Уилла Энгли

исследовать ssh -vv -X выход

Приведенное вами сообщение об ошибке является симптомом, который может иметь много причин. Попробуйте еще раз с ssh -X -vv remotehost, что должно дать вам дополнительные сведения о том, почему не удалось установить туннель X11.

Вы видите следующее сообщение?

 debug1: нет программы xauth.

1. Обратите внимание, где в вашей клиентской системе xauth команда находится:

    какой хаут 

2. Добавьте следующее в самом конце вашего ~/.ssh/config (и добавьте комментарий, чтобы напомнить себе, чтобы сохранить его там в будущем):

    Хост *
       XAuthLocation /opt/X11/bin/xauth
   

   Отрегулируйте этот путь в соответствии с выводами шага 1 - Кредиты Ян-Виллему Арнольду

У меня нет установки, которая может демонстрировать это поведение, так что это выстрел в темноте:

Предупреждение может быть подавлено, если вы установите ForwardX11Trusted в "no" для хостов, которые дают это предупреждение. Вы можете разместить это в любом ~/.ssh/config или же /etc/ssh/ssh_configи вы можете сделать опцию специфичной для конкретного хоста, включив Host <hostname> на линии выше. <hostname> Компонент соответствует тому, что вы вводите в командной строке (не разрешенное имя хоста), и он может включать в себя подстановочные знаки.

При установке xauth не работает правильно, один особенно раздражающий случай может быть поврежден .Xauthority файл. Этот конкретный случай позволил некоторым X-клиентам работать, но не другим, у которых более высокая тенденция к сбою с новыми дисплеями. Удаление и воссоздание .Xauthority Файл может решить эту проблему.

Как уже было объяснено выше, у меня сработало следующее:

Отредактируйте ~/.ssh/config, чтобы добавить строки

Host *
    XAuthLocation /opt/X11/bin/xauth

и теперь ssh -X hostname работает (XQuartz 2.7.11, macOS 10.4 Mojave)

Используя XQuartz 2.7.11 на MacOS Catalina, мне пришлось обновить файл /etc/ssh/ssh_config и добавить XAuthLocation /opt/X11/bin/xauth после Host * для работы ssh -X

У меня уже была установлена ​​последняя версия XQuartz 2.7.11, но я думаю, что с тех пор я также несколько раз обновлял ОС. Я переустановил XQuartz 2.7.11, и теперь он работает нормально.

Xauth добавить `hostname`/unix:10 MIT-MAGIC-COOKIE-1 `openssl rand -hex 16`