как к ssh-Y и затем su - <другой пользователь> и все еще направляют X заявлений к Вашей локальной машине

Это не ответ, поэтому если Вы находите один, очевидно, который предпочтителен.

В противном случае и это - первопричина Вашей загадки:

Причина я не ssh'ing непосредственно, состоит в том, потому что я не хочу, чтобы тот пользователь был доступен через ssh (это - "virtualbox" пользователь, который является, очевидно, легкой целью для попытки ботов к ssh к тому серверу)...

Это кажется мне не большой частью обоснования. "Какая цель ботов" WRT хорошо настроенный sshd в основном не важен. Они будут шуметь вокруг порта 22 повсеместно где-нибудь? По-видимому, так. Это означает, что у них на самом деле есть шансы на успех?

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

SSH очень безопасен при надлежащем использовании. Если бы это не было, то интернет-коммерция не была бы выполнима. Итак, почему эти боты беспокоятся? "Используемым правильно" я имею в виду, прежде всего, с обязательными парами "открытый/закрытый ключ". Если Вы делаете это и уверены, что Ваш закрытый ключ безопасен (и необходимо быть), уверены в sshd.

Я думаю причина, все "попытки взлома" происходят, вообще то, что существует большое тело пользователей, которые не делают, вещам нравится, задают вопросы на U&L ;) и не читают страницы руководства и используют одну только защиту паролем, который является видом подобного отъезда Вашей карты ATM в машине где-нибудь с высказыванием знака, "Предположение далеко!".

Однако при размышлении о закрытом ключе как карта ATM - как что-то, что физически защищается Вами (который это по существу), затем цель становится многим намного более эфирным. Все те боты могут сделать, доказывают, что да, действительно тысячам машин потребовались бы тысячи лет, сотрудничая к грубой силе 2048-разрядный ключ.

Если Вы устаете читать сообщения о попытках взлома, изменяете свой порт. Я видел людей здесь какашка-какашка это как "безопасность с помощью мрака", однако, sshd, который правильно защищается на порте 22, не будет немного менее безопасным на порте 57, но это не будет случайным образом побеспокоено. Конечно, все Ваши враги беспилотника могли просто сканирование портов целый IP - но Вы знаете что? Они не делают. Я предположил бы, что это вызвано тем, что то, что они ищут, является кем-то выполняющим систему, кто даже не посмотрел на /etc/ssh/sshd_config, А тем более образованный себя и настроенный это.

1. ssh -Y на удаленную машину как на себя.
2. После этого введите список xauth . Появится список элементов MAGIC-COOKIE. Ваш сеанс входа в систему, скорее всего, будет последним в списке. (Проверьте это, посмотрев на имя хоста и числовой код UNIX и сравнив его с именем хоста, с которого вы обстреляли, и вашим текущим локальным хостом: ## DISPLAY переменная env.)
3. Переключить пользователей.
4. Введите xauth add + всю строку MAGIC-COOKIE сверху.
5. Графика должна появиться. Протестируйте это с помощью быстрого xlogo .

Мне нравится ответ Рэнди, но для меня он не совсем сработал.

Вот что у меня получилось:

1. ssh -Y как user1
2. список xauth | grep `uname -n`
3. Переключиться на user2
4. unset XAUTHORITY
5. xauth generate: 0.
6. xauth добавить: 0.

Обратите внимание на две точки в шагах 5 и 6.

Если я просто следую ответу Рэнди, переменная user2 XAUTHORITY все еще указывает на user1 . Xauthority файл. И его синтаксис клавиши + не работал.

Хотя я нашел это очень полезным, мне также пришлось экспортировать $DISPLAY следующим образом:

Как первый пользователь

# $xauth list $DISPLAY
<<<<<<<<FULL COOKIE TEXT>>>>>>>>>>>
# echo $DISPLAY
    <localhost:11.0>

Как второй пользователь

# xauth add <<<<<<<<FULL COOKIE TEXT>>>>>>>>>>>
# export DISPLAY=<localhost:11.0>

Примечание. :Моя система — Red Hat 7.