ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983
尝试访问在localhost：8984上运行的HTTP服务器时出现此错误：
channel 1: open failed: administratively prohibited: open failed
此错误是什么意思，您可以在哪台计算机上解决该问题？
#1 楼
通道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/authorized_keys中的SSH密钥相对应的条目是否正确没有no-port-forwarding或permitopen语句[2]。如果您尝试使用-w选项，则
PermitTunnel选项与您的特定命令无关，但也与此主题相关。 [1]
sshd_config(5)联机帮助页中的完整语法。[2]
authorized_keys(5)联机帮助页中的完整语法。评论
在这里，我专门在sshd_config中添加了一些内容以使其正常工作：TCPKeepAlive是AllowTCPForwarding是PermitOpen任何我有一些“打开失败”的现象，但这似乎是正常的事情。事情做得很好。
–皮埃尔·蒂博（Pierre Thibault）
2015年1月17日在6:58
需要注意的一个极端情况：尝试使用SSH创建Tap / Tun设备并且SSH允许它时，会出现此错误，但是内核却不允许。这可能发生在LXC容器中。有关确切的详细信息，请参见blog.felixbrucker.com/2015/10/01/…，但在这种情况下，您可能需要将lxc.cgroup.devices.allow = c 10：200 rwm添加到容器的配置中，并确保/ dev / net / tun不存在，mknod / dev / net / tun c 10 200; chmod 666 / dev / net / tun在启动时在容器中运行。
–阿岑代尔
16年4月16日在0:58
@Azendale，这很有趣，谢谢。它会产生完全相同的错误消息，还是略有不同？
–高空
16年5月10日在7:52
@ St.Antario，AllowTcpForwarding允许您通过SSH转发TCP端口，这是-L 0.0.0.0:8984:remote:8983参数所请求的。如果AllowTcpForwarding设置为no，SSH将拒绝端口转发请求，从而导致您看到该错误。
–高空
18-11-12在11:20
尝试将大写的AllowTCPForwarding编辑为AllowTcpForwarding，但是SE希望至少更改6个字符。因此，请注意，正确的大小写是Tcp版本，因为它是第一次正确使用。
– dbreaux
19年4月12日在19:56
#2 楼
在一个非常奇怪的情况下，我在尝试创建本地隧道时也遇到了此错误。我的命令是这样的：ssh -L 1234:localhost:1234 user@remote
问题是，在远程主机上，
/etc/hosts没有“ localhost”的条目，因此ssh服务器不知道如何设置隧道。这种情况下非常不友好的错误消息；很高兴终于找到了答案。课程：确保远程主机可以通过DNS或
/etc/hosts解析隧道的目标主机名。评论
谢谢，这是我的问题。我在本地创建了IP的主机名，但没有在远程ssh服务器上创建。
– dev_feed
16-4-20在12:29
“您的隧道的目标主机名”很难解读。您能否举一个具体可行的示例，让我以您的示例为例，然后用我的目标主机名替换您的示例中的“目标主机名”（一旦我理解您的意思），然后进行这项工作？
–特伦斯·布兰农（Terrence Brannon）
17年5月12日在10:42
我什至不确定您的评论是否有意义。您说远程计算机没有本地主机的条目。但是然后说，远程主机必须解析目标主机名而不是本地主机名。再次提供前后具体情况的完整具体示例将有所帮助。
–特伦斯·布兰农（Terrence Brannon）
17年5月12日在10:44
上面命令中的@TerrenceBrannon，“ localhost”是隧道的目标主机名。创建SSH隧道时，ssh命令首先登录到远程系统（user @ remote），然后从远端设置到列出的目标主机的隧道（在上面的命令中，这是localhost）。这样做时，它将在远程主机上使用主机名解析方案。因此，如果您通过SSH登录的计算机无法解析localhost，则会收到此错误消息。
– cobbzilla
17年8月16日在5:30
就我而言，这就像输入目标主机名一样简单，因此当然它不能解决，但是我的眼睛太久没看到错字了。
–兰德尔
18年3月24日在19:19
#3 楼
至少一个答案是由于某种原因，ssh无法访问机器“ remote”。错误消息只是荒谬的。评论
不，不是。我一直在防火墙配置中使用icmp-admin-prohibited作为拒绝标志。
– Shadur
2011年6月1日19:29
+1，在管理上受禁止的消息将使您认为这是防火墙的阻塞，但是，在没有防火墙的阻塞但打开失败的情况下，由于没有到远程主机的路由，您会收到相同的消息。
–史蒂夫·布佐纳斯（Steve Buzonas）
2012年6月2日在21:04
我刚刚花了几分钟寻找这个问题，在我看来，该问题的消息毫无意义。值得庆幸的是，在检查中间站日志文件时，它非常清楚。
– JanMatějka
2013年6月10日20:46
的确，如果“远程”无法访问-因为它已关闭，离线，不存在，主机名无法解析-那么您将看到此错误消息。
–迈克尔·马丁内斯（Michael Martinez）
2015年9月8日在22:39
#4 楼
如果无法在服务器上解析“远程”，则将收到该错误。替换为IP地址，看看是否可以解决您的问题...（与Neil的回答基本相同-但我当然发现这是我的问题）[我有一个别名我的
~/.ssh/config文件中的机器名称-远程机器完全不知道该别名... 评论
在浏览器中将-D（DynamicForward）用作SOCKS代理时，您可能还会看到相同的错误。即尝试访问隧道主机无法解析的网站。
–timss
16年9月2日在9:05
#5 楼
当您使用ssh选项ControlPath和ControlMaster共享一个套接字连接以在多个客户端连接（从一个客户端到同一user @ server）之间重用时，肯定会弹出此错误。打开太多（在我的情况下，〜20个连接意味着什么）会产生此消息。关闭以前的所有连接，就可以再打开一次，达到上限。评论
我来到这里寻找在哪里设置ControlMaster多路复用限制。如果有人知道，欢迎与他们分享。
–clacke
13年7月17日在0:55
clacke：根据bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854的说明，您可以在/ etc / ssh / sshd_config文件中添加MaxSession参数来进行设置。根据手册页，默认情况下设置为10。
– oliver
13-10-23在10:36
@oliver：确认，MaxSession有效，谢谢。在我的工作簿上升至64。
–马特·科瓦奇（Matej Kovac）
2014年4月3日在8:58
请注意，它不是MaxSession，而是MaxSessions。尽管有一些保护措施，但不要破坏您的ssh服务器配置...
–StéphaneGourichon
2015年1月30日14:36
#6 楼
就我而言，我必须将localhost替换为127.0.0.1：ssh -L 1234:localhost:3389 user@remote
以使其正常工作。
我正尝试跟随Amazon的
rdesktop -L localhost:1234通过SSH隧道连接到AWS EC2的说明。我曾尝试根据投票最高的答案来更改/etc/ssh/sshd_config（客户端和服务器均运行Ubuntu 16.04 LTS）。我还检查了双方的localhost是否在/etc/hosts中。 在将
ssh命令本身更改为以下命令之前，什么都没有起作用：ssh -L 1234:127.0.0.1:3389 user@remote
评论
一样，我希望我知道为什么！
– NateS
20 Mar 13 '20 at 0:40
#7 楼
“管理员禁止”是特定的ICMP消息标志，其归结为“管理员明确希望此连接被阻止”。检查您的iptables设置。
评论
不必要。当主机无法处理请求时，将生成该消息。这种情况通常是因为管理员已阻止连接，但也可能是它没有被明确阻止，但没有通往所需主机的路由。 AFAIK ssh没有逻辑来确定连接失败的原因，它只是假设如果您尝试连接，则说明存在该连接，并且如果您无法到达该连接，则必须故意阻止了该连接。
–史蒂夫·布佐纳斯（Steve Buzonas）
2012年6月2日21:11
嗯不ICMP响应的类型为“无通往主机的路由”和“管理上禁止”的类型之间存在明显区别，除非有人故意对路由器进行了错误配置，否则后者的含义与在路由器上所说的完全相同。
– Shadur
2014年1月3日23:07
当我使用无法解析的主机名时，我只是被“行政上禁止”，因此这似乎是万能的。也许ssh正在做一些翻译？
–GS-向Monica道歉
2014年9月23日下午5:38
#8 楼
当/etc/sshd_config设置了AllowTcpForwarding no
时，也会发生这种情况。将其切换到
yes以允许TCP转发。 #9 楼
一个类似的问题另一个可能的引线
我在将
~/.ssh/authorized_keys与permitopen结合使用时遇到了同样的问题。当我使用
autossh创建隧道时，我需要两个端口：一个用于连接（10000），
一个用于监视（10001）。
在客户端
这给监视端口带来了类似的问题：
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.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中的消息和受到行政禁止的消息。我在这里理解的是，管理上的含义是“到期到服务器端的特定配置”。
评论
本地主机可能映射到:: 1（ipv6），并且由于某种原因您没有在那儿听
– Jo Rhett
17-10-23在22:29
#10 楼
需要一些故障排除活动才能找到明确的答案：检查是否在用户的ssh配置中启用了端口转发，
启用ssh（-v）的详细信息，
在本地主机上检查ssh日志，在远程主机上检查安全日志，
测试其他远程端口，
检查您的iptables设置（如Shadur所说）。
#11 楼
我曾经因为将遥控器放在-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.
#12 楼
我很惊讶没有人提到这可能是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@（这不起作用）。#13 楼
这也可能是由于无法绑定到本地端上的端口引起的。ssh -Nn -L 1234:remote:5678 user@remote
此命令试图绑定本地计算机上的侦听端口1234，该端口映射到远程计算机上端口5678上的服务。
如果本地计算机上的端口1234已被另一个进程使用（可能是后台ssh -f会话），则ssh将无法在该端口上侦听，并且隧道将失败。
问题是，此错误消息可能表示几项内容，并且“行政上禁止”有时会给出错误的主意。因此，除了检查DNS，本地与远程之间的防火墙以及sshd_config外，还要检查本地端口是否已被使用。使用
lsof -ti:1234
找出1234上正在运行的进程。您可能需要sudo来使lsof列出其他用户拥有的进程。然后，您可以使用
ps aux | grep <pid>
找出该过程是什么。
要在一个命令中获得全部信息：
ps aux | grep "$(sudo lsof -ti:1234)"
#14 楼
尝试建立隧道时，我有相同的消息。远端的dns伺服器发生问题。恢复工作后，问题已解决。#15 楼
就我而言，问题是由于在服务器旨在强行更改我的帐户的同时，请求没有外壳访问权限的隧道。由于缺少外壳，我看不到它，仅收到错误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!
我通过登录解决了该问题通过shell访问并更改密码。然后，我可以简单地使用隧道，而无需再次访问shell。
#16 楼
尝试通过SSH与仅被授权使用SFTP进行连接的用户进行连接时，出现了此问题。例如，这在服务器的/etc/ssh/sshd_config中：Match group sftponly
ForceCommand internal-sftp
ChrootDirectory /usr/chroot/%u
[...]
Match
因此，在这种情况下，要使用SSH，您将必须从等效的
sftponly组中删除该用户，或者使用不限于SFTP的用户进行连接。#17 楼
检查/etc/resolv.conf所指向的服务器上的ssh是否为空。几次我发现这与一个空的/etc/resolv.conf文件有关如果不是root用户，则可以通过在公共主机名上尝试一些
ping或telnet（80）来检查服务器，即：root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known
将名称服务器记录添加到
/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为空（如果适用，通常由服务器上的dhcp客户端使用名称服务器记录填充该记录。#18 楼
SSH隧道传输到Debian时，我收到了相同的消息。事实证明，远程系统没有可用空间。释放一些磁盘空间并重新启动后，隧道开始工作。#19 楼
我在cygwin上看到了这个错误，这在Linux上也应该如此，并为我工作。在我的情况下，我已经完成ssh -ND *：1234 user@127.0.0.1，并且当我将浏览器连接到该comp-socks服务器时，它进行了浏览，但是在我运行该ssh命令的comp上，出现了该错误每个请求的控制台-至少针对一个站点，尽管浏览器是通过代理检索到的，或者至少在我看到主流时代的程度上如此。但是进行此更改可以消除失败的消息http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/
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
评论
默认情况下会启用AFAIK隧道，因为禁用不会添加任何安全层，主要只是添加第三方隧道带来的不便。我在尝试从异地位置代理到内部服务器时遇到了类似的问题，并且启用了隧道+ iptables已使用默认操作刷新为ACCEPT。
–史蒂夫·布佐纳斯（Steve Buzonas）
2012年6月2日，3：09
@SteveBuzonas我在/ etc / sshd_config中看到了这一点，因此a）它不会禁用隧道b）关于我的回答，解决方案可能不是一个好主意。这是sshd_config关于该选项的内容＃要禁用隧道明文密码，请在此处更改为no！ #PermitTunnel否
– barlop
2012年6月2日上午8:05
@SteveBuzonas检查您的那一台，它可能设置为no，并且您可以进行隧道传输，因为默认情况下确实启用了隧道。
– barlop
2012年6月2日上午8:06
我当时正在考虑AllowTCPForwarding，您正在谈论的注释＃禁用隧道明文是关于PasswordAuthentication设置为no，PermitTunnel是一种允许通过tun / tap允许第2层或第3层网络隧道的设置，默认值为no。 L，R和D选项使用TCP转发而不是用于隧道的设备。
–史蒂夫·布佐纳斯（Steve Buzonas）
2012年6月2日21:00
#20 楼
另一种情况是您尝试访问的服务未运行。前几天，我遇到了这个问题，只是想起我尝试连接的httpd实例已停止。解决问题的步骤将从最简单的开始，这是连接另一台计算机，看看您是否可以本地连接，然后再使用自己的客户端计算机。至少这将使您能够确定通信未发生的时间点。您可以采用其他方法，但这对我有用。
评论
一个有用的一般提示，但不能解决所提出的问题。
–凯尔·琼斯（Kyle Jones）
2012年11月19日下午6:24
#21 楼
检查路由器的DNS重新绑定保护。我的路由器（pfsense）默认情况下启用了DNS重新绑定保护。导致使用SSH的“通道打开：管理上失败：打开失败”错误#22 楼
我有同样的问题，我意识到这是DNS。流量通过隧道传输，但是DNS请求没有。尝试手动编辑DNS主机文件并添加您要访问的服务。#23 楼
我的情况：$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)
#24 楼
我在博客中写此条目时遇到此错误：/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
请注意SSHBeyondRemote.server.com:22和sshbeyondremote.server.com:22之间大小写（大小写）的区别。情况下，我再也没有看到此问题。
我正在使用：
OpenSSH客户端的版本：
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4，OpenSSL 1.0.2g 2016年3月1日
OpenSSH服务器的版本：
OpenSSH_7.6p1 Debian-4，OpenSSL 1.0.2n 2017年12月7日
评论
如果您要链接，宣传，引用或引用您所隶属的事物，则必须明确披露该隶属关系。只说“边放（链接）时”是不够的（因为直到弄清楚您要链接到自己的博客后，我才理解它的含义）；仅提供一个与您的StackExchange用户名相匹配的URL是不够的。参考资料：如何成为垃圾邮件发送者，避免公开自我宣传，…（续）
–斯科特
18-3-27在19:25
（续）...，我们应何时执行从属关系要求？您可以在用户资料页面中自由提及自己的博客，雇主，开发的任何知名软件，编写的书籍，与您有联系或与之有关联的任何其他项目，等等。 。
–斯科特
18 Mar 27 '18 at 19:25
#25 楼
其他名称解析原因：我的/ etc / hosts的服务器名称（而不是localhost）的IP地址错误，例如：127.0.0.1 localhost
192.168.2.45 server.domain.com server
但是配置服务器IP（以及使用host / dig命令解析的DNS名称）为192.168.2.47。由先前的IP重新配置引起的简单错字。修复/ etc / hosts后，隧道连接可以正常工作：
ssh user@server.domain.com -L 3456:127.0.0.1:5901
当我在隧道中使用本地localhost IP时，真实IP导致失败很奇怪。发行版：Ubuntu 16.04 LTS。
#26 楼
我收到该消息的原因不是最常见的，但值得一提。我已经通过脚本生成了一个隧道列表，并且为了确保列显示，我在两个字节上打印了每个最后一个字节。当我尝试打开到192.168.66.08的隧道转发时，它总是失败，因为gethostbyaddr将'08'解释为无效的八进制数字:)#27 楼
似乎此消息有很多可能的根本原因。在我的情况下，因为我没有正确提供密钥文件，所以无法访问远程服务器。-L选项添加了一个隐式SSH跳转（有效地使用显式SSH主机作为堡垒/跳转服务器） ）。通过显式执行跳转并使用“ proxycommand”创建到目标计算机的登录外壳，可能更容易调试此问题。一旦成功，就可以基于目标计算机的端口转发端口
localhost（假设它可以自行登录）：-N -L 1234:localhost:1234
#28 楼
Asus RT68U路由器的固件（Merlin Asus）具有允许进行SSH端口转发的设置，必须启用该设置：
如下面所述设置了动态端口转发：Dyamic隧道故障排除
评论
也许我丢失了一些东西，但是为什么要尝试使用ssh客户端访问Web服务器？为什么在这里转发X11（-X选项）？如果只想转发HTTP，则没有必要。另外，恕我直言，恕我直言ssh可能是使Web服务器在多个端口上可用的错误解决方案。
我发现这意味着“无法远程解析主机名”。
从下面的十二个答案中可以看出，该错误消息尽管看起来非常具体，但仍应理解为一般错误。通常，解决方案是在远程服务器上打开一个外壳并尝试相同的连接，以查看实际原因。您将在以下最常见的实际原因中找到答案。
DNS解析失败可能会导致此错误，并且连接可能会冻结直到超时：superuser.com/a/700677