Open Discussion: OpenSSH Essentials

Journal Trolling4Dollars's Journal: Open Discussion: OpenSSH Essentials 3

Journal by Trolling4Dollars on Wednesday April 28, 2004 @11:59AM

Update 04292004:
Thank you GigsVT and Jeremiah Cornelius for the suggestions. I was not aware of 'rsync' and it's flexibility in that way. I will have to experiment with that as it sounds VERY useful. In the interest of standard tools that most *nixes are equipped with, the 'tar' command in this context is also handy to be familiar with in a pinch. Jeremiah Cornelius' suggestions of the --exclude flag is VERY important if you intend to make a full backup of a *nix box and not trun into problems. I had forgotten that I ran into EXACTLY the problem mentioned with /proc (endless loop) when I tried doing a hard drive to hard drive copy with 'tar'. I've edited the example commands below to reflect both of your suggestions. Hopefully, if more people join in, I will have more changes to make. :) (hint hint... come on folks, we're geeks, let's talk about geek stuff in our JEs!)

Today we will talk about running X applications remotely using OpenSSH. There are a couple of components required to get this to work:
1. You need to have an X server running on the machine in front of you. (Think of an X server as a virtual video monitor with multiple input connectors and the remote applications as different video sources)
2. The ssh server on the system you are connecting to, must be configured to (tunnel) forward X.

