Не удается запустить xterm над ssh после нескольких успехов

Я запускаю несколько сценариев MATLAB в командной строке удаленного компьютера, используя ssh . Эти скрипты запускают 5 xterms которые отправляются мне через ssh (используя опцию -X ). На данный момент я отлаживаю свой код, поэтому время от времени я перезапускаю свои скрипты. Все работает отлично на пару прогонов, но после N-го времени (где N – случайное число) я получаю тезисы об ошибках:

 xterm Xt error: Can't open display: localhost:10.0 xterm Xt error: Can't open display: localhost:10.0 xterm Xt error: Can't open display: localhost:10.0 xterm Xt error: Can't open display: localhost:10.0 xterm Xt error: Can't open display: localhost:10.0 

После этого я могу продолжать использовать ssh, за исключением запуска любого связанного с GUI, что означает, что я больше не могу запускать xterms удаленно. Моим единственным обходным решением является перезапуск ssh-соединения. Могу ли я это исправить, чтобы никогда не беспокоиться об этом?

  • Псевдотерминал не будет выделен, поскольку stdin не является терминалом
  • ssh и sudo, но нет $ DISPLAY
  • Завершение сеанса экрана GNU, если SSH не подключен
  • Блокировать SSH всем, кроме пользователя root
  • Использование таймаута в скрипте с одной командой, но несколько хостов
  • Как скопировать каталоги через ssh
  • система

    • локальная система: частный ноутбук, работающий Chakra Linux, KDE
    • удаленная система: университетский компьютер, работает openSuSe, KDE

  • Выполнять команду в sftp-подключении через скрипт
  • Отключить учетную запись PAM, но сохранить ландшафт-sysinfo y motd
  • Как получить доступ к моей локальной сети из любого места через ssh?
  • Проблема SSH удаленного доступа
  • Канал 0: сбой при открытии: административно запрещено: открыть сбой
  • Закрытый ключ SSH каким-то образом доступен для всех пользователей
  • 2 Solutions collect form web for “Не удается запустить xterm над ssh после нескольких успехов”

    SSH блокирует новые соединения X11 через 20 минут в настройках по умолчанию. Чтобы этого избежать, запустите ssh -Y вместо ssh -X или установите опцию ForwardX11Trusted yes в ~/.ssh/config .

    Если вы запустите ssh -v , вы увидите сообщение «Отклонено соединение X11 после того, как ForwardX11Timeout истекло», когда новое приложение попытается подключиться к дисплею после таймаута. Без -v (что вызывает много другого отладочного вывода), вся информация, которую вы получаете, это «Не удается открыть дисплей».


    Чтобы объяснить, почему, мне нужно дать немного информации. Пересылка X11 позволяет конечным машинам связаться с локальным X-сервером. Это имеет последствия с точки зрения безопасности. Сервер X11 не изолирует приложения друг от друга; это позволяет диспетчеру окон перемещать окна и убивать их по своему усмотрению, что позволяет инструментам макрообработки делать это, а также вводить нажатия клавиш и так далее. Также любое приложение может читать и изменять буфер обмена. Это дает большую отдачу удаленным приложениям над вашими локальными данными. Если удаленный компьютер не доверен, с подключением в текстовом режиме, худшее, что может случиться, – это плохие вещи на удаленной машине. Но с неограниченным соединением X11, плохие вещи могут произойти и на вашей локальной машине.

    X11 включает в себя расширение « SECURITY », которое позволяет объявлять некоторые приложения как ненадежные. У ненадежных приложений меньше прав, например, они не могут контролировать или вводить нажатия клавиш в других приложениях. SSH дает возможность объявлять доверенное соединение ( ForwardX11Trusted yes или ssh -Y ) или ненадежное ( ForwardX11Trusted no или ssh -X ).

    SSH уже давно дефолтовы установил ненадежные соединения. В качестве дополнительной функции безопасности ненадежные соединения могут быть установлены только в течение нескольких минут в начале сеанса SSH; первоначально 2 минуты ( ssh.c 1.202 ), затем 20 минут ( ssh.c 1.207 ). В качестве меры безопасности, я не вижу смысла: если вы работаете ненадежного приложение уже, то ли другое приложение может быть запущено позже спорно. В последних версиях SSH ( ssh.c 1.340 , clientloop.c ) таймаут настраивается с помощью ForwardX11Timeout .

    К сожалению, из-за ошибки на X.org (в настоящее время она недоступна) вы не можете установить слишком большое значение ForwardX11Timeout , иначе произойдет сбой X-сервера .

    Надежные соединения не подпадают под действие этого механизма истечения срока действия. Компромисс заключается в том, что вредоносное ПО или вредоносный администратор на удаленной машине могут управлять вашим локальным компьютером. Это часто бывает приемлемым, но вам решать.

    Я пробовал все это, но по-прежнему имел ту же проблему «Нет протокола». Если кто-то сталкивается с тем же, попробовав все решения, я могу сказать, что это не сложно,

    Я нашел сообщение об ошибке в моем файле журнала Xming. Xming (работает на панели задач) >> просмотреть файл журнала …

    Таким образом, вы можете перезапустить систему и запустить Xming, если Xming работает правильно, в файле журнала будет больше строк. Затем выполните тот же # export DISPLAY="IP:0.0" , он должен работать сейчас.

    У меня была другая проблема с двумя мониторами. И я нашел то же сообщение «Нет протокола». Не было выяснено, что проблема связана с 2-м монитором. Поэтому я остановил один монитор, если вы хотите использовать несколько мониторов, вот команда

     Xming -query <IP address of remote host> -nodecoration -screen 0 @2 -clipboard 
    Linux и Unix - лучшая ОС в мире.