I started this post with the intention of covering basic ssh and ssh key usage at a novice level and then going on to more advanced topics such as discussing scp usage, the ssh-agent and how it’s used, tunneling, port-forwarding, proxy hoping and so on. As soon as I thought about it I realized, “Wow, this is going to take a while.” Instead of trying to tackle everything here I’m going to turn this into a series of posts, each covering a topic related to how I use ssh on a daily basis. I’ll kick this series off with some fundamentals of ssh and move on to more advanced topics in subsequent posts.

My assumption here is that you have a user account with access to a remote machine running a ssh server daemon. If you do not have a remote machine to test commands against there are free services such as http://sdf.org/ that you can use for testing.

I should also note here that throughout I’ll be basing my examples on Linux/OS X execution of ssh commands but they should produce almost identical results in Windows clients as well.

What is SSH aka Secure Shell

SSH is a secure network communication protocol that was designed to replace rlogin, rsh, telnet, and other insecure communication protocols. Because of it’s origins ssh is very similar in look and feel to it’s older counterparts however ssh never sends data “in the clear.” Instead, all data is encrypted and in general ssh protects against spoofing, interception and even intermediate data manipulation on systems you may be hoping through.

SSH has two main components, the client application and the server application. The client is what you will run on your local machine and it allows you to access a system that is running ssh server software. There are several open source projects, as well as commercial SSH, applications available, but OpenSSH, an open source solution, is probably the most common. It has been a long standing project dating back into the 1990’s and has a number of forks. Many of the commercial applications available are actually just clones or wrappers over OpenSSH.

Unix based systems such as OS X Mac’s and many Linux distributions come with at least the client version of OpenSSH pre-installed. For Windows you have to jump through some extra hoops and use something like Cygwin to install OpenSSH or you can use PuTTY, which is a free TTY emulation app, and while it’s not pretty it works like a champ. There are several other free and commercial apps available however so shop around if you want a second opinion.

There are countless tutorials on setup available for every OS, so I won’t get into installation here. To see if your current system is running an ssh client just open up your terminal application and type “ssh -V” to see your client and version number.

$ ssh -V OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011

Starting to Use Your SSH Client

SSH is used by most people at a very basic level, but to really get the most out of it, you have to break out the owners manual and see what you have under the hood. Once you get a feel for how it handles and some of the quirks, then you can take the next obvious step and make a general tune up. Before long you will spend a Sunday under the hood... I mean at your computer, doing an overhaul on your ~/ssh/config file to get more speed and productivity out of your ssh client.

Since we’re starting with “the fundamentals,” I’ll cover the most basic command which is logging into a remote system.

To use ssh you would usually open a terminal and type the ssh command accompanied with the username and hostname (or IP address) for the remote system you want to connect to. There are several ways to type the user and host options but the most common is ssh user “at” remote host.

$ ssh john.doe@example.com

Another way is to use the -l option to indicate the username.

$ ssh -l john.doe example.com

Both of the above commands are essentially the same. One uses the @ option to concatenate the user and host while the other uses the “-l” option to indicate the username will follow. This is just like anything in the development world: there are multiple ways to do everything.

For full disclosure I should also let you know that if your local username is the same as the username on the remote host, then you don’t even need to enter it.

$ ssh example.com

That’s all you would need because ssh will use your local username as its default if you don’t add it as a command option. Obviously, now you might want your usernames to match just to save you some extra typing if you happen to have a long name. Luckily there are ways to make per host defaults by tuning up your ssh config, but that’s coming up in another post.

Quite a few other options and defaults are applied to the basic login command that go unseen and are taken for granted. The port you connect to, the type of encryption used, and a number of other options all have default values that can be overridden and you may find yourself needing to do so on occasion. The most common option you will see overridden, besides the username option, is the port option. ssh uses port 22 as a default port for connections, but many admins will use an alternate port to add a bit more security through obscurity since most attacks are geared towards that very well known port and won't bother to actually check other ports.

Here’s an example login with an alternate port of 2222.

$ ssh john.doe@example.com -p 2222

To see a terse list of what options are available you can just check the ssh client by calling ssh without command options.

$ ssh usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-w local_tun[:remote_tun]] [user@]hostname [command]

That’s a lot of obscure options available. To see verbose details on each of the options check the man page entry on your system. This is where you really start to “read the manual.”

$ man ssh...

The output from the man page is incredibly long so please take a look for yourself. Even though the options are detailed the language isn’t very clear if you are new to networking but as more examples are given the options will start to make more sense.

At this point though you should have ssh installed and a very basic understanding of what ssh is and what it’s used for.

Up Next

For my next installment I’ll cover login basics and then in later parts well get into ssh key creation and usage. Read SSH Tips and Tricks (Part 2) - Host Key

Additional Resources

Webinar: A Drush Aliases Primer

Drush: Granting administrative permissions in Drupal

9 Steps to Sync your FileMaker data with Drupal