channel 3: open failed: administratively prohibited: open failed

Posted: February 18, 2010 in Administration, Debian, Troubleshooting
Tags: , , , , , , ,

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

About these ads
Comments
  1. Jay Goldberg says:

    Might I also comment, PermitTunnel is an SSHD _server_ parameter, and thus should go in /etc/ssh/sshd_config.

  2. Also, if SELinux is in enforcing mode, you may need to enable the sshd_forward_ports boolean so that SELinux doesn’t prevent sshd from establishing a tunnel::
    sudo setsebool -P sshd_forward_ports 1
    —-
    Larry O’Leary

    http://profiles.google.com/larryoleary

  3. syed says:

    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@10.18.20.13 works
    ssh syeds@10.18.20.13 Fails
    OS: Linux

    But why manuly sftp command working fine ?

  4. dan pritts says:

    in my case, the problem was that I’d typoed the name of the end host that i was tunneling to.

  5. singhgurjeet says:

    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 8.8.8.8 it all worked smoothly as ever.

  6. Jimbo Jones says:

    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.

  7. John Cant says:

    Caused the error in my case:

    Fails: —– ssh -L 1234:remote.com:1234 user@remote.com

    Works: —– ssh -L 1234:localhost:1234 user@remote.com

  8. bikerusl says:

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

    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.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s