Tagged as: Linux

At the office, after preupgrade failed to upgrade Fedora 12 to 13, I figured I could either just install Fedora 13 from scratch, or use the opportunity to give OpenSolaris a try.

OpenSolaris is a Unix operating system (not Linux); I'd played with it in VirtualBox on a few occasions but haven't really gotten into it very deeply so I decided to try installing it on real hardware and try to use it on a day-to-day basis and see how I like it.

OpenSolaris was the creation of Sun Microsystems as a free/open source version of their Solaris operating system. The last stable release was version 2009.06 -- released in June 2009. That version was a bit buggy when run inside VirtualBox; for instance, the audio system didn't work with the virtual audio card provided by VirtualBox, and one would need to manually install the Open Sound System and do a bunch of hacking to fix it. The 2010 release of OpenSolaris was supposed to fix that, but the 2010 release is still missing in action...

After Oracle bought out Sun it seems that OpenSolaris is being neglected. It was supposed to have a release in February as version 2010.02... but that got pushed to March (2010.03), but March came and went and there hasn't been any news from Oracle about it. I hope OpenSolaris isn't going to die though, because it's pretty interesting to me. It and Mac OS X are the only two Unix-based operating systems I've found (so far) that are as user-friendly as Linux. I've tried FreeBSD, for example, and it installs a text mode system and getting a graphical desktop requires a bit of work; it seems to be for the hardcore Unix fans and not the user base of Linux users.

Anyway, I installed the latest development build that was slated to become 2010.*, and, to my surprise all the hardware on my PC at the office worked perfectly with OpenSolaris out of the box; even the proprietary nVidia drivers came pre-installed so I could set up the dual monitors immediately. It's surprising because OpenSolaris in general, along with most other Unix operating systems, doesn't have nearly as wide a range of hardware support as does Linux.

So... dying or not, I'll keep trying OpenSolaris out until I break it or get sick of it, whichever comes first. So far it's been providing a nice new challenge for me though; its software repository isn't as wide as most Linux distributions, so some of the software I'm used to using in Linux that's usually just a yum install away is a bit trickier to get for OpenSolaris. I can live without most of them though for work-related purposes; all I need is VirtualBox, Firefox and some terminal windows to do my job. But I did have to compile the latest version of Wine from source to run my company's chat application because the 1.0.1 version with OpenSolaris doesn't quite cut it.

Once you know one Linux distro you can find your way around any of them; Unix is where the diversity is at. :)

I saw a somewhat interesting article on Digg today titled "The trouble with Linux: it's just not sexy." Apart from making some rather ridiculous claims, one interesting idea the article mentioned was that Linux would have to be unified, standardized, in order to succeed.

The article compared Linux to Firefox: with Firefox, if you make any changes to its source code and redistribute it, you're no longer allowed to call it Firefox, but only "Firefox-based." This article mentioned the idea of one distribution of Linux being able to call itself the Linux; all other distributions have to call themselves "Linux-based."

This wouldn't really work out though, largely because there would be too much politics involved in such a thing. If somebody did want to create "THE" Linux distribution, what desktop environment should be chosen as its default? GNOME, KDE, something else? Or, what package management system should it use? Aptitude/DEB, or Yum/RPM?

Debian, being one of the oldest Linux distributions, would naturally prefer that Debian be the package manager of "THE" Linux. And you could add the whole entire Ubuntu fanboy population on that side of the debate; Ubuntu noobs would all support Debian format, just because these noobs were handed Ubuntu and with that, Debian packages were grandfathered to them because Ubuntu is based on Debian. On the other hand though, large corporations like Red Hat would prefer that RPM be used as a package manager.

Because of politics like this there will probably never be an "official" Linux distribution; only a popular one, like Ubuntu currently is.

Here's what I would suggest though to market Linux as a real competitor to Windows and OS X: first, create a completely new desktop environment, not GNOME or KDE or any existing environments. Make something unique about it. Windows has the task bar and start menu, and OS X has the dock and global top menu bar. What does GNOME or KDE have? Bits and pieces from both.

A new desktop environment developed by a large company would help a lot because the entire desktop experience could be controlled and made high quality. Distributions that just build on top of GNOME or KDE only make the problems even worse by adding custom control panel software and further fragment these two desktop environments. A new desktop environment could be better controlled and marketed from a central point.

