SSH tunneling error: "channel 1: open failed: administratively prohibited: open failed"

  • 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?

    Maybe I'm missing something, but why are you trying to access a web server using a ssh client?

    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.

    I found this to mean "Cannot resolve hostname `remote`" in my case.

    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.

    A DNS resolution failure may cause this error *plus* the connection may freeze until it times out: https://superuser.com/a/700677

    A slight addition to one of the comments above: "A DNS resolution failure may cause this error" -- also make sure you're spelling your hostname correctly. I just spent over an hour trying to debug all the ssh settings and it turns out I had just misspelled `amazonaws` in the command which is equivalent to the DNS resolution failure note above.

    Also, it could be that your server credentials are expired.

  • 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 ensure 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.

    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.

    A corner case to note: You can get this error when trying to create a tap/tun device with SSH and SSH allows it, but the kernel does not. This can occur in LXC containers. See https://blog.felixbrucker.com/2015/10/01/how-to-enable-tuntap-inside-lxc/ for the exact details, but in that case you may want to add `lxc.cgroup.devices.allow = c 10:200 rwm` to your container's config, and ensure that if `/dev/net/tun` does not exist, `mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tun` is run on bootup in the container.

    @Azendale, that's interesting, thanks. Does it yield the exact same error message, or something slightly different?

    @hyperair It's been a bit since I ran into this, but IIRC, yes it is exactly the same.

    I had the same problem with `permitopen` in `~/.ssh/authorized_keys` and solved it. See my answer

    For some reason I had to enable both options in the `sshd_config` for this to work.

    Also make sure the remote actually exists (domain name resolves). I was trying to forward a port to a non-existent AWS snapshot instead of the original instance and was getting the same error.

    One other reason for this behaviour is if the listening port you're trying to open is a privileged port (1-1024 range) and you're not root. I recall on older versions of SSH, it would alert you to this fact when establishing the tunnel. Under newer versions (the one on Ubuntu 16.04), it weirdly enough only alerts you when trying to actually use the tunnel.

    Could you please give a bit of explanation why `AllowTcpForwarding` option makes things work? It looks a bit like magic.

    @St.Antario, `AllowTcpForwarding` allows you to forward TCP ports over SSH, which is what the `-L 0.0.0.0:8984:remote:8983` parameter is requesting. If `AllowTcpForwarding` is set to `no`, SSH will reject the port forwarding request, causing you to see that error.

    I had this problem in `authorized_keys` because I was using `restrict,permitopen="..."`. It turns out that with `restrict` in effect, you must specifically re-enable `port-forwarding` as well as `permitopen` in order to allow that connection to be made. So, I needed `restrict,port-forwarding,permitopen="..." ssh-rsa [...]` in my `authorized_keys` file.

    Tried to edit the upper-case of `AllowTCPForwarding` to `AllowTcpForwarding`, but SE wants at least 6 characters changed. So just noting that the correct case is the `Tcp` version, as used correctly the first time.

    Massive thanks for this answer! `AllowTcpForwarding` was the culprit for me.

  • 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 [email protected]
    

    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.

    Thanks, this was the issue for me. I created the host name for the IP locally but not on the remote ssh server.

    "the target hostname of your tunnel " is a bit hard to decipher. Can you give a concrete workable example that would allow me to take your example and replace the "target hostname" in your example with my target hostname (once I understand what you mean by that) and have this work?

    I'm not even sure your comment makes sense. You say that the remote machine had no entry for localhost. But then say that the remote host must resolve the *target* hostname not the local hostname. Again a complete concrete example of the situation before and after would be helpful.

    @TerrenceBrannon in the command above, "localhost" is the target hostname of the *tunnel*. When creating an SSH tunnel, the ssh command first logs into the remote system (`[email protected]`), then from the remote end, it sets up tunnels to the target hosts listed (in the above command this is `localhost`). When doing this, it uses the hostname resolution scheme on the *remote* host. So if the machine you SSH'd into cannot resolve `localhost`, you'll get this error message.

    In my case, it was as simple as having mistyped the target hostname, so of course it didn't resolve, but my eyes missed seeing the typo for far too long.

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

    No it isn't; I use icmp-admin-prohibited as the reject flag in firewall configs all the time.

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

    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.

    Indeed if "remote" is unreachable - because it's down, offline, doesn't exist, hostname doesn't resolve - then you'll see this error message.

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

    You may also see the same error when using `-D` (DynamicForward) as a SOCKS proxy in a browser. I.e. trying to access a website that the tunnel host can not resolve.

  • 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 [email protected]). 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.

    I came here looking for where to set this ControlMaster multiplex limit. If anyone knows, they are more than welcome to share.

    clacke: according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 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: confirming, MaxSession works, thanks. bumped to 64 on my workbook.

    Be careful, it's not `MaxSession` but `MaxSessions`. Although there are some protections, don't break your ssh server configuration...

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

    Check your iptables settings.

    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.

    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.

    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?

  • In my case, I had to replace localhost with 127.0.0.1 in:

    ssh -L 1234:localhost:3389 [email protected]
    

    to make it work.

    I was trying to rdesktop -L localhost:1234 following Amazon's instructions on connecting to AWS EC2 via SSH tunneling. I had tried to change /etc/ssh/sshd_config (both client and server run Ubuntu 16.04 LTS) per the highest voted answer. I also checked that localhost is in /etc/hosts on both sides.

    Nothing worked until I changed the ssh command itself to:

    ssh -L 1234:127.0.0.1:3389 [email protected]
    

    Same, and I wish I knew whyyyy!

  • A similar problem

    Another possible lead

    I had the same problem using ~/.ssh/authorized_keys with permitopen.

    As I use autossh to create a tunnel, I need two ports:

    • one for connection (10000),
    • one for monitoring (10001).

    On client side

    This gave me a similar problem with monitoring port:

    autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa [email protected]
    

    I had that message (after 10 minutes):

    channel 2: open failed: administratively prohibited: open failed
    

    On remote side

    My /var/log/auth.log contained:

    Received request to connect to host 127.0.0.1 port 10001, but the request was denied.
    

    In my ~/.ssh/authorized_keys (remote side) I had this:

    command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...
    

    How to solve it

    I solved this by replacing localhost instances with 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...
    

    It seems that SSH does not understand that localhost is a shortcut to 127.0.0.1, hence the message in auth.log and the administratively prohibited message.

    What I understand here is that administratively means "due to a specific configuration on server side".

    localhost likely mapped to ::1 (ipv6) and you weren't listening there for some reason

  • This also happens when /etc/sshd_config has

    AllowTcpForwarding no 
    

    set. Switch it to yes to allow TCP forwarding.

  • This can also be caused by being unable to bind to the port on the local side.

    ssh -Nn -L 1234:remote:5678 [email protected]
    

    This command is trying to bind a listening port 1234 on the local machine, which maps to a service on port 5678 on a remote machine.

    If port 1234 on the local machine is already in use by another process, (maybe a background ssh -f session), then ssh will not be able to listen on that port and the tunnel will fail.

    The problem is that this error message can mean any of several things, and "administratively prohibited" gives the wrong idea sometimes. So in addition to checking DNS, firewalls between local and remote, and sshd_config, check to see if the local port is already used. Use

    lsof -ti:1234
    

    to figure out what process is running on 1234. You might need sudo for lsof to list processes owned by other users. Then you can use

    ps aux | grep <pid>
    

    to find out what that process is.

    To get this all in one command:

    ps aux | grep "$(sudo lsof -ti:1234)"
    

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM