4

i have a dynamic OpenSSH tunel running as :

ssh -N -D '*:1080' [email protected]

(OpenSSH_5.3p1 Debian-3, OpenSSL 0.9.8n 24 Mar 2010)

which runs perfectly for a few hours, or a few days, but begin to randomly drop connections (not 100%, only some) yielding:

channel 1019: open failed: administratively prohibited: open failed

I googled it but can't find nothing more than this message spowning in cause of server misconfiguration denying completly the tunnel, here the tunnel works some hours before dropping a few requests.

Any idea?

11
  • Is there a chance you're encountering a bad link? I'm pretty baffled at that message-the only other thing I could think of was a memory issue-do you have plenty of free RAM on the box you're sshed into?
    – Josh Budde
    Jun 28, 2010 at 15:15
  • I'll check the memory server-side the next time, and wrote it here. The bad link idea : I think not as if i restart the ssh, it works well again
    – Mandark
    Jun 28, 2010 at 15:22
  • New one this day, checked client and server health (cpu, memory, logs) nothing particular.
    – Mandark
    Jun 29, 2010 at 7:40
  • did you ever find the solution to this?
    – sybind
    Sep 10, 2013 at 2:04
  • @sybind No, but I continue using ssh -D a lot, without any problem now. Do you experience it ? Which version ? Only a few drops ?
    – Mandark
    Sep 11, 2013 at 19:19

4 Answers 4

4

I've seen the same message when trying to do a port forward to an unreachable destination:

ssh example.com -L 1337:example.invalid:80

telnet localhost 1337

[email protected]:~$ channel 3: open failed: administratively prohibited: open failed

3
  • This can't be that, as my tunnel works some hours before starting to fail, i mean, somtime >24h
    – Mandark
    Jun 29, 2010 at 7:41
  • I never said it was :)
    – Andrew
    Jun 29, 2010 at 7:50
  • @Andrew This saved me! Nov 15, 2017 at 18:35
1

“Administratively prohibited” is also one of the ICMP control messages. Is it possible a router between the SSH server and the tunnel destination is sending this?

If sniffing is possible, a simple pcap filter with just icmp can show you all ICMP traffic.

1
  • I'll try to dump some ICMP packets next time using tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
    – Mandark
    Jun 29, 2010 at 7:44
0

I had the same problem using authorized_keys with permitopen. On server side, /var/log/auth.log contained:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

As I use autossh to create a tunnel, I needed two ports: one for connection (10000) and one for monitoring (10001). The problem came with monitoring port.

In my authorized_keys I had this:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA

I solved this by replacing localhost instances with 127.0.0.1

0

The reason for the dropped connections might be a firewall that is overloaded or configured to be overly strict in cleaning up idle connections, somewhere between your SSH connection target and the ultimate target of the forwarded ports.

Once a firewall judges a connection to have been idle for long enough, it may just drop the connection information from its connection state table. If either endpoint of the connection attempts to pass any traffic after that, the firewall will reject the connection (on behalf of the intended destination) since you're apparently attempting to use an existing connection but the firewall no longer has the state tracking information for that connection. So the firewall rejects the packets with an ICMP error message, hence "administratively prohibited".

You must log in to answer this question.

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