ssh возвращает сообщение “запрос на переадресацию X11, отказавший на канале 1”
Переименование файла (безотносительно его типа, включая каталоги) означает менять свое имя в каталоге, где это расположено. На самом деле переименование и перемещение в файловой системе являются той же операцией; файл отсоединяется с его старого названия и присоединяется к своему новому имени, которое требует изменения и источник и целевой каталог (для переименования в одном каталоге, входные и выходные каталоги являются тем же). Результат - то, что Вы должны записать разрешение на содержании каталога, /box в Вашем примере.
Это точно те же полномочия, необходимо было бы скопировать файл, затем удаляют оригинал, между прочим.
Эти сообщения могут быть устранены через 1 из 3 методов, с помощью просто опции SSH. Можно всегда отправлять сообщения в /dev/null также, но эти методы пытаются иметь дело с сообщением через конфигурацию, вместо того, чтобы просто захватить и вывести их.
Метод № 1 - устанавливает xauth
Сервер, в который Вы являетесь дистанционной работой, жалуется, что это не может создать запись в пользователе .Xauthority файл, потому что xauth не установлен. Таким образом, можно установить его на каждом сервере для избавлений от этого раздражающего сообщения.
На Fedora 19 Вы устанавливаете xauth как так:
$ sudo yum install xorg-x11-xauth
Если Вы затем пытаетесь ssh в сервер Вы будете видеть сообщение, что запись создается в пользователе .Xauthority файл.
$ ssh root@server
/usr/bin/xauth: creating new authority file /root/.Xauthority
$
Последующие логины больше не будут показывать это сообщение.
Метод № 2 - отключает его через ForwardX11
Можно сообщить ssh клиент, чтобы не попытаться включить передачу X11 включением параметра SSH ForwardX11.
$ ssh -o ForwardX11=no root@server
Можно сделать то же самое с -x переключатель:
$ ssh -x root@server
Это только временно отключит это сообщение, но является хорошим вариантом, если Вы не сможете или не желающий установить xauth на удаленном сервере.
Метод № 3 - отключает его через sshd_config
Это обычно - значение по умолчанию, но в случае, если это не, можно установить Ваш sshd сервер так, чтобы X11Forwarding был выключен, в /etc/ssh/sshd_config.
X11Forwarding no
Из этих 3 методов я обычно использую № 2, потому что я буду часто хотеть X11Forwarding на для большинства моих серверов, но затем не хотят видеть X11.... предупреждения
$HOME/.ssh/config
Большая часть времени, которое они передают, даже не обнаружится. Они обычно только присутствуют, когда у Вас есть следующие записи в Вашем $HOME/.ssh/config файл, наверху.
ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes
GatewayPorts yes
Таким образом, это - эта установка, которая в конечном счете управляет поколением тех X11.. сообщения, поэтому снова, метод № 2, казалось бы, были бы самыми соответствующими, если Вы хотите действовать с ForwardX11 yes на по умолчанию, но затем выборочно отключают его для определенных соединений от ssh перспектива клиента.
Безопасность
Обычно не рекомендуется работать с ForwardX11 yes на в любом случае. Таким образом, если Вы желаете управлять своими соединениями SSH в самом безопасном возможном поместье, лучше делать следующее:
- Не включать
ForwardX11 yesв Вашем$HOME/.ssh/configфайл - Только используйте ForwardingX11, когда Вы должны будете через
ssh -X user@server - Если Вы можете, отключить
X11Forwardingполностью на сервере, таким образом, это запрещено
Ссылки
Установите следующие 2 опции в
/etc/ssh/sshd_configна вашем хосте RHELX11Forwarding yes X11UseLocalhost nosudo /etc/init.d/sshd reloadsudo yum install xauth- ssh возвращается на ваш хост RHEL с ключом -X:
ssh -X yourname@rhelbox
В моем случае добавление этой строки в /etc/ssh/sshd_config решило проблему:
X11UseLocalhost no
Другая небольшая вариация - если вы хотите перестать видеть это сообщение (т.е. прекратить попытки пересылки X11) для определенных серверов, но при этом сохранить значение по умолчанию ForwardX11 yes для всех остальных соединений.
Для этого сценария вы можете отключить переадресацию X11 для определенного хоста (или диапазона) в ~/.ssh/config. Что-то вроде этого:
host 10.1.1.*
ForwardX11 no
Благодарность: Это небольшое приукрашивание к существующему (и очень полному) ответу - поскольку я не смог прокомментировать!
Пробежался сегодня по этому поводу и некоторое время бил головой, пока не наткнулся на настройку ssh:
Если это RHEL 7 (CentOS, OEL и т. Д. ), и у него отключен ipv6, необходимо:
AddressFamily inet
установить в / etc / ssh / sshd_config.
Если при запуске клиента в подробном режиме ( ssh -v user @ host ) вы получите
debug1: Remote: No xauth program; cannot forward with spoofing.
, но xauth действительно установлен на сервере, то это, вероятно, связано с тем, что sshd ищет исполняемый файл xauth в неправильном месте (обычно / usr / X11R6 / bin / xauth ). Это можно исправить, установив
XAuthLocation /usr/bin/xauth
в / etc / sshd / sshd_config (или там, где настроен ваш сервер).
Один важный момент, на который следует обратить внимание после внесения изменений в конфигурацию, заключается в том, что вам придется убить sshd, чтобы он принял изменения:
cat /var/run/sshd.pid | xargs kill -1
пользователь root.
Настройка переадресации X11 для каждого хоста
В дополнение ко всем превосходным ответам, уже приведенным здесь, вы можете настроить ForwardX11для каждого хоста, поэтому, если только serverне работает, вы можете добавить запись в свой файл ~/.ssh/configследующего форма:
Host server server.domain.dom
ForwardX11 no
Вы даже можете использовать подобные записи в качестве псевдонимов для целых наборов конфигураций
Host my.server
HostName server.domain.dom
User user
Port 1234
ForwardX11 no
Это особенно полезно, если вы настроили Автозаполнение имен серверов для SSH и SCP .
Я столкнулся с этим вопросом после того, как столкнулся с ошибкой sshd-xauthпочти десятилетней давности. Сообщается о двух решениях, первое для обхода xauth, второе для устранения ошибки.
Решение 1 -обойти xauth
- местный --локальный компьютер, обслуживающий X-сервер.
- удаленный --удаленная машина, обслуживающая приложение, которое управляет данными, поступающими на X-сервер
Пульт/etc/ssh/sshd_config:
X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes
Пульт ~/.Xauthorityпуст или не существует
На местном уровне:
Xephyr -ac -screen 1280x800 -br -reset :2 &
DISPLAY=:2 ssh -fR 6010:/tmp/.X11-unix/X2 user@remote "DISPLAY=:10 xeyes"
Во время теста на локальном компьютере работала Ubuntu 18.05, а на удаленном — Debian Jesse.
Я также разместил это решение как ответ на другой вопрос.
Решение 2 -устраняет ошибку sshd/xauth
Это решение близко к решению @systempoet выше , хотя одного этого было недостаточно.
В дополнение к изменению /etc/ssh/sshd_configна удаленном:
AddressFamily inet
/etc/hostsна пульте дистанционного управления также было изменено:
::1 localhost ip6-localhost ip6-loopback
Если любой из них был закомментирован, сообщение об ошибке
X11 forwarding request failed on channel 0
появился после звонка ssh -X.... Кроме того, /var/log/auth.logпоказал ошибку:
sshd[...]: error: Failed to allocate internet-domain X11 display socket
Тест для создания ошибки (перед исправлением):
Локальный компьютер:
$ Xephyr -ac -screen 1280x800 -br -reset -terminate :2 &
$ DISPLAY=:2 ssh -X user@remote
X11 forwarding request failed on channel 0
Для тех, у кого IPv6 отключен с помощью /etc/sysctl.conf, попробуйте вместо этого использовать вариант загрузки disable.ipv6=1.
Странное взаимодействие с IPv6 похоже на ошибку в OpenSSH:https://bugzilla.mindrot.org/show_bug.cgi?id=2143. Связанные отчеты об ошибках Debian :https://bugs.debian.org/422327,https://bugs.debian.org/595014.