ssh tunnel error in Fedora 14 x86_64

[mikewlcheung]

Dear all,

I have just upgraded Fedora 13 to 14 via preupgrade. Everything seems fine so far except the SSH tunneling. I used to connect to vncserver via tunneling from Windows and Linux clients by
ssh -L 5902:localhost:5901 user_name@ip_linux_server

Then I could use "vncviewer localhost:2" to connect to the Linux server from Windows and Linux clients. After upgraded to Fedora 14, I received an error message "channel 3: open failed: administratively prohibited: open failed".

I searched the web on this error message and tried to fix it by (1) enabled "PermitTunnel yes" in /etc/ssh/sshd_config and restarted sshd; and (2) enabled 5900 port with tcp and udp protocols in Firewall. However, they did not work.

I would appreciate any suggestions. Thanks in advance.

Regards,
Mike

[ozawa]

I have the same problem. My scenario is a bit different I was using tunnelling to connect to my squid server. It was working on Fedora 12 but not 14. I have also tried enabling PermitTunnel. No luck. Temporary disabled iptables still the same error. Could not see any warnings from Selinux. Running out ideas.

---------- Post added at 12:12 PM GMT ---------- Previous post was at 12:00 PM GMT ----------

Just fixed the problem It is actually to do with the Selinux. Funny there was no warning. Just execute this command below
sudo setsebool sshd_forward_ports=on

[stevea]

Yeah well here is the problem,
what youse guys call "tunneling" is "port forwarding". Ssh can also do tunneling but it is ENTIRELY DIFFERENT.

su -
<passwd>
echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config
service sshd restart

I strongly suggest you learn to RTFMpg.

[ozawa]

Yeah well here is the problem,
what youse guys call "tunneling" is "port forwarding". Ssh can also do tunneling but it is ENTIRELY DIFFERENT.

su -
<passwd>
echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config
service sshd restart

I strongly suggest you learn to RTFMpg.

I have tested it myself with the param you have suggested. It did not fix the problem. I think this param is yes by default (man sshd_config). To fix the problem I have to run this command below.

setsebool sshd_forward_ports=on

[timliim]

Eventually I did "tail -f /var/log/messages" and saw this msg

Nov 24 02:23:06 vyam setroubleshoot: SELinux is preventing
/usr/sbin/sshd "name_connect" access on <Unknown>. For complete
SELinux messages. run sealert -l 2ac9d527-18a0-4efc-81fd-3d3694aef179

and "sealert -l 2ac9d527-18a0-4efc-81fd-3d3694aef179" told me to

# setsebool -P sshd_forward_ports 1

which fixed the issue, same as "setsebool sshd_forward_ports=on".


BTW, vncviewer from tigervnc has a -via option, so you can do

ssh -via user_name@ip_linux_server :1

instead of

ssh -L 5902:localhost:5901 user_name@ip_linux_server

Here the reason why we use "tunneling" in lieu of "port fowarding."
With "ssh -vvv -L5598:0:5901 taiwan", ssh says

debug1: sys_tun_open: failed to configure tunnel (mode 1): Operation not permitted
Tunnel device open failed.
Could not request tunnel forwarding.

You see, I requested "port forwarding," but ssh told me it had issue
with "tunnel." I agree that the proper term should "port forwarding"
here.

---------- Post added at 03:17 AM GMT ---------- Previous post was at 02:51 AM GMT ----------

I opened

bug656813 selinux should allow sshd port forwarding by default

to request change of this setting. Let's see if this brings anything.

[mikewlcheung]

Thanks all the replies! timliim's solution works!

[timliim]

Glad I can help! There is some discussion going on in
Bug 653579 - SELinux is preventing /usr/sbin/sshd from binding to port 3388
on whether selinux should allow/disallow "ssh port forwarding" by default.

Cheers.
Tim Taiwanese Liim

[abbott]

Well.
timliim's solution does not fix my problem.