And, this desktop environment could license itself like Firefox: if you change it, you have to rename it. Linux itself is already too big to change the way its name can be used like this without starting an epic flame war all over the Internet, but a new GUI desktop environment could pull this off.

The more I use open source software, the more I start to dislike the developers of open source software. They tend to change things and remove features in newer releases of their projects, taking away functionality that used to be there just because they feel like it.

One example of functionality that was removed at the whim of a developer that was actually kind of an important feature: in the GNOME desktop environment, you used to be able to set what mount options you wanted used when GNOME auto-mounted a flash drive or external hard drive when you plug it in.

The default mount options include, among other things, the shortname=lower option for FAT32 volumes. What this means is that, if you have a file on the FAT32 hard drive that fits within the 8.3 filename format of DOS, and the file name is all uppercase, it is displayed in Linux as all lowercase.

I used to (used to!) back up all my websites to a FAT32 hard drive, and I have a folder titled "PCCC" -- all uppercase, and shorter than 8.3 characters. The default mount options would have Linux display this to me as "pccc" -- all lowercase. When restoring from a backup, then, my site would give 404 errors all over my Perl CyanChat Client page, because Linux is case-sensitive and "pccc" is not the same as "PCCC."

It used to be as simple as editing the GNOME gconf key and changing this mount option. But as of Fedora 11 or so, changing the mount options in gconf has no effect. After researching, it turns out that Fedora 11 decided to switch from HAL to DeviceKit to manage the automatic mounting of flash drives. And, DeviceKit doesn't pay any attention to your gconf options.

And, to make it much worse, DeviceKit has the mount options for FAT32 and other filesystems hard coded into the binary itself. So for me to set the shortname=mixed mount option I want for FAT32 drives, I have to download the source code for DeviceKit, find where the mount options were hard-coded into the source, change them there, and compile my own custom version of DeviceKit. This is ridiculous.

Googling as to why in the world this is, I found comments from developers very similar to the one on this bug ticket that goes like this (emphasis mine):

The other part of this bug a discussion of whether exposing mount options to
end users is an useful thing to do. My view is that it is not. So the
replacement for gnome-mount/HAL, namely gvfs/DeviceKit-disks, will not support
that.

Excuse me? I'm sure I cannot be the only person in the world who finds it useful to be able to change the mount options.

As a result of this, I have to edit /etc/fstab and add entries for my permanent external hard drives (FAT32) to get them to use the mount options I need. What is this, 1999 again? We shouldn't have to touch fstab nowadays.

Another example: GNOME 3.0 and GNOME Shell. I have ranted about this several different times now. I'm not against innovation, but I am for backwards compatibility. Intentionally developing a desktop environment that is supposed to replace one as ubiquitous as GNOME 2.x and having it require very powerful graphics hardware, with no fallback for less capable systems, is not a good idea.

One more example (kinda nitpicky, really): in the 4.4 release of the XFCE desktop environment, the window list panel applet used to support automatically grouping all windows of the same application into a single button, and an option to display only the icon of the application and not the window's title. See where I'm heading with this? Long before Windows 7 was even out, XFCE's panel could emulate the behavior of Windows 7's new taskbar. The feature is completely missing from XFCE 4.6 however, probably because the one developer who manages the panel applet decided by himself that nobody, anywhere, uses that feature and he removed it.

This arrogancy by open source developers makes me worry about other projects. In the XFWM4 window manager used by XFCE, you can currently double-click on the menu icon in the title bar and that will close the window, similar to the behavior of Windows as far back as Windows 3.0 (at least). I haven't seen any other X11 window manager that supports double-click-to-close like this (Metacity and Emerald for sure don't support this).

I rather like the double-click-to-close feature, but I'm afraid it will just up and disappear one day because this feature is very poorly documented and the developer may one day decide that nobody uses that feature and delete it from the code. I use that feature! Don't delete it!

Because of things like this, I find myself more and more thinking of just creating my own desktop environment. Yes, a whole entire desktop environment: panels, window managers, everything. I've seen a few Perl-powered desktop environment features that I bookmarked so I can dissect them later. Like, I'm a big fan of the XFWM4 window manager, but I'm not a C or C++ programmer and wouldn't know where to begin if I wanted to fork XFWM4 as my own project. Thus I would write my own window manager in Perl, program in the features that I really like, and maintain it on my own, so that I won't ever lose a feature suddenly just because some arrogant programmer somewhere decided without consultation that the feature is useless.

