Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

When I open this ssh tunnel:

ssh -nXNT -p 22 localhost -L

I get this error when trying to access the HTTP server running on localhost:8984:

channel 1: open failed: administratively prohibited: open failed

What does this error mean, and on which machine can you fix the problem?

share|improve this question
Maybe I'm missing something, but why are you trying to access a web server using a ssh client? – Faheem Mitha Jun 1 '11 at 17:00
Why are you forwarding X11 (-X option) here? If you want to only forward HTTP this is not necessary. And as a side note IMHO ssh might be the wrong solution to make a Webserver available on multiple ports. – Marcel G Jun 3 '11 at 9:16
I found this to mean "Cannot resolve hostname remote" in my case. – RobM Apr 22 '13 at 16:56
As you can see from the dozen of answers below, the error message, despite looking very specific, should be understood as a generic error. Generally, the solution is to open a shell at the remote and try the very same connection, to see the actual cause. You will find in answers below the most common actual causes. – Stéphane Gourichon Jan 31 at 7:49

17 Answers 17

Check your router for DNS Rebinding protection. My router (pfsense) has DNS Rebinding Protection Enabled by default. It was causing the 'channel open: failed administratively prohibited: open failed' error with SSH

share|improve this answer

I was getting the same message while SSH tunelling to Debian. It turned out the remote system had no free space. After freeing up some disk space and rebooting, the tunnel started working.

share|improve this answer

Check if /etc/resolv.conf is empty on the server you're ssh-ing to. Several times I found this to be related to an empty /etc/resolv.conf file

If non root, you can just check on the server by trying some ping or telnet (80) on a public hostname, i.e.:

root@bananapi ~ # telnet 80
telnet: could not resolve Name or service not known

After adding nameserver records to /etc/resolv.conf:

root@bananapi ~ # telnet 80
Connected to
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found

