15

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

  • 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 Nov 17 '15 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 Mar 24 '17 at 17:12
14

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
  • 6
    Just searched and it is AllowTcpForwarding yes – AGamePlayer Sep 1 '13 at 10:52
5

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.

0

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.

  • 3
    This does not answer the question. – sebix Dec 7 '16 at 18:11
  • 1
    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 Dec 8 '16 at 1:04
  • 4
    The question was how to solve the problem, not to hide the error message. – sebix Dec 8 '16 at 22:03
  • 1
    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 Dec 10 '16 at 2:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.