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 :


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


13 thoughts on “channel 3: open failed: administratively prohibited: open failed

  1. Hi All,

    We have SFTP client library[3rd party] which Fails to connect to the sftp server [use password authentication].

    From 3rd party log file I can see that SSH/SFTP authentication is successs but ssh channel open is failed ….

    3rd party library first creates ssh tunnel and then cretaes a channel and then open a sftp-subsystem

    I can see that ssh tunnel is create successfuly , but channel open is
    failed , this may be the user doesn’t have ssh access to that server .

    I can do manual sftp using command but SSH also failed
    sftp syeds@ works
    ssh syeds@ Fails
    OS: Linux

    But why manuly sftp command working fine ?

  2. In my case, the DNS nameserver address contained in /etc/resolv.conf on the remote host was having some issues. After I changed the ‘nameserver’ parameter to it all worked smoothly as ever.

  3. try checking /var/log/auth.log for errors form sshd. In my case I found the problem there, my tunnels were specifying the service name “tika:9998” when they needed to be localhost:9998 because i was connecting to services on local host and tika was being interpreted as a hostname.

  4. This solution did not work for me. I was getting the error “channel 3: open failed: administratively prohibited: open failed”

    So I tried what you suggest, with “echo “PermitTunnel yes” >> /etc/ssh/sshd_config” but I still got the same error. And I don’t have SELinux.
    I did look into /var/log/auth.log as Jimbo Jones suggested and notice some mention of sshd and error: connect_to … unknown host (Name or service not known) this showed the hostname alias that I use on my local machine. (as in ssh -L 7777:hostname:443 root@hostname) So, I added that same hostname to the /etc/hosts of the remote machine and viola, finally worked! 😀

    After I went into sshd_config and removed the PermitTunnel just to see if that was necessary and it turned out it was not. The remote server is debian and the local computer ubuntu

    Even though your solution didn’t work in my case it did lead me to the answer, so thanks for that. And hopefully if anyone else has my situation hopefully writing this may help them.

  5. The most common thing we’ve seen for our clients is that they need to restart SSH.
    Sometimes this also happens from a stable or inactive tunnel and may go away after you start transferring data over it for a few seconds or minutes.

    If the above doesn’t help restarting the SSH server as this blog article is often a surefire fix even without using the PermitTunnel setting. It seems like there is probably some bug in the SSH daemon that causes tunnels to stop working after some time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.