If you are on the Windows platform, you can either purchase a commercial X server, or do as I do and use Cygwin's excellent free X server. Again... try to imagine that the X server on the machine in front of you "virtualizes" your monitor and makes it "networkable". When you run the X server, it opens a connection on your machine listening for traffic coming from either the network, or (on *nix) shared memory. When you run an X application, it is instructed to connect to the X server so the Xserver can display it's output. (Just like plugging in a game console to one of your TV/Monitor's composite inputs)

This is all well and good if you can trust the network that your X traffic is travelling on. But, what if you can't? Or what if you just don't want your traffic out in the clear? This is where ssh and X make a pretty good team. You still run your X server on the machine in front of you like usual. But instead of instructing the remote application to connect directly to it, you use ssh's X Protocol Forwarding so that all X traffic is sent through an encrypted TCP tunnel.

SSH Server End Preparations
You will need to edit your sshd_config file which controls how your SSH server works. You would make these changes on the machine you are connecting to. First, find your sshd_config file. Typically, it's in /usr/local/etc if you compiled the OpenSSH suite yourself or if the package maintainer went with defaults. In other cases it could be in /etc/openssh or /usr/local/etc/openssh. To verify for your distribution, you can run the 'find' command:

find /usr -name sshd_config

Once you've located it, make sure you add these lines to it for TCP and X Forwarding:

AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

You will then need to restart your ssh server so that it reads the new configuration.

Testing from the workstation in front of you
Now we can test and see if we can forward a simple X app over the ssh tunnel. Assume that I am using yesterday's ~/.ssh/config file and have a 'work' profile. Also assume that the remote system has the simple X application 'xeyes' in /usr/X11R6/bin:

ssh -X work "/usr/X11R6/bin/xeyes"

We should now be seeing the familiar googly eyes peeking at us. All the application execution is happening remotely, but displaying in front of us and it's coming over an encrypted ssh tunnel to boot!

Add it to your ~/.ssh/config file
For each connection profile you put in your ~/.ssh/config file, you can add:

ForwardX11 yes

This means that all you would have to do to run a remote X app is either log into a shell using that profile and type the name of the X app you want to use, or... You can create a script to run the app using ssh and make an icon for it on your Windows Quick Launch bar or Gnome Panel. A sample script in Linux would be:

#!/bin/bash

ssh work "/usr/local/bin/gimp"

Pretty simple, huh? In Windows, you can write a CMD file using about the same syntax:

C:\cygwin\usr\local\bin\ssh work -F "C:\Documents and Settings\mikey\.ssh\config" "/usr/local/bin/gimp"

You can argue that this is a form of "application publishing" to use a friendly term. But it's really a way of exploiting the features of X in a more secure way. Once everything is configured, it works pretty seamlessly as well.

Compression
This X traffic can take up some bandwidth, and I personally don't use it unless I have a fast connection. I still tend to prefer 'vnc' over ssh for most instances. However, there is something you can do which might help out a little in terms of speed. You can compress your ssh traffic. Just add these lines to each host profile in your ~/.ssh/config file:

Compression yes
CompressionLevel 9

You can set your CompressionLevel to anything between 1 and 9 with '1' being the fastest but worst compression, and 9 being slow but better. There is a slight improvement in X application performance. This compression applies across the board to any ssh traffic for that connection profile though, so it's handy to add it to your slower connections.

Final Words
Again, I don't pretend to know everything there is about ssh or X and I am sure there are other ways that this can be done better. But that's why I started this JE. I am hoping that some of you will have more suggestions like GigsVT and Jeremiah Cornelius.

Original JE 04282004:
A good while back, I wrote a very nice tutorial on OpenSSH explaining how I had used it to create some limited tunnels between my network and my friend's and family's PCs. I clicked submit and figured it made it into my Journal. I checked back later and saw to my horror that it wasn't there. So... instead of doing all that all over again, I'm starting an open discussion instead of what I did before.

Some things to spark discussion:

Q1. Isn't OpenSSH just an encrypted telnet program?
A1. Short answer, no. It's a suite of programs that provides:
-remote shell access
-remote execution of applications (both text and gui)
-data compression
-TCP tunneling
-ftp-like file transfers
-rcp-like file copying
-public key encryption/authentication (no passwords)
-GUI login prompt for remote execution of X applications with 'gnome-ssh-askpass' And I'm sure there's more... I'm kind of an intermediate user of OpenSSH.

Q2. Setting up tunnels is a pain. What's up with this Local/Remote Forward crap?
A2. Actually, 'man ssh_config' is your friend. If you become familiar with the ~/.ssh/config file, you will find yourself not needing to type much to make conenctions with OpenSSH. For example, I've set up some parameters in my ~/.ssh/config file and called the profile "home". Now I just type: 'ssh home' and I'm in. Folling is an example of what to put in your ~/.ssh/config file:
-Assume that I am connecting from my house (192.168.1.0)
-192.168.1.5 is my web server at home
-192.168.1.2 is my workstation at home
-10.0.x.x is the network at work
-My workstation at work is 10.0.5.5 Example '~/.ssh/config':

# My 'webserver' connection profile. All I
# need to do to ssh into the web server now
# is type 'ssh webserver'. I am automatically
# prompted for the password for 'mikey'.
host webserver
hostname 192.168.1.5
User mikey
# My 'work' connection profile with non
# standard port for ssh (2020).
#
# I've also included one LocalForward line to
# forward port 80 from a web server at work to
# port 4080 on my workstation in front of me.
# So... if I connect with 'ssh work' and log in,
# and point my browser here at home to
# 127.0.0.1:4080, I see the internal web site
# at work here at home. :)
#
# The RemoteForward line works in reverse. It
# sends specified TCP ports from my workstation
# in front of me to my workstation at work. In
# this case, OpenSSH is pushing port 5900 (vnc)
# from 192.168.1.2 (here at home) to my
# workstation at work. If I leave this connection
# up and go to work. I can run 'vncviewer
# 127.0.0.1:0' and log into my workstation at home
# with vnc.
host work
hostname 10.0.5.5
port 2020
User porkman
LocalForward 4080:intranet.myjob.com:80
RemoteForward 5900:192.168.1.2:5900

Q3. Yeah... but I use Windows and I don't have time to mess with Linux. So how does this help me?
A3. There are two ways to get OpenSSH going under Windows and still enjoy all the benefits. One is to use Cygwin and the other is to download the prebuilt OpenSSH installer. These days, it's better to use Cygwin and just install what you need. I will be providing links for those who are interested in the ensuing discussion. As a side note, I played around with compiling the latest OpenSSL/SSH in Cygwin. It's pretty straightforward if you aren't the sort who is afraid to get into a little *nix command line. The benefit of doing this is that you can then package your own "VPN Client" with just the programs and libraries needed to make your ssh connection for tunneling. I did this and worked it down to about a 2 Meg package. If there is anyone out there who is a little more up on security than I am, I wouldn't mind putting together some instructions on how to do this at a later date. I just don't trust that I got everything "right" in my package even though it works well enough.

Q4. Why are the docs about OpenSSH on the net so hard to understand?
A4. To each his own. However, I will say that it took me a good deal of digging to try and find some useful info for tunneling and Public Key info. Yes, the documentation could use some major improvements for people who are a little less technically adept. To be honest, I think a nice GUI framework around OpenSSH would go a long way to getting more people to use it. Yeah, there's PuTTY for Windows and it can be made to work in the context of what we're talking about here, but it has the problem of just presenting itself as a telnet-like client and immediately turning people off. "I never use shells or command line, why would I need an ssh client". If there was just an OpenSSH standalone "Tunneling" GUI app, I think more interest in OpenSSH would grow on the Windows side. Still, when it comes to the basics of OpenSSH on Unix, the man pages are currently the best resource. The best places to look are:

'man sshd_config' - Tweak your ssh server just right
'man ssh_config' - Find out what else you can do with ~/.ssh/config
'man scp' - You can copy files AND directories using 'scp'
'man sftp' - Used to use this all the time, but have since moved to 'scp'. However, it's good to know how to use it in a pinch.
'man ssh' - Check out the less frequently used options.

Q5. Someone mentioned that I can use 'ssh' in combination with 'tar' for remote backup. Is that true?
A5. More or less, depending on what you consider a useful backup. I've used ssh and tar for "imaging" Linux boxes. It works well, but has expected limitations. A quick example of using ssh, tar, and gzip to "image" BoxA to BoxB. Assume that we have set up ~/.ssh/config to include all needed info for username and hostname:

Backing up '/' on BoxA to BoxB, intitiated from BoxB:
ssh BoxA "tar -cf - / --exclude=/proc/* --exclude=/var/tmp/*" | gzip -c > /home/admin/images/BoxA.tar.gz

Restoring '/' to BoxC from the archive on BoxB, intiated from BoxC:
ssh BoxB "gunzip -c /home/admin/images/BoxA.tar.gz" | (cd / ; tar -xvf -)

Using 'rsync':
rsync -av -e "ssh -c arcfour" user@host:/remotedirectory /localdirectory
Remember 'man rsync' is your friend...

Well... that's it for now. I know that there are people more equipped to discuss this than I am, but I am hopeing to attract the curious who haven't had the time or energy to try. Hopefully this will spark some interesting discussion.

This discussion has been archived. No new comments can be posted.