По какой причине вы не хотите использовать флаг -Y вместо флага -X?

Проще говоря, разница между -X и -Y заключается в том, что -Y включает надежную пересылку X11.

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

Изменить: с тех пор на новой домашней странице был выпущен фиксированный XQuartz, xquartz.org, и установка последней версии оттуда (в настоящее время 2.7.9) поможет обойти проблему.

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

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

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

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

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

ОСТОРОЖНО (устал читать неполные ответы, которые приводят к бреши в безопасности)

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

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

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

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

2. добавить следующее к $HOME/.ssh/config

   XAuthLocation /opt/X11/bin/xauth

3. ssh -X you_server работает надежно

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

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

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

Во-первых, вы должны исключить любые проблемы на стороне сервера. Вы можете 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 # Поддельный cookie только для этого теста
3. ssh -X localhost env |grep DISPLAY

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

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

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

Изучить ssh -vv -X вывод

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

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

debug1: No xauth program.

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

   which xauth

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

   Host *
       XAuthLocation /opt/X11/bin/xauth
   

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

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

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

редактировать ~ / .ssh / config добавить строки

Host *
    XAuthLocation /opt/X11/bin/xauth

и сейчас ssh -X имя хоста работает (XQuartz 2.7.11, macOS 10.4 Mojave)

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

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