SSH tunneling error: “channel 1: open failed: administratively prohibited: open failed”

Question

When I open this ssh tunnel:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

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?

Answer 1

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.

Answer 2

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

Check your iptables settings.

Answer 3

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).

Answer 4

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.

Answer 5

I got this error once for putting the remote in the -L parameter, also the 0.0.0.0 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.

Answer 6

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.

Answer 7

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

Answer 8

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@127.0.0.1 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

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

Answer 9

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.