Yesterday I upgraded also my workstation to Fedora 14 and soon ran into a rather unexpected problem that I couldn’t resolve due to an overwhelming amount of misleading reports and discussions on the web a.k.a. „noise“. The use-case was, that I tunnel from home to my workstation via SSH on a regular basis and for different purposes. After yesterdays upgrade I double-checked that all firewall settings are OK to permit the connection before I went home. Initialising the tunnel later that evening went without a problem, but using it issued a weird error:
channel 2: open failed: administratively prohibited: open failed
A search on the web yielded all kinds of results, mostly referring to settings in the SSH daemon. All solutions either mentioned
AllowTcpForwarding, which is anyway
yes by default, or
PermitTunnel, which has nothing to do with port forwarding. As was to be expected, these hints didn’t help in my case.
Desperate to find more useful keyword for a search, I ran
ssh in verbose mode (with
-vvv), which gave (global IP addresses are replaced by
debug1: Connection to port 11080 forwarding to socks port 0 requested. debug2: fd 8 setting TCP_NODELAY debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: channel 2: new [dynamic-tcpip] debug2: channel 2: pre_dynamic: have 0 debug2: channel 2: pre_dynamic: have 3 debug2: channel 2: decode socks5 debug2: channel 2: socks5 auth done debug2: channel 2: pre_dynamic: need more debug2: channel 2: pre_dynamic: have 0 debug2: channel 2: pre_dynamic: have 10 debug2: channel 2: decode socks5 debug2: channel 2: socks5 post auth debug2: channel 2: dynamic request: socks5 host X.X.X.X port 80 command 1 channel 2: open failed: administratively prohibited: open failed debug2: channel 2: zombie debug2: channel 2: garbage collecting debug1: channel 2: free: direct-tcpip: listening port 11080 for X.X.X.X port 80, connect from 127.0.0.1 port 59418, nchannels 3 debug3: channel 2: status: The following connections are open: #1 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1) debug3: channel 2: close_fds r 8 w 8 e -1
No luck either.
Finally, I had the idea that SELinux could interfere here without giving the SSH daemon the possibility of a helpful error message. When I logged into my workstation this morning, the SELinux warning gave the appropriate solution in the form of a command (to be issued by
$ setsebool -P sshd_forward_ports 1
This fixed the problem and everything now works as before. \me = happy.