Ah well... you get what you pay for, I guess.</rant>

A few interesting links I found recently:

perlwm - An X11 Window Manager Written in Perl

http://perlwm.sf.net/

This is an allegedly fully standards-compliant X11 window manager. It appears to be very minimalistic however, but is pretty interesting nonetheless. The window manager, if you don't know, is the software that draws title bars and window borders around all of your windows.

perlpanel - A GTK+ Desktop Panel

http://savannah.nongnu.org/projects/perlpanel

This is a desktop panel written in Perl, using the GTK+ toolkit (same as GNOME, Xfce and Lxde). While meant to be used in conjunction with minimalist window managers such as Blackbox that don't tend to come with panels of their own, it could easily replace gnome-panel or xfce4-panel in their respective desktop environments.

I played with it for a few minutes by doing a `killall xfce4-panel` to nuke my panels and then started this one in their place. It comes with 36 panel applets, some of which require additional perl-Gtk modules to be installed for them to really function properly.

perlbox-desktop - A Perl/Tk Desktop Environment for X11

http://rpm.kirsle.net/tarball/perlbox-desktop.0.1.8.tar.gz

Nowadays, Perlbox is all about voice control software for Linux. But apparently a long time ago, Perlbox was an X11 desktop environment written entirely in Perl/Tk, which is the GUI toolkit I used in my Perl CyanChat Client, and you can see how ugly it is if you look at the Linux screenshots for that program.

I played around with this one. It creates a "panel" of sorts that it sticks on the bottom of your screen. Besides being ugly as sin, this panel doesn't even hook into your window manager to show a taskbar list of your running applications. It's really clunky and not very fun to use, and did I mention how ugly it is?

I logged in with the Blackbox window manager to test it and I forgot to grab a screenshot of it, but there's a (scaled down) screenshot on an old freshmeat project page for it. Also, it's here:

These projects are interesting and I'm definitely gonna save a copy of their source codes for reference material in case the day comes where I get the utterly insane idea to ditch all the existing Linux desktop environments and create my own, from scratch, that does what I want (the only complaint on my list so far with all the desktops I've tried is: when a panel auto-hides, they like to destroy all their panel applets, so that when the panel is unhidden you see the contents jump around as all the applets load back up. Why!? Just move the panel off the screen, don't destroy all its applets.)

Just one complaint isn't enough (yet!) for me to roll my own desktop environment though. :)

rdesktop, the command-line-driven Windows remote desktop client for Linux, is a kinda old program that uses OSS (Open Sound System) for its audio, so it tries to open /dev/dsp as your audio device.

In modern Linux distros this device doesn't exist because now we have PulseAudio. So how do you get rdesktop to play sounds from the remote server on your local machine? Using padsp from the PulseAudio pulseaudio-utils package in Fedora (and probably a similarly-named package for Ubuntu).

padsp "starts the specified program and redirects its access to OSS compatible audio devices (/dev/dsp and auxiliary devices) to a PulseAudio sound server."

Then just put padsp in front of your rdesktop command:

$ padsp rdesktop -u Kirsle -f -r sound:local 10.10.1.100

Several months ago I decided to convert my old Acer Aspire 5050 laptop into a media center PC, because it's the only computer in the apartment that has an S-video port, and that's the only input my TV will accept.

The laptop has an ATI Radeon Xpress 1100 (a.k.a. Xpress 200M), and it seems that just months after I bought this laptop a couple years ago, ATI obsoleted that card. So, I've been using just Windows XP on the laptop since converting it to a media center PC, because getting the S-video to work in Linux with the obsolete/unsupported drivers was a nightmare.

Windows, however, annoys me. I'm using the VLC Player for my DVD-playing needs, because it's pretty much the only program I can get to actually play DVD's. But it's annoying, and half the time when I start up Windows and tell VLC to play my DVD, VLC starts crashing the whole system really hard and forcing a reboot. I'd much rather have Linux around for situations like this.

Today I installed Ubuntu 9.10 on the laptop. I would've installed Fedora 12, but I don't have any LiveCD's handy at the moment. I installed it in a dual-boot way so that Windows XP is still there if things blow up.

So far, I'm pretty sure I'm using the default drivers Ubuntu picked for my video card, unless me installing "atitvout" accidentally pulled in the fglrx drivers or something. So it's either radeon or fglrx right now; I dunno which.

