Fedora 14 and SSH port forwarding

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 X.X.X.X):

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 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 root):

$ setsebool -P sshd_forward_ports 1

This fixed the problem and everything now works as before. \me = happy.

Fedora 14 on HP 8440p

The new version of Fedora is out since yesterday and available for download.

Naturally, my private notebook is the first place for me to perform the upgrade. Although the new Nouveau driver detects the resolution (1600×900) and runs just fine, I really want fully accelerated graphics and for that purpose still have to resort to the proprietary drivers from NVIDIA to use the NVS 3100M card in my HP EliteBook 8440p. Not the least reason for this is, that I love GNOME Shell which requires accelerated graphics.

Here is a summary specifically for the 8440p with a resolution of 1600×900. (as root):

yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
yum update
yum install kmod-nvidia


nvidia-settings -r

Verify, that Xorg is configured to use the proprietary driver. A minimal /etc/X11/xorg.conf should look like this:

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"

Finally, since the driver doesn’t support Kernel Mode-Setting (KMS), open the Grub configuration at /boot/grub/grub.conf and append the following parameter to the kernel configuration (behind rdblacklist=nouveau): vga=0x34D.

Update (2011-02-28): To make the video wake up properly after suspend to RAM (sleep), add the following kernel parameter: acpi_sleep=nonvs.