However, you should also check why /etc/resolv.conf was empty (this is usually populated with nameserver records by the dhcp client on the server, if applicable.

share|improve this answer

I had this problem when trying to connect via SSH with a user that was only authorized to connect using SFTP.

For example, this was in the server's /etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u

So in this case, to use SSH, you will have to either remove the user from the equivalent sftponly group or connect using a user that is not limited to SFTP.

share|improve this answer

In a very weird case, I also experienced this error while trying to create a local tunnel. My command was something like this:

ssh -L 1234:localhost:1234 user@remote

The problem was, on the remote host, /etc/hosts had no entry for "localhost" so the ssh server didn't know how to setup the tunnel. A very unfriendly error message for this case; glad I finally figured it out.

The lesson: make sure the target hostname of your tunnel is resolvable by the remote host, either via DNS or /etc/hosts.

share|improve this answer

I had the same message while trying to tunnel. There was a problem with the dns server on the remote side. The problem was solved when it came back to work.

share|improve this answer

If the 'remote' cannot be resolved on the server you will get that error. Replace with an IP address and see if that resolves your issue...

(Basically same answer as that of Neil - but I certainly found that to be the issue on my side) [I had an alias for the machine name in my ~/.ssh/config file - and the remote machine knew nothing of that alias...

share|improve this answer

This also happens when /etc/sshd_config has

AllowTcpForwarding no 

set. Switch it to yes to allow TCP forwarding.

share|improve this answer

This error definitively pops up when you use ssh options ControlPath and ControlMaster for sharing one socket connection to be reused between several client connections (from one client to the same user@server). Opening too many (whatever it means, in my case ~20 connections) yields this message. Closing any previous connections lets me open newer, again up to the limit.

share|improve this answer
I came here looking for where to set this ControlMaster multiplex limit. If anyone knows, they are more than welcome to share. – clacke Jul 17 '13 at 0:55
clacke: according to you can add a MaxSession parameter in /etc/ssh/sshd_config file to set this. According to man page, this is set to 10 by default. – oliver Oct 23 '13 at 10:36
@oliver: confirming, MaxSession works, thanks. bumped to 64 on my workbook. – Matej Kovac Apr 3 '14 at 8:58
Be careful, it's not MaxSession but MaxSessions. Although there are some protections, don't break your ssh server configuration... – Stéphane Gourichon Jan 30 at 14:36

channel 1: open failed: administratively prohibited: open failed

The above message refers to your SSH server rejecting your SSH client's request to open a side channel. This typically comes from -D, -L or -w, as separate channels in the SSH stream are required to ferry the forwarded data across.

Since you are using -L (also applicable to -D), there are two options in question that are causing your SSH server to reject this request:

  • AllowTcpForwarding (as Steve Buzonas mentioned)
  • PermitOpen

These options can be found in /etc/ssh/sshd_config. You should check that:

  • AllowTCPForwarding is either not present, is commented out, or is set to "yes"
  • PermitOpen is either not present, is commented out, or is set to "any"[1]

Additionally, if you are using an SSH key to connect, you should check that the entry corresponding to your SSH key in ~/.ssh/authorized_keys does not have no-port-forwarding or permitopen statements[2].

Not relevant to your particular command, but somewhat relevant to this topic as well, is the PermitTunnel option if you're attempting to use the -w option.

[1] Full syntax in the sshd_config(5) manpage.

[2] Full syntax in the authorized_keys(5) manpage.

share|improve this answer
Here what I specifically add in sshd_config to make it work: TCPKeepAlive yes AllowTCPForwarding yes PermitOpen any I have a few "open failed" but it seems a normal thing. Things work very well. – Pierre Thibault Jan 17 at 6:58

I got this error once for putting the remote in the -L parameter, also the is redundant you can omit it with the same results, and I think you should add the -g for it to work.

This is the line I use for tunneling: 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.
share|improve this answer

One other scenario is that the service you are trying to access is not running. I ran into this issue the other day only to remember the httpd instance I was trying to connected to had been stopped.

Your steps to resolving the problem would be to start with the simplest, which is going to the other machine and seeing if you can connect locally and then working yourself back towards your client computer. At least this will allow you to work out at what point the communication is not happening. You can take other approaches, but this is one that worked for me.

share|improve this answer
A useful general tip but not an answer to the question posed. – Kyle Jones Nov 19 '12 at 6:24

I saw this error on cygwin and this should be true of linux too and worked for me. In my case i'd done ssh -ND *:1234 user@ and when I connected a browser to that comp-socks server , it browsed, but on the comp where I ran that ssh command I got that error appearing at the console with each request - for one site at least, though the browser retrieved it through the proxy or seemed to, at least to the extent that I saw the main age. But making this change got rid of the failed message

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 :
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

root@remote-server:~# /etc/init.d/ssh restart
share|improve this answer
AFAIK tunneling is enabled by default because disabling doesn't add any layer of security, primarily just an inconvenience of adding a 3rd party tunnel. I am having a similar problem trying to proxy to internal servers from an off site location and tunneling is enabled + iptables flushed with default action to ACCEPT. – Steve Buzonas Jun 2 '12 at 3:09
@SteveBuzonas I see this in /etc/sshd_config so a)it doesn't disable tunneling b)as regards my answer, the solution there may not be a good idea. Here is what sshd_config says about that option # To disable tunneled clear text passwords, change to no here! #PermitTunnel no – barlop Jun 2 '12 at 8:05
@SteveBuzonas check your one it probably is set to no and you can tunnel as indeed tunneling is enabled by default. – barlop Jun 2 '12 at 8:06
I was thinking of AllowTCPForwarding, The comment you are talking about # To disable tunneled clear text is in regards to PasswordAuthentication being set to no, PermitTunnel is a setting to allow layer 2 or layer 3 networking tunnels via tun/tap and defaults to no. The L, R, and D options use TCP forwarding and not a device for tunneling. – Steve Buzonas Jun 2 '12 at 21:00

Administratively prohibited generally means you've been blocked by a firewall or equivalent control software. This will be somewhere between localhost and remote.

When you connect to the local endpoint on localhost, the other end of the ssh tunnel (also on localhost) will try to establish a connection to remote:8983. This is what is being blocked. You should find that if you try to connect from localhost to remote:8983 with a web browser, you should also get an error (although it may not display "Administratively prohibited").

The connection is not being blocked before reaching the ssh tunnel, since the "channel 1: open failed" error message is coming from ssh.

To find out where the connection is being blocked, use a recent version of traceroute(1) that can use TCP (or install tcptraceroute):

# traceroute -T -p 8983 remote

That should tell you at which point your connection is being blocked.

share|improve this answer
Ooo, didn't know that about latest traceroute. Upvoting. – Shadur Jun 3 '11 at 8:53
+1 Didn't know traceroute could be an effective tool to debug service gaps from a proxy. Lead me to realize that my overall problem was the machine serving the proxy could not resolve the address. – Steve Buzonas Jun 2 '12 at 3:19

Some troubleshooting activity is needed to find a definitive answer:

  • check that port forwarding is enabled in user's ssh configuration,
  • enable verbosity of ssh (-v),
  • check ssh logs on local host and secure logs on remote one,
  • test different remote port,
  • check your iptables settings (as Shadur said).
share|improve this answer

"administratively prohibited" is a specific ICMP message flag that boils down to "The administrator explicitly wants this connection blocked".

Check your iptables settings.

share|improve this answer
Not necessarily. The message is generated when the host cannot serve the request. The case is generally because the admin has blocked the connection, but it can also be that is it not explicitly blocked but there is no route to the desired host. AFAIK ssh has no logic to determine why a connection failed, it just assumes that if you are trying to connect, then it exists, and if you can't get there the connection must have been blocked intentionally. – Steve Buzonas Jun 2 '12 at 21:11
Uh, no. There is a distinct difference between the type of ICMP response that says "no route to host" and one that says "administratively prohibited", and unless someone deliberately misconfigured a router, the latter means exactly what it says on the tin. – Shadur Jan 3 '14 at 23:07
I just got 'administratively prohibited' when using a hostname that didn't resolve, so it does seem to be a catch-all. Perhaps ssh is doing some translation? – Ganesh Sittampalam Sep 23 '14 at 5:38

At least one answer is that the machine "remote" is unreachable with ssh for some reason. The error message is just absurd.

share|improve this answer
No it isn't; I use icmp-admin-prohibited as the reject flag in firewall configs all the time. – Shadur Jun 1 '11 at 19:29
+1, The administratively prohibited message would cause one to believe that it is a firewall blockage, however you receive the same message when there is no firewall blockage but the open fails because there is no route to the remote host. – Steve Buzonas Jun 2 '12 at 21:04
I have just spent several minutes hunting this problem, whose message doesn't make any sense in my context down. Thankfully it's pretty clear upon checking the middle station log files. – yaccz Jun 10 '13 at 20:46
Indeed if "remote" is unreachable - because it's down, offline, doesn't exist, hostname doesn't resolve - then you'll see this error message. – Michael Martinez Sep 8 at 22:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.