Tue, Sep 13, 2011
TLDR: By default SELinux in Fedora 14 blocks sshd from forwarding traffic,
even if your
sshd_config allows it. Run
setsebool -P sshd_forward_ports 1
to allow forwarding.
When working from home, I was attempting to set up a SSH tunnel to forward
traffic from my Macbook Pro to a Fedora machine I have on the network in the
office. We have a VPN to connect to in order to access machines on the
corporate network, but a particular internal web application has always been
very tricky to connect to over the VPN (for some unknown reason - it takes
minutes for any page to load).
After getting fed up with using VNC over the VPN to access this webapp from a
machine on the network - which is unbearably slow - I remembered I could try to
set up a ssh tunnel between my laptop and another machine I own on the network
(in a bit of an “aha, why didn’t I think of this 6 months ago!” moment).
Setting up the tunnel is simple: run this ssh command in a terminal window:
$ ssh -ND 5555 matt@officelinuxmachine
and then configure a browser to use 127.0.0.1 and port 5555 as a Socks v5
However then I ran into something tricky - when I tried to access the
troublesome web app in the browser through the proxy, officelinuxmachine was
refusing my requests:
debug1: channel 2: new [dynamic-tcpip]
channel 2: open failed: administratively prohibited: open failed
debug1: channel 2: free: direct-tcpip: listening port 5555 for 10.22.15.138 port 80, connect from 127.0.0.1 port 62342, nchannels 3
(this is the output from the ssh client on my laptop, reporting that the other
side of the tunnel is prohibiting the open command)
After googling around a bit, I checked to make sure
the other side of the tunnel allowed tunneling (
PermitTunnel yes) - which it did.
After a few minutes of frustration, I noticed this in
Sep 13 08:44:33 officelinuxmachine setroubleshoot: SELinux is preventing
/usr/sbin/sshd from name_connect access on the tcp_socket port 80. For
complete SELinux messages. run sealert -l
Uh-oh, SELinux is blocking sshd from connecting, even though sshd itself is
configured ok! Running the
sealert command to view the full alert yields this
SELinux is preventing /usr/sbin/sshd from name_connect access on the tcp_socket port 80.
***** Plugin catchall_boolean (47.5 confidence) suggests *******************
If you want to allow sshd to forward port connections then you must tell
SELinux about this by enabling the ‘sshd_forward_ports’ boolean.
Do setsebool -P sshd_forward_ports 1
Now it all makes sense - SELinux is set up to block sshd from forwarding ports by default. Executing
$ setsebool -P sshd_forward_ports 1
then allows the port to be forwarded as intended.
Thu, Apr 14, 2011
At work I used byobu on my Fedora machine as a wrapper around screen, and I’ve
.byobu/windows file (which is a bit of a replacement for
in a normal screen session) to open up all of the screen windows I like to have
I like to start a new session with a few dedicated windows setup:
A window titled “logs” which tails the log file of the main application I’m
A window titled “errors” which tails the same log file as #1, but piping the
output to grep to watch for ERRORs
A window titled “project” which starts in my project’s main directory
A window titled “bash” which starts in my home directory.
.byobu/windows) looked like this:
# window 1
screen -t 'logs'
# window 2
screen -t 'errors'
# window 3
screen -t 'project'
# window 4
screen -t 'bash'
To actually start the tail process, I used to always search through my command
history to find the correct tail command I wanted to use in the window (either
tail -F current.log or
tail -F current.log | grep -A 3 ERROR to watch for
the ERRORS only).
Until today, that is, when I figured out how to setup screen to run these
commands for me automatically when the screen session starts.
There seems to be two ways to go about this:
You can simply include the command you want to run in this window in the
screen -t, such as
screen -t 'logs' tail -F current.log
however, this breaks if you want the command to include a pipe, such as
screen -t 'errors' tail -F current.log | grep -A 3 "ERROR"
and I couldn’t figure out the correct way to escape this.
Setting up the screen window this way will also cause screen to exit the
window entirely if you enter
Ctrl+C, rather than just exiting the command
and returning you to the shell (which makes sense if you think about it).
Another way to execute a command in the window at startup is to use the
stuff command, which will paste whatever string you want into the input
buffer of the current window. The trick here is to also include the escape
sequence for the Enter key, to simulate someone actually entering the
command and then pressing enter at the keyboard:
screen -t 'errors'
stuff 'tail -F /var/ec/current.log | grep -A 3 "ERROR"^M'
^M is entered by pressing Ctrl+V, Enter with your keyboard, not by
actually typing caret and uppercase M)
This works like a charm - when I start a new screen/byobu session, I have
windows named “logs” and “errors” setup which are already tailing the log files
I would like them to.
Sources that were helpful in figuring out how to set this up:
Mon, Jan 24, 2011
I’ve recently started using Linux (Fedora 14 to be specific) as my primary
development OS at work. I actually have two desktop machines side-by-side at my
desk - a Windows 7 PC for general office-type work and the Fedora machine for
development. When working from home, I have to remote into the Windows machine
and then use VNC from that machine to the Linux machine. The built-in VNC
server in Fedora (vino-server) is configured by default to start only once you
start a physically-logged-in session (since it runs as your local user, with
preference you set, etc).
This is fine most of the time, but when working from home I have a nasty habit
of forgetting how the setup I’m using actually works and logging out of my
physical session, thus terminating my VNC session and (GUI) access to the Linux
desktop machine. To get back in, I need to find someone in the office who can
walk over to my Linux desktop and log me in again. This is obviously a bit
After a fair amount of searching of how vino-server could be restarted remotely
from the command line, I’ve found two methods for resolving this issue
(ironically most of the advice was from threads on the Ubuntu forums, notsomuch
on Fedora sites). The first option is rather ugly in that it leaves your system
with a user who will be automatically logged in, and stored passwords will be
saved to disk in plaintext. I would not suggest this approach unless absolutely
Solution 1: Set Gnome Desktop Manager to auto-login your user
One fix I found for this is to setup Gnome Desktop Manager to auto-login your
user when it starts (at boot); this solves the VNC problem fine but it
causes a few other problems of it’s own (listed below):
Edit /etc/gdm/custom.conf and add the two settings under the
section, each on their own line:
AutomaticLogin=yourUsername. Now the next time that the machine boots,
yourUsername will be logged in.
However, Gnome has a feature (the “keyring”) in which it asks you to enter a
master password to unlock the keyring, in which Gnome and other applications
in your system can store any password information you save in an encrypted
manner. If GDM auto-logs in your user, Gnome will be sitting at a screen
where it is asking the user at the physical display to enter the master
password to unlock the keyring. If you are remote at this time, you will not
be able to enter in the password! To prevent this behavior, rename or delete
A new keyring needs to be created to replace the previous - to do so you can
either (from a physical login) attempt to store a new password, triggering
Gnome to prompt you for a new keyring password (you must set the password as
blank for this method to work), or create the file
~/.gnome2/keyrings/default with the content of just the word
From now on you should be able to VNC if you ever log out of your physical
session, since Gnome will automatically log your user back in.
The nasty side-effect of this method is that with an empty keyring
password, any stored passwords in your local account are stored on disk in
plaintext. If you save a password to your IM account in Pidgin, or your email
account password in Thunderbird, etc., all of these are stored in
~/.gnome2/keyrings/default.keyring in plaintext.
This might not seem so bad at first glance since this file is readable by only
your user, until you remember that your account will automatically be logged in
whenever the machine boots. All someone needs to do is reboot your machine -
even if you have locked the display - to gain access to your files.
As mentioned above, this solution is not that great due to the side-effects - I
would really not recommend doing this unless nothing else works.
Solution 2: Start vino-server over X11 Forwarding
It is possible to start a new vino-server instance if you login to the target
machine with X11 forwarding.
First, ssh to the target machine with
ssh -X targetmachine (note, if you get
warning messages about
untrusted X11 forwarding setup failed, try
If you are using Windows on the machine you are doing this from, you can
install Cygwin and the X11 options (in Cygwin’s installer, select “xorg-server”
from the X11 category, this should pull in a lot of other dependencies
automatically). Once installed, open a Cygwin terminal and run
start the ssh session using the terminal windows within the X windows that have
popped up on the Windows machine.
Once logged into the target machine, switch to the root account (using
-s) and then run
DISPLAY=:0.0 xhost + to allow remote access to the local X
server. Then exit from root, and as your normal user run
/usr/libexec/vino-server to start a new instance of vino-server.
It’s necessary to prepend these commands with
DISPLAY=:0.0 to have them use
the X display of the physical display.
ssh -X targetmachine
sudo -s to change to root
DISPLAY=:0.0 xhost +
exit from root
DISPLAY=:0.0 /usr/libexec/vino-server as the regular user to start
You should now be able to connect via SSH and start a new login session as
if you were sitting at the machine.
Note that from here, if you terminate the SSH session in which you spawned
vino-server, then the VNC server will be shut down as well. To re-start the VNC
server, you can either re-do these steps or (if connected to the target machine
via VNC) open
vino-preferences (either by running the command or navigating
System > Preferences > Remote Access). Simply running
seems to start a new instance of vino-server if none is already running.
This thread on the Ubuntu forums was a big help in figuring out how to get
this to work.
Compared to Solution 1, this solution does not leave your machine in a state in
which it could be comprimised - no automatic login or keyring password options
need to be changed.