Anyway, the S-video port doesn't detect the TV at all without some manual fscking around with it. I eventually found a collection of xrandr commands I can run to force it to detect the S-video port and add an 800x600 mode to it and a couple other things.

I wound up writing this small shell script, so after I log on to the desktop I run this in the terminal and pray that the TV will get a signal from the laptop, and display a second desktop on it without it being all scrambled:

#!/bin/bash

xrandr
xrandr --output S-video --set load_detection 1
xrandr --output S-video --set tv_standard ntsc
xrandr --addmode S-video 800x600
xrandr --output S-video --right-of LVDS --mode 800x600

Here, LVDS is the built-in LCD screen on the laptop. Line 2 forces xrandr to detect S-video, line 3 sets it to use NTSC standards (PAL for outside the US), line 4 adds an 800x600 mode to it (which is pretty much standard for dinosaur TV's like the one I have), and line 5... might actually activate the second monitor and extend my desktop to it.

The last line there is hit-or-miss. It seems to have an 80% chance of showing a scrambled output on my TV, a 10% chance of sending no signal at all (TV goes to a black screen), and finally a 10% chance of doing what I want it to do: actually show my extended desktop clearly.

So, I copied that very last line into a separate shell script called "tv-retry.sh", so after running "tv-out.sh" (the first script) I run this second one for however many times it takes for my TV to show a clear picture.

Here's my terminal output from the last time I got the TV to work:

kirsle@ubuntu:~$ sh tv-out.sh
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2560 x 800
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 304mm x 190mm
1280x800       59.9*+
1280x720       59.9
1152x768       59.8
1024x768       59.9
800x600        59.9
640x480        59.4
S-video disconnected (normal left inverted right x axis y axis)
xrandr: cannot find mode 800x600
kirsle@ubuntu:~$ sh tv-out.sh
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2560 x 800
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 304mm x 190mm
1280x800       59.9*+
1280x720       59.9
1152x768       59.8
1024x768       59.9
800x600        59.9
640x480        59.4
S-video disconnected (normal left inverted right x axis y axis)
kirsle@ubuntu:~$
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
xrandr: cannot find mode 800x600
kirsle@ubuntu:~$ sh tv-retry.sh
xrandr: cannot find mode 800x600
kirsle@ubuntu:~$ sh tv-retry.sh
xrandr: cannot find mode 800x600
kirsle@ubuntu:~$ sh tv-out.sh
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2560 x 800
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 304mm x 190mm
1280x800       59.9*+
1280x720       59.9
1152x768       59.8
1024x768       59.9
800x600        59.9
640x480        59.4
S-video disconnected (normal left inverted right x axis y axis)
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-out.sh
Screen 0: minimum 320 x 200, current 2080 x 800, maximum 2560 x 800
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 304mm x 190mm
1280x800       59.9*+
1280x720       59.9
1152x768       59.8
1024x768       59.9
800x600        59.9
640x480        59.4
S-video connected 800x600+1280+0 (normal left inverted right x axis y axis) 0mm x 0mm
800x600        59.9*+   59.9*
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh
kirsle@ubuntu:~$ sh tv-retry.sh

It would've been much easier if this video card wasn't made obsolete right after I bought this laptop. Stupid ATI! This is why I like Nvidia more, just in case you were wondering; Nvidia works better in Linux, and they at least support their old unsupported cards (or somebody does, at least).

In Ubuntu Linux, all the graphical administrative applications (for example, user and group management) prompt you for your user password and not the root password. But in Fedora and many other Linux distributions, these apps always prompt for the root password.

Ubuntu by default follows some good security practices such as locking out the root password so that you can't log in directly as root (short of using sudo -i), but in Fedora systems if you lock out the root password, you can't use any of the graphical admin apps anymore since they ask for the root password.

So, here's how to set up Fedora to ask for the user password for graphical admin apps:

There are scripts in /etc/security/console.apps/ for most of the graphical admin apps, for example /etc/security/console.apps/system-config-users for the user & groups app. The general syntax for these files is like this:

USER=root
PROGRAM=/usr/share/system-config-users/system-config-users
SESSION=true

The general idea how to change it to ask for the user password is to add a line that says "UGROUPS=wheel" (where "wheel" is the name of a built-in group commonly used to give sysadmin capabilities to regular users). Then, any user who belongs to the "wheel" group will be asked to give their user password; all other users have to give the root password. Make sure your user belongs to the "wheel" group and you're all set.

On my Fedora 12 system though, all these scripts include /etc/security/console.apps/config-util first. So, my system-config-users script just said this:

. config-util
PROGRAM=/usr/share/system-config-users/system-config-users
SESSION=true

And my config-util file just said USER=root. So, I just added "UGROUPS=wheel" to config-util and now all my graphical admin apps ask me for my user password now, since all these files included config-util.

I discovered a neat trick you can do with PulseAudio: redirect the audio output of your computer to the microphone input, so that any application that supports recording from a mic will get your audio output instead.

I needed to do this because I was testing something at work that involved an Asterisk server calling a softphone running on my Linux box, and it wanted me to record a voice prompt and then hang up. This computer didn't have a microphone installed, so I started looking for a way to fake the mic input and make it record an MP3 or something instead.

If your system is using PulseAudio (every recent Fedora and Ubuntu distribution does), the steps to follow are:

1) Open PulseAudio Volume Control

