how to solve the "open failed: administratively prohibited: open failed" when using a SSH tunnel proxy

Question

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

Answer 1

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

Answer 2

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.

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

Answer 4

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.

Answer 5

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

Answer 6

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!