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?

Maybe I'm missing something, but why are you trying to access a web server using a ssh client? — Faheem Mitha, Jun 01 '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 03 '11 at 09: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 '15 at 07:49
A DNS resolution failure may cause this error plus the connection may freeze until it times out: https://superuser.com/a/700677 — user423430, Mar 24 '17 at 17:12
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. — Brad Dwyer, Apr 16 '18 at 15:04
In my case it was paired with Escape character is '^]'. Connection closed by foreign host. client side, which suggested that the connection was actually established but dropped immediately. After a while - it turned out to be that nothing was listening on the forwarded port. — tishma, May 23 '22 at 19:22
Another cause of hostname lookup failure on the intermediate system is if it's a CentOS system with systemd, and the /etc/nsswitch.conf file includes myhostname for the hosts: entry. The myhostname extension is systemd's attempt to be smart, and it fails miserably and causes hostname failures. Remove the myhostname (so that the line looks something like hosts: files dns or similar) and then try running a host remote_system_name lookup on its command line. With myhostname it fails, without it everything works. — Ti Strga, Sep 06 '22 at 19:10

score 214 · Answer 1 · edited Feb 25 '22 at 02:38

214

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.

edited Feb 25 '22 at 02:38

slm

369,824

answered Dec 18 '12 at 09:39

hyperair

2,366

1

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 '15 at 06:58
7

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 Apr 16 '16 at 00:58
@Azendale, that's interesting, thanks. Does it yield the exact same error message, or something slightly different? – hyperair May 10 '16 at 07:52
@hyperair It's been a bit since I ran into this, but IIRC, yes it is exactly the same. – Azendale May 10 '16 at 21:36
I had the same problem with permitopen in ~/.ssh/authorized_keys and solved it. See my answer – lauhub Jul 22 '16 at 10:34
1

For some reason I had to enable both options in the sshd_config for this to work. – erikbstack May 08 '17 at 18:56
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. – Nic Nilov Sep 13 '17 at 12:08
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. – Ferry Boender Oct 03 '17 at 19:32
Could you please give a bit of explanation why AllowTcpForwarding option makes things work? It looks a bit like magic. – St.Antario Nov 11 '18 at 10:55
2

@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. – hyperair Nov 12 '18 at 11:20
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. – Christopher Schultz Nov 21 '18 at 16:59
2

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. – dbreaux Apr 12 '19 at 19:56
Massive thanks for this answer! AllowTcpForwarding was the culprit for me. – scubbo May 06 '19 at 14:08
TIP: use egrep -v '^#' /etc/ssh/sshd_config to see only uncommented lines – Rafael Gomes Francisco Dec 18 '20 at 22:52
Like @erikbstack mentioned, explicitly enabling both option only worked. – SANN3 Feb 01 '22 at 12:59
Can confirm that the server in b/w the initiating SSH client and the final destination SSH server needed to have TCPKeepAlive yes and AllowTcpForwarding yes. I was making use of the ProxyJump feature in my SSH client's config. – slm Feb 25 '22 at 02:41
CentOS 7: AllowTcpForwarding yes + PermitTunel yes + service sshd restart worked for me to make a tunnel with: ssh -D 8123 -C -N root@<IP> – DenisKolodin Apr 15 '22 at 09:46
In my case AllowTCPForwarding was yes but for root and admin users. While my user was in admin group it still didn't work. Added the same settings for user, restarted and everything runs. – Mike Menko Apr 24 '23 at 11:27

score 79 · Answer 2 · edited Jun 04 '14 at 21:50

79

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.

edited Jun 04 '14 at 21:50

HalosGhost

4,790

answered Jun 04 '14 at 21:16

cobbzilla

891

2

Thanks, this was the issue for me. I created the host name for the IP locally but not on the remote ssh server. – dev_feed Apr 20 '16 at 12:29
3

"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? – Terrence Brannon May 12 '17 at 10:42
2

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. – Terrence Brannon May 12 '17 at 10:44
2

@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 (user@remote), 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. – cobbzilla Aug 16 '17 at 05:30
5

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. – Randall Mar 24 '18 at 19:19

score 31 · Answer 3 · answered Jun 01 '11 at 16:59

31

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

answered Jun 01 '11 at 16:59

Neil

3,462

3

No it isn't; I use icmp-admin-prohibited as the reject flag in firewall configs all the time. – Shadur-don't-feed-the-AI Jun 01 '11 at 19:29
12

+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 02 '12 at 21:04
1

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. – Jan Matějka Jun 10 '13 at 20:46
1

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 08 '15 at 22:39
:face-palm: wrong host name - double check it – WEBjuju Jan 10 '23 at 22:25

score 21 · Answer 4 · edited Aug 20 '13 at 07:18

21

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

edited Aug 20 '13 at 07:18

Anthon

79,293

answered Aug 20 '13 at 07:01

jacquesjtheron

211

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. – timss Sep 02 '16 at 09:05

score 13 · Answer 5 · answered May 20 '13 at 12:07

13

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.

answered May 20 '13 at 12:07

Matej Kovac

361

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 00:55
1

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 Oct 23 '13 at 10:36
@oliver: confirming, MaxSession works, thanks. bumped to 64 on my workbook. – Matej Kovac Apr 03 '14 at 08:58
3

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 '15 at 14:36

score 10 · Answer 6 · answered Dec 30 '17 at 03:39

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

ssh -L 1234:localhost:3389 user@remote

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 user@remote

Same, and I wish I knew whyyyy! – NateS Mar 13 '20 at 00:40 — NateS, Mar 13 '20 at 00:40

score 10 · Answer 7 · edited May 28 '13 at 23:18

10

This also happens when /etc/sshd_config has

AllowTcpForwarding no

set. Switch it to yes to allow TCP forwarding.

edited May 28 '13 at 23:18

answered May 28 '13 at 22:03

user578125

101

score 7 · Answer 8 · answered Jun 01 '11 at 19:28

7

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

Check your iptables settings.

answered Jun 01 '11 at 19:28

Shadur-don't-feed-the-AI

31,260

10

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 02 '12 at 21:11
4

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-don't-feed-the-AI Jan 03 '14 at 23:07
4

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? – GS - Apologise to Monica Sep 23 '14 at 05:38

score 7 · Answer 9 · answered Mar 10 '16 at 14:26

7

I'm extremely surprised that no one have mentioned that this might be a DNS issue.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

This might be presented if remote is not resolvable or you've enter a unknown syntax like I've done here where I've added a user@ to the port-forward logic (which won't work).

answered Mar 10 '16 at 14:26

Torxed

3,637

I'm extremely happy that I saw this answer and realised I had a typo in my domain name..thanks. Saved me some time. – bandejapaisa Apr 28 '22 at 20:36

score 5 · Answer 10 · answered Jul 22 '16 at 10:31

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 user@remote

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 — Jo Rhett, Oct 23 '17 at 22:29
This may actually have to do with the UseDNS no option in in sshd_config, although localhost should be listed in /etc/hosts and therefore conventionally doesn't require a full DNS lookup. — 0xC0000022L, Dec 14 '21 at 20:56

score 4 · Answer 11 · answered Apr 23 '18 at 17:37

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

ssh -Nn -L 1234:remote:5678 user@remote

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

That should cause bind [0.0.0.0]:<port>: Address already in use and shouldn't result into the OP's issue — Junaid, Nov 15 '21 at 21:38

score 4 · Answer 12 · edited Dec 13 '12 at 23:50

4

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.

edited Dec 13 '12 at 23:50

Renan

17,136

answered Dec 13 '12 at 20:37

Marciano

41