This is pavucontrol on the command line, and in Fedora is provided by the package pavucontrol.

Go to the "Input Devices" tab, and select "Show: Monitors" from the bottom of the window. If your computer is currently playing audio, you should see a bar showing the volume of the output:

2) Start running an app that is recording audio, and go to the "Recording" tab and see if your app is listed.

In this screenshot I'm running Audacity and recording audio.

3) Click the input device button ("ALSA Capture from") and pick "Monitor of Internal Audio Analog Stereo")

And that's pretty much it. If you see volume bars on the Recording tab now then it's probably working, and the recording app is now recording your audio output.

Here's a full desktop screenshot of me running `play audiodump.wav` (a WMA-to-WAV conversion of the Windows XP Welcome Music) in a terminal, the PulseAudio Volume Control running, and Audacity recording from the mic.

Over a period of time I've put together two Perl scripts to help monitor a Linux desktop system.

Why? To see if anybody else uses my computer when I'm not there, and to see what they were doing with it.

screenspy - Linux desktop monitoring daemon

This is the visual desktop monitoring script. It takes quite a lot of screenshots during periods when the desktop is currently being used.

Basically, you run this script as root, and it monitors your major hardware input devices for any activity. By default it watches /dev/console (which, on Fedora systems, seems to output data whenever there's keyboard activity), and /dev/input/mice (which is a common node for the collective input of any and all mice attached to a computer).

When it sees any activity at all on either of these devices (it doesn't care what the devices are doing, it just cares that they're active), it begins taking screenshots. If you use the keyboard or mouse for a little bit, and then stop for 2 seconds, it takes a screenshot. If you use the keyboard or mouse constantly and don't stop, it will take a screenshot every 5 seconds.

So it essentially creates a visual log of everything you were doing on the computer; every time you type, stop typing, type like crazy, move the mouse, stop moving the mouse... anything that happens, a screenshot is taken.

It uses scrot to take the screenshot, since this is the lightest-weight screen capturing program I could find. Using ImageMagick's import command is slow, and makes the computer beep, and GNOME's screensaver application can't run without showing a GUI window.

You can check it out here. You'll be required to edit the script in the "configuration" section though, at least to change the directory where it saves the screenshots to.

Since the script runs as root, the images it creates are naturally owned by root as well, and can't be deleted by the nonprivileged user, even if the user does manage to find the screenshots. Better yet, you can have the screenshots saved under root's home directory, keeping them completely out-of-sight for the user. And, to kill the script, you have to be root since it will be a root-owned process. +1 if your unauthorized users don't know your root password!

keylog - A Simple Keylogger

This is just a simple keylogger that reads from one of the input event devices, like /dev/input/event0. You run it as root again, and it saves keystrokes to a file under /tmp.

Actually, it doesn't store all keystrokes; instead, it stores what the user "intended" to type. That is, if a user begins typing a sentence and makes a typo and hits backspace a few times and then continues typing, what gets logged is what they actually ended up typing... you don't see their typo; when they hit backspace, the log buffer also deleted the last character it logged, before saving it to disk.

It separates what they type based on certain "divider characters," which includes Tab, Return and Enter. So as they fill out a web form, the script would log one line of text for each field they filled out as they tab through the form. Also, if they delay their typing for a few seconds it will dump the current buffer to the log file as well, so if they're a particularly slow typer, one "sentence" may span multiple lines in the log file.

I can't recommend using this keylogger for malicious purposes, it's just being uploaded for educational purposes only and should only be used as a personal desktop monitoring solution, if it should be used at all.

Source code: keylog.

*bump* (added a new section about getting to other machines on the remote network via port forwarding) - Originally posted on Jan 11, 2010 @ 7:08:50 PM.

This blog post is primarily for my own reference, to avoid having to dig through the manual to look up the occasional edge case.

How to use SSH to do port forwarding. These assume you're on a Unix-like system (Linux or OS X) and not using some lame Windows client like PuTTy.

Forwarding Remote Ports to You

Example: you're behind a firewall at the office, and your home computer is listening on the SSH port. You can connect out of the office to your home computer, opening a port so that, once you're home, you can SSH back to the office again (bypassing the firewall).

ssh -R 9022:localhost:22 remotehost.com

This will open port 9022 on remotehost.com (loopback only; you can only connect to 9022 from the local remotehost.com, not from elsewhere on the internet), and forward it to "localhost:22", where "localhost" refers to your computer at the office, and 22 is of course the SSH port.

By default the remote host only would make port 9022 available on the loopback address, so from your home PC you can do ssh -p 9022 localhost and connect to it, but you can't do e.g. ssh -p 9022 remotehost.com and connect to it from somewhere else on the Internet.

To open the port on all interfaces (thus making it available on the internet too):

ssh -R *:9022:localhost:22 remotehost.com

Replace the * with any other bind address if you want.

Forwarding Local Ports to Remote

If your home computer is running a web server on port 80, and for some reason you can't get to it from the Internet (firewall blocking it, maybe), you can forward a local port on your office computer that gets you to port 80 on your home computer.

ssh -L 8080:localhost:80 remotehost.com

Here, 8080 is opened on your office computer, for the loopback interface only, and localhost:80 refers to port 80 on the remote (home) computer. It's the reverse of ssh -R.

Then you open Firefox and go to http://localhost:8080/ and yer in.

Another example: you have a VNC (remote desktop) server running on remotehost.com, but the VNC protocol itself is insecure, and you don't want your password being sent across the network in clear text to log in. So, you need your VNC traffic to be encrypted via SSH.

Here, remotehost.com is listening on port 5900 (the VNC port). You want to open a port on your local computer to the same number, so that you connect a VNC client to "localhost:5900" and it really connects you to "remotehost.com:5900" over a secure SSH tunnel:

ssh -L 5900:localhost:5900 remotehost.com

Then with your VNC client, just connect it to "localhost".

"Penetrating" the Remote Network

Use case scenario: I'm at the office, and at home only my main PC can be reached from the Internet (the router forwards all ports to it); but, I also left my laptop at home turned on and it has a VNC server and I wanna get remote desktop access to it from work. So I'll use my home PC to set up a bridge so I can connect to the VNC server on the laptop, which has a private LAN IP address of say, 10.10.1.101.

ssh -L 5900:10.10.1.101:5900 remotehost.com

Here "remotehost.com" goes to the main PC which I can access.

This opens up a listening port 5900 on my local (office PC) -- the first 5900 in the command -- and if I connect to it, it will use remotehost.com as a jumping off point to connect onward to 10.10.1.101:5900 (the laptop with a private LAN IP address on the remote network).

Then I point my VNC client at "localhost" and I end up with remote desktop on the laptop.

Using SSH as a Secure SOCKS 5 Proxy

As a bonus, here's how to open up a secure SOCKS 5 proxy over SSH:

ssh -D 8080 remotehost.com

Now you can configure your programs (e.g. Pidgin, Firefox) to use a SOCKS 5 proxy and have them connect to localhost:8080. All their internet traffic will be routed through the SSH tunnel to remotehost.com, secured, and then enter the cloud from there.

Additionally, this can be used to reach other devices on the remote server's LAN that you otherwise couldn't get to. For example, turn on your proxy settings in Firefox and you can navigate to http://192.168.1.1/ to log into the router from the remote LAN (as opposed to a router on your local LAN). The SOCKS 5 proxy would cause Firefox (or any other app configured to use it) to use "remotehost.com" as a jumping off point into the internet, so it can connect to other local network devices on its end just the same.