46

I've been using SSH tunnel for a while on Windows (using Putty).

On Windows with putty, it is always fine, but on mac or cygwin, it sometimes prompts the warning message:

open failed: administratively prohibited: open failed

2
  • If you are port forwarding as a regular user and trying to use a privileged port number <1024 this msg will show. Is this the case?
    – cormpadre
    Commented Nov 17, 2015 at 15:53
  • If caused by mis-typing a domain and DNS resolution fails, the connection may freeze until it times out. superuser.com/a/700677
    – user423430
    Commented Mar 24, 2017 at 17:12

6 Answers 6

41

I believe you have disabled TCP forwarding on the server. In your server /etc/ssh/sshd_config make sure that the following line is either not present or commented, otherwise comment it.

AllowTcpForwarding no
2
  • 10
    Just searched and it is AllowTcpForwarding yes Commented Sep 1, 2013 at 10:52
  • 3
    The answer says that the line in the answer is the one that should not be present Commented Dec 29, 2020 at 13:18
11

There is a broader discussion of this error with SSH tunnels on Unix StackExchange. In a nutshell, this is a non-specific error; there are numerous possibilities that should be explored.

3

If the sshd config already has all the options to enable port forwarding, but you still get this issue, check /var/log/secure for something like this - sshd: error: connect_to XXX: unknown host (Name or service not known)

If the ssh host is unable to resolve the host that you want to tunnel to, it will give back the generic error unable to open channel.

Double check you tunnel hostname or DNS resolution on ssh server.

1
  • How do I prevent the SSH tunnel from hanging comlpetely when it is unable to resolve some failed domain?
    – Alecz
    Commented Oct 13, 2021 at 20:01
3

open failed: administratively prohibited: open failed

This means the SSH service (on the remote server) is not allowing SSH agent forwarding (AllowAgentForwarding no).

If you cannot change the configuration on the remote server, you can still ssh to one server, then to another one.

Normally you could use ProxyJump option in your .ssh/config, but in this case you cannot.

You can try to forcibly disable forwarding agent on your client (ForwardAgent no), which probably won't work.

Assuming you want to ssh to Y server via X, then as for the workaround, you can define the following section in SSH config file:

Host remotehost
  ForwardAgent no
  HostName 192.168.X.IP
  RemoteCommand ssh 192.168.Y.IP
  RequestTTY yes

Once loaded, then you can simply run: ssh remotehost.

2

Just for posterity, even if it isn't useful to you specifically

The errors are put to your console via stderr, so if you just want to ignore them, adding 2>/dev/null to the end of your ssh call will work perfectly. E.g.:

ssh -C -D 3210 example@connexion 2>/dev/null

This is useful if the proxy tunnel is actually working fine, but you just dont want to see the errors.

In my case; the machine I'm tunnelling to isn't mine, so I can't modify the sshd_config (not that that was your issue) and I also use the same connexion for the shell. Having those error messages write into my console during an open vim window makes the display act up quite annoyingly.

4
  • 8
    This does not answer the question.
    – sebix
    Commented Dec 7, 2016 at 18:11
  • 2
    The text open failed: administratively prohibited: open failed is being outputted to stderr, "on mac or cygwin" you can hide this warning (what it's warning about doesn't actually break anything) by sending that text to null (appending 2>/dev/null to the command). This absolutely answers the question, especially if you dont have admin access to the other machine to fix the underlying issue
    – Hashbrown
    Commented Dec 8, 2016 at 1:04
  • 16
    The question was how to solve the problem, not to hide the error message.
    – sebix
    Commented Dec 8, 2016 at 22:03
  • 2
    depending on the person, the message is the problem. Like I said, it actually doesn't break anything most of the time, so it's okay to hide. Have you ever tried to use ssh when every so often a giant string is vomited all over your session's interactive shell? This solves that, which is why it's here.
    – Hashbrown
    Commented Dec 10, 2016 at 2:55
2

I had a problem with the same symptoms. However at the end of the day, mine was related to vault and tcpforwarding with the credentials given by vault.

When you created the signed-cert.pub file as specified in the documentation, you might have troubles because there is the parameter permit-port-forwarding that should be included.

Verify the certificate you created with vault as follows:

ssh-keygen -Lf signed-cert.pub

You must see the following result:

signed-cert.pub:
        Type: [email protected] user certificate
        Public key: RSA-CERT SHA256:somehash
        Signing CA: RSA SHA256:somehash (using rsa-sha2-256)
        Key ID: "vault-token-somehash"
        Serial: somehash
        Valid: from 2024-01-01T14:44:04 to 2024-01-01T14:46:34
        Principals: 
                ubuntu
        Critical Options: (none)
        Extensions: 
                permit-port-forwarding
                permit-pty

In my case I didn't have enabled the permit-port-forwarding. You should some something analog to the following code:

vault write ssh-client-signer/roles/my-role -<<"EOH"
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "*",
  "allowed_extensions": "permit-pty,permit-port-forwarding",
  "default_extensions": {
    "permit-pty": "",
    "permit-port-forwarding": ""
  },
  "key_type": "ca",
  "default_user": "ubuntu",
  "ttl": "30m0s"
}
EOH

You might think that it's the same as in the documentation, but they are lacking in default_extensions the property permit-port-forwarding (I don't know why, since they put it in the allowed_extensions.

Thus, in the case of vault is not the AllowTcpForwarding that I kept seeing over and over again when debugging.

A bit more in depth

I would like to give a bit more information because this simple looking problem took me days to solve.

I was using the command to connect to the ssh host as follows:

ssh -v -i signed-cert.pub -i ~/.ssh/id_rsa -L 5432:localhost:5432 -N $SERVER_USER@$SERVER_ADDR

The command was working properly (I included -v just to give more information), however, once I wanted to connect (in my case was with postgres) with the command psql -h localhost -p 5432 -U username -W, I was having the following response:

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

And when I go to the terminal with the ssh command I got the following:

debug1: channel 1: new [direct-tcpip]
channel 1: open failed: administratively prohibited: open failed
debug1: channel 1: free: direct-tcpip: listening port 5432 for localhost port 5432, connect from 127.0.0.1 port 32924 to 127.0.0.1 port 5432, nchannels 2

This is the message that brought me here, here, here and a lot more sites over and over again. After a lot of debugging, OS upgrading, bunch of changes in configuration and around 4 days, I realized that I could do the tunneling from my computer even with the options. After a bunch of more tests (playing with /etc/hosts, ip4 and .ssh/authorized_keys modifications, I realized that my computer was overriding -i signed-cert.pub -i ~/.ssh/id_rsa when I have my ssh key in .ssh/authorized_keys. That was the eureka moment that brought me to the following page and this part of the vault documentation, in which I said, why in the world they do not include that part since the beginning? they activate the extension but they don't include it.

Another important aspect was the log from /var/log/auth.log noted from time to time in my searches (this log is from the server).

Jan  1 14:10:15 ip-172-26-3-55 sshd[496555]: refused local port forward: originator 127.0.0.1 port 32924, target localhost port 5432

Anyway, I write this answer with several logs in the hope that if somebody have the same problem, they are going to come here given the information of the logs. Good luck!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .