Некоторое действие поиска и устранения неисправностей необходимо для нахождения категорического ответа:
"административно запрещенный" определенное сообщение ICMP, махают рукой, останавливая, который кипит "Администратору, явно хочет это заблокированное соединение".
Проверьте свои iptables настройки.
ssh
не имеет никакой логики для определения, почему связь прервалась, она просто предполагает, что, при попытке соединиться, затем она существует, и если Вы не можете добраться там, соединение, должно быть, было заблокировано намеренно.
– Steve Buzonas
03.06.2012, 00:11
По крайней мере один ответ - то, что "удаленная" машина недостижима с ssh по некоторым причинам. Сообщение об ошибке просто абсурдно.
Я видел эту ошибку на cygwin, и это должно быть верным для Linux также и работало на меня. В моем случае я сделал ssh - ND *:1234 user@127.0.0.1 и когда я подключил браузер к тому серверу носков аккомпанемента, он просмотрел, но на аккомпанементе, куда я выполнил это, ssh управляют, чтобы я получил ту ошибку, появляющуюся в консоли с каждым запросом - для одного сайта, по крайней мере, хотя браузер получил его через прокси или казался, по крайней мере до такой степени, что я видел основной возраст. Но внесение этого изменения избавилось от неудавшегося сообщения
While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or
root@remote-server:~# /etc/init.d/ssh restart
ACCEPT
.
– Steve Buzonas
02.06.2012, 06:09
AllowTCPForwarding
, Комментарий Вы говорите о # To disable tunneled clear text
в отношении PasswordAuthentication
будучи установленным на не, PermitTunnel
установка должна позволить сетевые туннели уровня 2 или уровня 3 через бочку/касание и значения по умолчанию к нет. L, R, и опции D используют передачу TCP и не устройство для туннелирования.
– Steve Buzonas
03.06.2012, 00:00
канал 1: открытый отказавший: административно запрещенный: открытый отказавший
Вышеупомянутое сообщение относится к Вашему серверу SSH, отклоняющему запрос Вашего клиента SSH для открытия канала стороны. Это обычно прибывает из -D
, -L
или -w
, поскольку отдельные каналы в потоке SSH требуются, чтобы переправлять переданные данные через.
Так как Вы используете -L
(также применимый к -D
), существует две рассматриваемых опции, которые заставляют Ваш сервер SSH отклонять этот запрос:
AllowTcpForwarding
(как Steve Buzonas упомянул),PermitOpen
Эти опции могут быть найдены в /etc/ssh/sshd_config
. Необходимо удостовериться что:
AllowTCPForwarding
или не существует, комментируется или установлен на yes
PermitOpen
или не существует, комментируется или установлен на any
[1]Кроме того, при использовании ключа SSH к подключению необходимо проверить, что запись, соответствующая SSH, вводит ~/.ssh/authorized_keys
не имеет no-port-forwarding
или permitopen
операторы [2].
Не относящийся к Вашей конкретной команде, но несколько относящийся к этой теме также, PermitTunnel
опция, при попытке использовать-w опцию.
[1] Полный синтаксис в sshd_config(5)
страница справочника.
[2] Полный синтаксис в authorized_keys(5)
страница справочника.
lxc.cgroup.devices.allow = c 10:200 rwm
к конфигурации Вашего контейнера, и гарантируют это если /dev/net/tun
не существует, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tun
выполняется на начальной загрузке в контейнере.
– Azendale
16.04.2016, 03:58
Я получил эту ошибку однажды для помещения удаленного в-L параметре, также эти 0.0.0.0 избыточны, можно опустить его с теми же результатами, и я думаю, что необходимо добавить-g для него для работы.
Это - строка, которую я использую для туннелирования: ssh -L 8983:locahost:8984 user@remote -4 -g -N
-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.
Еще один сценарий - то, что услуга, к которой Вы пытаетесь получить доступ, не работает. Я столкнулся с этой проблемой на днях только для запоминания httpd экземпляра, с которым я пробовал к связанному, был остановлен.
Ваши шаги к разрешению проблемы должны были бы запуститься с самого простого, которое идет в другую машину и видит, можно ли соединиться локально и затем работа себя назад к Вашему клиентскому компьютеру. По крайней мере, это позволит Вам удаваться, в какой точке не происходит коммуникации. Можно проявить другие подходы, но это - то, которое работало на меня.
Это также происходит когда /etc/sshd_config
имеет
AllowTcpForwarding no
набор. Переключите его на yes
позволить передачу TCP.
Эта ошибка окончательно открывается при использовании ssh опций ControlPath
и ControlMaster
для совместного использования одного сокетного соединения, которое будет снова использовано между несколькими соединениями клиента (от одного клиента на тот же user@server). Открытие слишком многих (независимо от того, что это означает в моем случае ~20 соединений) приводит к этому сообщению. Закрытие любых предыдущих соединений позволяет мне открыться более новый, снова до предела.
MaxSession
но MaxSessions
. Хотя существуют некоторые меры защиты, не повреждайте свою ssh конфигурацию сервера...
– Stéphane Gourichon
30.01.2015, 16:36
Если 'удаленное' не может быть разрешено на сервере, Вы получите ту ошибку. Замена IP-адресом и видит, решает ли это Ваш вопрос...
(В основном тот же ответ как ответ Neil - но я, конечно, нашел, что, чтобы быть проблемой о моей стороне) [у меня был псевдоним для названия машины в моем ~/.ssh/config
файл - и удаленная машина не знал ничего из того псевдонима...
-D
(DynamicForward) как SOCKS проксируют в браузере. Т.е. попытка получить доступ к веб-сайту, который не может разрешить туннельный хост.
– timss
02.09.2016, 12:05
У меня было то же сообщение при попытке туннелировать. Была проблема с сервером DNS на удаленной стороне. Проблема была решена, когда она возвратилась к работе.
У меня была эта проблема при попытке Чтобы подключиться через SSH с пользователем, который был авторизован только для подключения с использованием SFTP.
Например, это было в сервере / etc / ssh / sshd_config
:
Match group sftponly
ForceCommand internal-sftp
ChrootDirectory /usr/chroot/%u
[...]
Match
Так что в этом случае использовать SSH, вам придется либо удалить пользователь из эквивалента SFTPONLY
Группа или подключение пользователей, который не ограничен SFTP.
Выполните следующую команду:
df -h
-121--15040- Разделение выполняется в клиенте экрана
, а не в самом сеансе экрана. пара
может разделить свой экран любым способом, каким он захочет, независимо от вашего разделения.
Проверьте, пуст ли /etc/resolv.conf
на сервере, на который вы ssh
-участвуете. Несколько раз я обнаружил, что это связано с пустым файлом /etc/resolv.conf
Если не корень, вы можете просто проверить сервер, попробовав ping
или telnet
(80) на общедоступном имени хоста, то есть:
root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known
После добавления записей nameserver в /etc/resolv.conf
:
root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK
Однако следует также проверить, почему /etc/resolv.conf
был пуст (обычно заполняется записями nameserver dhcp-клиентом на сервере, если применимо.
Я получал то же самое сообщение во время тюнинга SSH в Debian. Оказалось, что в удалённой системе нет свободного места. После высвобождения некоторого дискового пространства и перезагрузки, туннель начал работать.
Проверьте свой маршрутизатор на наличие защиты DNS Rebinding . На моем маршрутизаторе (pfsense) по умолчанию включена защита от повторного связывания DNS. Это вызывало ошибку «канал открыт: сбой административно запрещено: сбой открытия» с SSH
В очень странном случае я также столкнулся с этой ошибкой при попытке создать локальный туннель. Моя команда была примерно такой:
ssh -L 1234:localhost:1234 user@remote
Проблема заключалась в том, что на удаленном хосте в /etc/hosts
не было записи для "localhost", поэтому ssh-сервер не знал, как настроить туннель. Очень недружелюбное сообщение об ошибке для этого случая; рад, что наконец-то разобрался.
Урок: убедитесь, что имя целевого хоста вашего туннеля разрешимо удаленным хостом либо через DNS, либо через /etc/hosts
.
Я крайне удивлен, что никто не упомянул, что это может быть проблемой DNS.
journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)
Это может произойти, если remote
не разрешается или вы ввели неизвестный синтаксис, как я сделал здесь, где я добавил user@
в логику переадресации портов (которая не будет работать).
Еще одна возможная зацепка
У меня возникла такая же проблема при использовании ~/.ssh/authorized_keys
с permitopen
.
Поскольку я использую autossh
для создания туннеля, мне нужно два порта:
Это дало мне аналогичную проблему с портом мониторинга:
autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60 -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote
у меня было такое сообщение (через 10 минут):
channel 2: open failed: administratively prohibited: open failed
Мой /var/log/auth.log
содержал:
Received request to connect to host 127.0.0.1 port 10001, but the request was denied.
В моем ~/.ssh/authorized_keys
(удаленная сторона) я имел следующее:
command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...
Я решил это, заменив localhost
экземпляры на 127. 0.0.0.1
:
command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...
Похоже, что SSH не понимает, что localhost
- это сокращение до 127.0.0.1
, отсюда сообщение в auth.log
и административно запрещено.
Насколько я понимаю, административно означает "из-за специфической конфигурации на стороне сервера".
У меня была такая же проблема, и я понял, что это DNS. Трафик туннелируется, но запрос DNS отсутствует. Попробуйте отредактировать файл хостов DNS вручную и добавить службу, к которой вы хотите получить доступ.
Мой случай:
$ssh -D 8081 localhost >>log1.txt 2>&1 &
----wait for 3 days
$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
$ps axu | grep 8081
root 404 0.0 0.0 4244 592 pts/1 S+ 05:44 0:00 grep --color=auto 8081
root 807 0.3 0.6 8596 6192 ? S Mar17 76:44 ssh -D 8081 localhost
$lsof -p 807 | grep TCP
ssh 807 root 1013u sock 0,8 0t0 2076902 protocol: TCP
ssh 807 root 1014u sock 0,8 0t0 2078751 protocol: TCP
ssh 807 root 1015u sock 0,8 0t0 2076894 protocol: TCP
.....
$lsof -p 807 | wc -l
1047
$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 malcolm-desktop
$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)
----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh 1184 root 3u IPv4 2332193 0t0 TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh 1184 root 4u IPv6 2332197 0t0 TCP ip6-localhost:tproxy (LISTEN)
ssh 1184 root 5u IPv4 2332198 0t0 TCP localhost:tproxy (LISTEN)
ssh 1184 root 6u IPv4 2332215 0t0 TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh 1184 root 7u IPv4 2336142 0t0 TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh 1184 root 8u IPv4 2336062 0t0 TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)
В моем случае проблема была связана с запросом туннеля без доступа к оболочке, в то время как сервер пытался принудительно изменить пароль для моей учетной записи. Из-за отсутствия шелла я не мог этого увидеть и получил только ошибку
channel 2: open failed: administratively prohibited: open failed
Моя конфигурация туннеля была следующей:
ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]
Ошибка проявлялась при входе напрямую на сервер (без -N -f):
WARNING: Your password has expired. You must change your password now
and login again!
Я решил проблему, войдя в систему с доступом к оболочке и изменив пароль. Тогда я мог бы снова просто использовать туннели без доступа к оболочке.
Я получил эту ошибку при написании этой записи в моем блоге:
/etc/ssh/sshd_config
было что-то вроде:
Match Group SSHTunnel_RemoteAccessGroup
AllowTcpForwarding yes
PermitOpen=sshbeyondremote.server.com:22
Но ~/.ssh/config
было:
Host remote.server.com
HostName remote.server.com
Port 10022
User useronremote
IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
LocalForward 2222 SSHBeyondRemote.server.com:22
Обратите внимание на разницу в case(заглавных букв )между SSHBeyondRemote.server.com :22 и sshbeyondremote.server.com :22 .
Как только я устранил проблему, проблема исчезла.
Я использовал:
Версия клиента OpenSSH:
Версия сервера OpenSSH:
Это также может быть вызвано невозможностью привязки к порту на локальной стороне.
ssh -Nn -L 1234:remote:5678 user@remote
Эта команда пытается связать прослушиваемый порт 1234 на локальном компьютере, который сопоставляется со службой на порту 5678 на удаленном компьютере.
Если порт 1234 на локальном компьютере уже используется другим процессом, (возможно, фоновый ssh -f сеанс ), тогда ssh не сможет прослушивать этот порт и туннель не будет работать..
Проблема в том, что это сообщение об ошибке может означать несколько вещей, а фраза «административно запрещена» иногда дает неверное представление. Таким образом, в дополнение к проверке DNS, брандмауэров между локальным и удаленным и конфигурации sshd _, проверьте, не используется ли уже локальный порт. Используйте
lsof -ti:1234
, чтобы выяснить, какой процесс запущен на 1234. Вам может понадобиться sudo, чтобы lsof вывел список процессов, принадлежащих другим пользователям. Затем вы можете использовать
ps aux | grep <pid>
, чтобы выяснить, что это за процесс.
Чтобы получить все это одной командой:
ps aux | grep "$(sudo lsof -ti:1234)"
Другая причина разрешения имен :Мой /etc/hosts имел ошибочный IP-адрес для имени сервера (не для локального хоста ), например:
127.0.0.1 localhost
192.168.2.45 server.domain.com server
Но настроенный IP-адрес сервера (и DNS-имя, разрешенное с помощью команд host/dig ), были 192.168.2.47. Простая опечатка, вызванная предыдущей реконфигурацией IP. После исправления /etc/hosts туннельное соединение работало безупречно:
ssh user@server.domain.com -L 3456:127.0.0.1:5901
Странно, что реальный IP-адрес вызвал сбой, когда я использовал литеральный IP-адрес локального хоста для туннеля. Дистрибутив :Ubuntu 16.04 LTS.
Причина, по которой я получил это сообщение, не самая распространенная, но стоит упомянуть. С помощью скрипта я сгенерировал список туннелей, а для обеспечения столбцового представления я распечатал каждый последний байт на два байта. Когда я пытался открыть туннель с переадресацией на 192.168.66.08, это всегда терпело неудачу, потому что «08» интерпретировалось gethostbyaddr как недопустимое восьмеричное число :)
.Похоже, это сообщение может быть вызвано многими причинами. В моем случае это была невозможность получить доступ к удаленному компьютеру, потому что я неправильно предоставил ключевой файл .
Опция -L
добавляет неявный SSH-переход (, эффективно используя явный SSH-хост в качестве бастиона/сервера перехода ). Это может быть проще отладить, выполнив переход явно и создав оболочку входа на целевую машину с помощью «proxycommand».
Как только это заработает, вы можете выполнить переадресацию портов на основеlocalhost
(целевой машины, предполагая, что она может войти в систему):
-N -L 1234:localhost:1234
Прошивка маршрутизатора Asus RT68U (Merlin Asus )имеет параметр, разрешающий переадресацию портов SSH, который необходимо включить:
Динамическая переадресация портов была настроена, как описано в:Устранение неполадок динамического туннеля
.Проблема может быть связана с именем хоста назначения, если используется эта форма:
ssh -L 12345:destination:54321 tunnelhost
Убедитесь, что «назначение» разрешается из туннельного хоста. Чтобы решить мою проблему, мне пришлось использовать полное доменное имя для цели.
ssh -L 12345:destination.domain.host:54321 tunnelhost