Как разрешить «Протокол не указан» для пользователя su
У меня есть модем SmartRG SR505N Я провел кучу netstat и осмотрелся, и в конце концов обнаружил, что, хотя Маршрутизатор говорит, что переместил свой собственный ssh-порт с 22 на 2222 после того, как я включил переадресацию портов на свой LAN-сервер, он фактически не перемещает свой собственный ssh-сервер, но это странно, иногда это сработает, а иногда нет. Я читал об этой проблеме на http://www.dslreports.com/forum/r29001235-DSL-Port-forwarding-on-SmartRG-SR505 , это модем, который у меня есть. Думаю, тогда мне придется использовать другой порт, да ладно.
Предположим, вы хотите получить соединение с X методом грубой силы...
Предположим, что вы уже выполняете свои команды на сервере (где работает X), иначе сначала заставьте его работать, а затем используйте 'ssh -X user@server) с клиента ;).
Может быть несколько способов запуска команд xauth, например, вы можете использовать 'sudo', но это может привести к потере или изменению переменных окружения. Следующие переменные окружения должны быть сохранены: DISPLAY и XAUTHORITY. Чтобы проверить, так ли это, вы можете выполнить команду 'echo $XAUTHORITY' тем же способом, каким вы выполняете свои команды, но убедитесь, что вы не расширяете переменные окружения до выполнения этих команд. Например, попробуйте: sudo bash -c 'echo "$XAUTHORITY"', чтобы увидеть, что XAUTHORITY действительно является после выполнения команды sudo (если она исчезнет, возможно, вам нужно добавить что-то в файл sudoers, см. в другом месте).
В конце концов, выполните следующую команду от имени пользователя, с которым вы хотите получить доступ, на сервере:
xauth info
Это покажет 'Authority file', который будет использоваться (/root/.Xauthority по умолчанию, для root, или что-то вроде /home/theuser/.Xauthority). Если он показывает правильный файл .Xauthority, то вам не нужно беспокоиться о переменной окружения XAUTHORITY (на самом деле, я не знаю, когда это не так, за исключением случаев, когда вы хотите манипулировать нестандартным местом этого файла).
Удалите этот файл (если он вообще существует):
rm /root/.Xauthority
Замените /root/.Xauthority на правильный файл XAUTHORITY для вашего случая.
Создайте его заново, но пустым (это нужно для многих команд):
touch /root/.Xauthority
На этом этапе вы получите ошибку No protocol specified, даже если до этого вы получили Invalid MIT-MAGIC-COOKIE-1. Найдите файл полномочий, который X-сервер использует в данный момент:
ps aux | grep Xorg
Это должно показать что-то вроде:
root 1153 0.0 1. 0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7
Имя файла после -auth - это то, что вам нужно в следующей команде. Выполните ее от имени root:
sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list
Это список 32-значных шестнадцатеричных ключей. Например, вывод может быть таким:
hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7
Используйте это для генерации вашего . Xauthority файл (как пользователь, которому нужно снова войти):
xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7
замените 'c0eaf749aa252101a0f57d5087089db7' на то, что было возвращено командой list. Теперь ваш .Xauthority должен иметь размер 51 байт, и вы можете подключиться к X-серверу (снова).
Просто введите это в свой терминал xhost +SI:localuser:root, затем введите export DISPLAY=:0.0и повторите попытку
Используя подсказки в принятых ответах, я смог решить проблему по-другому:
- Найдите файл Xauth в работающей учетной записи (Xauth1)
- Найдите файл Xauth в учетной записи, которая не (Xauth2)
- Копировать Xauth1 в Xauth2
- Изменить разрешения Xauth2
В коде:
root@45c4933a8f1a:~# xauth info
Authority file: /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file: /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser
Допустим, вы пытаетесь получить доступ к GUI как user2(обычный пользователь ), тогда вам нужно загрузить установочный UI как user2 .
Попробуйте следовать этому:
Войти как root:
sudo su
Проверка x-сервера:
xclock
Если вы видите, что часы работают, это хорошо, теперь попробуйте запустить это:
xhost
Результат должен быть таким:
xhost SI:localuser:tri
# tri is my user name
Теперь дайте user2 доступ к xhost
xhost +SI:localuser:user2
теперь попробуйте снова войти в систему user2 и попробуйте открыть любую программу с графическим интерфейсом.
Сделать все это сразу,
su -c 'cat $XAUTHORITY' $(logname) > ~/.Xauthority && XAUTHORITY=~/.Xauthority
При появлении запроса введите пароль пользователя для входа в систему.
Пояснение
Опираясь на ответ tjb, xauth infoможет не работать (X11 ). Когда я попробовал это на другом пользователе, я получил ошибку
xauth: timeout in locking authority file /path/to/Xauthority
Вы можете запустить echo $XAUTHORITYдля пользователя 2 (, который не работает ), чтобы увидеть текущий файл полномочий пользователя 2. Пользователь 2 может не иметь надлежащего доступа к этому файлу, поэтому вы можете изменить его на что-то другое (Пример :/home/user2/.Xauthority )или отредактировать права доступа к файлам. Изменение файла во избежание проблем с безопасностью:
XAUTHORITY=/home/user2/.Xauthority
, а затем следуйте остальной части ответа tjb.