this option -g solved it for me (together with AllowTCPForwarding yes). My use case was a port-forward of a VirtualBox controller that has two virtual Ethernet ports: one for NAT and the other one to the internal network. I needed to bind the ssh ports of the internal network (not reachable by host) to the "controller" VM. Thx! – Sebastian Mar 19 '23 at 17:01

score 3 · Answer 13 · edited Jun 02 '11 at 11:08

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

edited Jun 02 '11 at 11:08

Shadur-don't-feed-the-AI

31,260

answered Jun 01 '11 at 21:23

Marco Solieri

51

score 3 · Answer 14 · edited May 02 '17 at 09:22

In my case, the issue was due to requesting a tunnel without shell access while the server aimed to force a password change on my account. Due to the lack of a shell, I could not see that and only received the error

channel 2: open failed: administratively prohibited: open failed

My tunnel configuration was as follows:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

The error showed when logging in directly to the server (without -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

I resolved the issue by logging in with shell access and changing the password. Then I could simply use tunnels without shell access again.

score 2 · Answer 15 · answered Aug 18 '15 at 18:54

2

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.

answered Aug 18 '15 at 18:54

SlavaSt

125

score 2 · Answer 16 · answered Oct 04 '13 at 14:34

2

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.

answered Oct 04 '13 at 14:34

Leonardo Brunnet

21

score 1 · Answer 17 · answered Apr 18 '15 at 19:44

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
    [...]
Match

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.

score 1 · Answer 18 · edited Jul 21 '15 at 08:25

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 www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

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

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

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

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.

score 1 · Answer 19 · answered Feb 25 '22 at 03:05

I just wanted to confirm what @hyperair mentioned in their answer. I was trying to do the following type of SSH connection using a ProxyJump.


┌─────────────────────┐     ┌─────────────────────┐      ┌─────────────────────┐
│                     │     │                     │      │                     │
│                     │     │                     │      │                     │
│     SSH Client      ├────►│  ProxyJump Server   ├─────►│      SSH Server     │
│                     │     │                     │      │                     │
│                     │     │                     │      │                     │
└─────────────────────┘     └─────────────────────┘      └─────────────────────┘

In my scenario I had the following in my client's SSH ~/.ssh/config.

StrictHostKeyChecking no
ControlPersist 10m
ServerAliveInterval 240
ForwardAgent yes
ForwardX11 yes
adds keys found to ssh-agent
UseKeychain yes
AddKeysToAgent yes
Host host1-ext.mydom.com
    Hostname host1.dyndns.org
    Port 3022
    IdentityFile ~/.ssh/ssh_slm@mydom.com_id_rsa
    User slm
    ForwardAgent yes
Host host2-ext.mydom.com
    Hostname host2.mydom.lan
    IdentityFile ~/.ssh/ssh_slm@mydom.com_id_rsa
    User slm
    ProxyJump host1-ext.mydom.com

When using a ProxyJump configuration the server in between, host1.dyndns.org needed to have the configuration options enabled on its /etc/ssh/sshd_config file, mainly:

$ more /etc/ssh/sshd_config
...
TCPKeepAlive yes
AllowTcpForwarding yes
...

Without these settings I'd get the following error:

$ channel 0: open failed: administratively prohibited: open failed
stdio forwarding failed
kex_exchange_identification: Connection closed by remote host

But adding them and bouncing the SSHD on the "proxy" server (i.e. the one in the middle) enabled it so I could SSH all the way through.

score 1 · Answer 20 · answered Nov 13 '23 at 09:45

1

I found yet another reason for the issue:

I tried to open a tunnel to localhost
I used the ChrootDirectory command

Apparently this combination fails, because sshd can then no longer access the file /etc/hosts

I found two workarounds:

open a tunnel to ::1 or 127.0.0.1 instead of localhost
copy /etc/hosts to the chroot directory.
(Assuming ChrootDirectory: /var/allowed_dir, then mkdir /var/allowed_dir/etc; cp /etc/hosts /var/allowed_dir/etc)

answered Nov 13 '23 at 09:45

Jakob Egger

123

« yet another reason »? No, this was given more generally by Lars Nordin (« make sure "destination" is resolvable from tunnelhost ») and by Torxen (« this might be presented if remote is not resolvable »). This was also suggested by others (empty/wrong /etc/resolv.conf or /etc/hosts). But your answer is valuable, as it addresses the specific case of chroot. – xhienne Nov 13 '23 at 12:19

score 0 · Answer 21 · answered Oct 23 '15 at 21:34

0

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

answered Oct 23 '15 at 21:34

Northstrider

101

score 0 · Answer 22 · answered Feb 20 '17 at 17:48

0

I had the same issue and i realized that it was DNS. Traffic is tunneled but DNS request no. Try to edit you DNS hosts file manually and add the service you wish to access.

answered Feb 20 '17 at 17:48

Data

1

barlop · Answer 23 · 2012-03-31T10:46:28.317

0

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

edited Mar 31 '12 at 10:46

answered Mar 31 '12 at 10:40

barlop

259

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 02 '12 at 03: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 02 '12 at 08:05
@SteveBuzonas check your one it probably is set to no and you can tunnel as indeed tunneling is enabled by default. – barlop Jun 02 '12 at 08: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 02 '12 at 21:00

score 0 · Answer 24 · edited Mar 01 '22 at 02:54

Other name resolution cause: My /etc/hosts had an erroneous IP address for the name of the server (not for localhost), like this:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

But the configured server IP (and the DNS name resolved with the host/dig commands) was 192.168.2.47. A simple typo caused by a previous IP reconfiguration. After fixing /etc/hosts the tunnel connection worked flawlessly:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

It is weird that the real IP caused the failure when I was using the localhost literal IP for the tunnel. Distro: Ubuntu 16.04 LTS.

score 0 · Answer 25 · answered Jun 03 '19 at 20:57

It seems there a lot of possible root causes for this message. In my case it was an inability to access the remote because I hadn't provided the keyfile correctly.

The -L option adds an implicit SSH jump (effectively using the explicit SSH host as a bastion/jump server). It may be easier to debug this by performing the jump explicitly and creating a login shell to the target machine using "proxycommand".

Once this is working, you can do the port forward based on the target machine's localhost (assuming it can log in to itself):

-N -L 1234:localhost:1234

score 0 · Answer 26 · answered Feb 23 '20 at 13:09

0

The Asus RT68U router's firmware (Merlin Asus) has a setting that permits SSH port forwarding, which must be enabled:

Dynamic port forwarding was setup as described at: Dyamic tunnel troubleshooting

answered Feb 23 '20 at 13:09

gatorback

1,384
23
48

Lars Nordin · Answer 27 · 2023-03-03T16:29:49.017

Issue could be with the destination hostname - if same hostname is used in different subdomains - if using hostname only:

ssh -L 12345:destination:54321  tunnelhost

To fix my issue, I had to use the fully qualified domain name for the target to get the correct server and not depend on DNS search order.

ssh -L 12345:destination.domain.host:54321  tunnelhost

Also, make sure "destination" is resolvable from tunnelhost

score 0 · Answer 28 · answered May 27 '22 at 21:09

So many answers, and none covered my scenario, so I'll share as well.

I was getting this error message when using VNC over an SSH tunnel. The tunnel would be created just fine but then when I tried to open the VNC session, nothing would happen on the client and the tunnel would log a very similar "administratively prohibited" error.

The solution was to fix the max logins in /etc/security/limits.conf on the target machine. This was very confusing to me, since I had not yet authenticated with VNC so I don't know how it "knew" it was me.

(If it matters, my ssh client was actually plink from PuTTY.)

diyism · Answer 29 · 2017-03-31T11:17:21.750

My case:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

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

29 Answers29

A similar problem

On client side

On remote side

How to solve it

adds keys found to ssh-agent

Linked

Related