SSH is quite the Swiss Army Knife of networking. One powerful feature that I can never remember is securely tunneling from one machine to another, possibly through a firewall. To do this:

ssh -f matlik@home -L 3000:www.google.com:80 -N

In this example, a proxy connection is established between my local machine’s port 3000 and my home machine (an alias in ~/.ssh/config) on the normal SSH port. Then my home machine relays any network traffic on to google.com on port 80.

Here is another example of making a HTTP server listening only to localhost (not 0.0.0.0) and therefore not handling requests from the outside world accessible from another machine in the “outside world”. Note that the “localhost” in the below command is from the perspective of the remote server.

ssh -f matlikj@192.168.1.4 -L 8000:localhost:8000 -N

• The -f flag requests ssh to go to background just before command execution.
• The -L flag binds a local port to a remote port.
• The -N flag tells ssh not to execute any commands on the remote server, which is useful when forwarding traffic from one machine to another is the goal, as in these examples.

Maintaining such a connection for an extended period of time, particularly if the connection goes through periods of idleness, may be problematic. It is common practice for connections to be dropped when not actively used. If you find that you need to keep the connection alive, you can do a few things:

1. Update your ~/.ssh/config file to contain the settings ServerAliveInterval 180 and ServerAliveCountMax xxxx where the ServerAliveInterval defines how frequently a keep alive ping should be sent over the open connection, and the ServerAliveCountMax defines how many pings should be performed without real traffic before closing.
2. Use another program like autossh
3. Use a shell script to establish the SSH connection in an infinate loop (hackish and messy).

While this isn’t a perfect replica, it does work relatively well:

bash> ps axf

This output generates a process tree for everything running on the system, not just a subtree for a specified process, so you are best off piping this to less and searching within. It can be a bit more clunky as a result, but the end result is the same.

There are obviously many parameters that may be required to support various security setings; however the below satisfies my need for a small home network where I am trying to mount a shared directory on my wife’s machine onto my local Ubuntu box.

bash> mount -t cifs -o username=guest,iocharset=utf8 $SMB_SHARE $MNT_POINT

• The cifs filesystem type has replaced the smbfs predecessor
• username=guest can only be used if the shared directory does not require authentication
• Specifying iocharset=utf8 enables unicode characters in file names to render properly. This, of course, assumes both the Windows box and Linux box support the UTF8 encoding.
• The SMB_SHARE shell variable would of a format similar to //192.168.1.5/Share
• The MNT_POINT shell variable corresponds to the mount destination

Bash supports both emacs and vi edit modes, allowing users familiar with those editors to use the commands they are most familiar with. The emacs mode is active by default, but this can be changed using the following command:

bash> set -o vi

This can subsequently be changed back to emacs using the obvious alteration:

bash> set -o emacs