OS Fedora 13 x86_64
I enabled
Tunnel yes
TunnelDevice any:any
in /etc/ssh/ssh_config on Fedora 13.

Then when I connect to some other RHEL5 server,
I got the following message:

ssh -p 8022 -X abbott@dawn

Tunnel device open failed.
Could not request tunnel forwarding.

Actually,
no changes have been made to
the /etc/ssh/ssh_config on my Fedora 13
and the /etc/ssh/sshd_config on danw server (RHEL5) since Oct. 1 2010.

The other day,
when I get my Fedora 13 updated,
I got that message.
Tunnel device open failed.
Could not request tunnel forwarding.

I don't know the exact date.
Maybe it is due the recent update since Nov. 28, 2010.

I need your support to help me out....

Pleas.....

[timliim]

Abbott,
But your issue is a different one, of course the "setsebool -P
sshd_forward_ports 1" command will not fix it.

I did not encounter the same error ("Tunnel device open failed. ...")
as you do, so could you provide more info?
- does the same error occur if you do not use "-X"? I guess not, but just a sanity check.
- does the error occur if you connect to another server? Or localhost? How about from your RHEL5 back to your F13 box?
- when this error occurs, is there any new msg in /var/log/messages on the server side?
- add "-vvv" to the ssh command, to see what the ssh client is doing.

I checked my /etc/ssh/ssh_config; it has

# Tunnel no
# TunnelDevice any:any

(both are commented out), and I can use -X to another F13 box without
problem. That is, you should not have to change /etc/ssh/ssh_config
to use -X.

Cheers,
Tim Taiwanese Liim

[AMAMH]

I disable selinux completely.... not sure if this is ultra good, but I'm not running a weapons factory it's just my laptop, and selinux is annoying and sometimes prevent stuff from working.

[drinkingcoffee]

I have the same problem. My scenario is a bit different I was using tunnelling to connect to my squid server. It was working on Fedora 12 but not 14. I have also tried enabling PermitTunnel. No luck. Temporary disabled iptables still the same error. Could not see any warnings from Selinux. Running out ideas.

---------- Post added at 12:12 PM GMT ---------- Previous post was at 12:00 PM GMT ----------

Just fixed the problem It is actually to do with the Selinux. Funny there was no warning. Just execute this command below
sudo setsebool sshd_forward_ports=on

just wanted to say thanks for this -- I was trying to work remotely the other day from my laptop to my desktop, and couldn't for the life of me figure out why the ssh forwarding wasn't working.

[abbott]

My problem was solved.

The other day,
after the update,
everything works fine.

Now,
Fedora13,
2.6.34.7-66.fc13.x86_64

[dave_c]

I am having a different, but related, problem to what is discussed above.

I am trying to use X forwarding over ssh/vpn to display an application from a remote Solaris server.

I use the command ssh -X -vvv user@location remote_command.

I have used this on Fedora 9-12 with success in displaying the remote application.

With Fedora 14, the command does not generate any error messages in /var/log/messages or Xorg.0.log or secure, but the remote application does not display.

The ssh debugging messages also do not help.

The last few debug messages look like:

debug3: channel 1: close_fds r 7 w 7 e -1
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40905
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: channel 1: will not send data after close
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)
#1 x11 (t4 r3 i3/0 o3/0 fd 7/7 cc -1)

debug3: channel 1: close_fds r 7 w 7 e -1
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40908
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11

after which no further messages are displayed, and no remote application is displayed. Parts of the above messages can be displayed several times.

When I do the same thing on a macbook running Snow Leopard, I get an almost identical set of debugging messages which end as above, but the remote application successfully displays.

I can log in to the remote server using ssh -X user@location to get a remote shell, but I can't display remote applications using this approach either.

I don't know if this is a SELinux problem, an Xorg problem, or ssh problem, a vpn problem, or a combination of problems.

Where should I look next?