“su” с ошибкой “соединение X11, отклоненное из-за неправильной аутентификации”
Вы можете видеть это особое поведение, задокументированное в : help: bnext :
Если вы находитесь в буфере справки, это приведет вас к следующей справке буфер (если он имеется). Аналогично, если вы находитесь в норме (не-help) буфер, это приведет к следующему обычному буферу. Это так, что если вы вызвали помощь, она не попадает в способ просмотра буферов кода/текста.
Чтобы включить их в навигацию, используйте : setlocal buftype =
Незарегистрированные буферы не учитываются : bnext , ни (cp. : help 'buflisted' ). Но чтобы они появились в списке буферов, вам придется использовать : буферы! .
Хорошо, я нашел ссылку, которая решает проблему:
https://askubuntu.com/questions/451805/screen-resolution-problem-with-ubuntu-14-04-and-virtualbox
Введите следующее в терминал, и он должен работать!
sudo apt-get install virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11
Я не уверен, чем это отличается от установки виртуального компакт-диска, но, черт возьми, если это сработает, я не буду жаловаться.
-121--129085-Более простое решение:
1 .- ssh user @ host
2. - $ sudo su
3 - # xauth merge/home/user/.Xauthority
Это все
Конечно, переменная $ ДИСПЛЕЯ должна быть набором.
Вы должны полностью переключиться на целевого пользователя, т.е. использовать « - » с su ( su - standarduser ... ). В противном случае X-файлы root будут перемещаться по окружению.
Мои потребности были немного другими, поэтому я придумал немного другое решение. Мне нужна была возможность запускать приложение X11 от имени другого пользователя (не root). Работаю на CentOS, поэтому у меня нет замечательного инструмента gksudo, который есть у счастливчиков с ubuntu и который делает магию Xauth.
Я действительно не хотел создавать несколько пользовательских скриптов только для того, чтобы войти в систему, сменить пользователя и запустить приложение; это кажется мне немного излишним.
Шаг первый:
Разрешите $XAUTHORITY переноситься между сессиями sudo.
Добавьте эту строку под остальными утверждениями env_keep в /etc/sudoers:
Defaults env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Шаг второй:
Разрешите целевому пользователю читать ваш .Xauthority (да, я знаю, кричите SECURITY! сколько хотите). Для тех, кто просто хочет иметь возможность выполнять команды от имени root, этот шаг можно пропустить.
У целевого пользователя та же группа, что и у меня, поэтому я просто включил разрешения на групповое чтение:
$ chmod g+r user ~/.Xauthority
Шаг третий:
CentOS не заполняет значение $XAUTHORITY по умолчанию. Добавьте строку в свой профиль (мой ~/.bash_profile):
export XAUTHORITY=$HOME/.Xauthority
Вот и все. Больше никаких настроек. Не нужно писать .XML, чтобы заставить PolicyKit работать. Не нужно запускать скрипты для каждого входа в систему. Не нужно дважды выполнять sudo, чтобы скопировать xauth. С этого момента вы можете просто:
$ sudo -u user xcalc
Отлично работает с MobaXTerm.
Поскольку я часто использую root-доступ в сетевом файловом ресурсе с зажатым корневым доступом, ни одно из вышеперечисленных решений у меня не сработало. (xubuntu 14.04). Я собрал следующий сценарий, который работает в моей системе. Это может сработать на вашем. Опять же, может и нет, но это бесплатно ...
Предполагается, что я использовал ssh с параметром -Y.
#!/bin/bash
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
port=${BASH_REMATCH[1]}
else
echo "Unexpected DISPLAY $DISPLAY"
exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
sudo -i xauth -i add $cookie
sudo -i $*
В моем случае, когда я столкнулся с этой ошибкой, у меня был зашифрованный пользовательский каталог. После вызова ecrypt-mount-private он избавился от ошибки и позволил мне продолжить пересылку X11.
Чтобы определить, зашифрована ли ваша домашняя папка, вы можете попробовать это (согласно этому ответу): ls -A /home. Если вы видите папку .ecryptfs, ваш домашний каталог, вероятно, зашифрован, и в этом случае вы можете попробовать выполнить команду, которую я указал в начале ответа.