HELPMEUSETECH'S BLOG

In our technological infancy, no one really was very concerned about security. Use of the telnet application was the common method used to establish text-based connections to remote systems. The downside of telnet is that all of the traffic (usernames, passwords and data) are transmitted in what is known as plaintext or cleartext. That is, it is completely visible to anyone who can watch the traffic on your connection. As we became more aware of the security risks and as “bad guys” became more aggressive in trying to obtain and use personal information, we developed a need for a more secure method of connecting to remote destinations– Secure Shell.

For those of us who work in an environment with many different flavors of Linux, UNIX, Windows and Mac computers, being able to securely access and interact with different machines, transfer data and run command-line applications is essential to our productivity.  One very valuable tool which provides much of this functionality is Secure Shell (ssh). Secure Shell is a standards-based, secure network protocol which can support remote command execution, data transfer or tunneling over otherwise insecure networks. The ssh system follows a basic client-server model where an ssh server is running on the machine you wish to connect to. An ssh client is used to validate your identity and establish a secure connection to the server on the remote system using public key cryptography mechanisms. All modern operating systems support ssh client software and virtually all non-Microsoft operating systems come with an ssh package already installed. Within Windows, you must install third-party software to provide ssh client and server support. The default port used for ssh is 22. Configuration of ssh and associated port forwarding will be considered beyond the scope of this post.

Lets assume that you have access to a remote machine that has an ssh server installed and properly configured.  The first time you attempt to connect to the server, you will see something like this:

$ ssh sample@10.0.1.37
The authenticity of host '10.0.1.37 (10.0.1.37)' can't be established.
RSA key fingerprint is d3:7f:16:f8:5c:55:9b:63:c4:c7:4d:ad:df:ff:1f:ea.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.1.37' (RSA) to the list of known hosts.
sample@10.0.1.37's password:
Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-15-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

*** /host/ubuntu/disks/home.disk will be checked for errors at next reboot ***

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

sample@ubuntu:~$

This very simple connection allows you to now work interactively with the remote system. For all practical purposes, it is as if you were sitting at the console of the other machine. The very first time that you connect to an ssh server, the authenticity of the remote machine cannot be verified. The RSA key fingerprint exchange that is done during the first login allows you to be certain that in the future, you are talking to the same host that you initially made contact with.  If not, you will receive a warning that the identity was not correct and you won’t be able to proceed. When working from a UNIX-based system, a hidden directory called .ssh will be created in your home directory when you use ssh for the first time. It stores information about known hosts that you have successfully connected to in the past (known_hosts) as well as public and private RSA keys that help verify your identity.

In addition to bringing up an interactive shell, you may issue specific commands that will be executed on the remote system, like this:

$ ssh sample@10.0.1.37 date
sample@10.0.1.37's password:
Mon Feb 20 12:59:29 PST 2012
$ 

$ ssh sample@10.0.1.37 df -h /
sample@10.0.1.37's password:
Filesystem            Size  Used Avail Use% Mounted on
/dev/loop0             29G  3.7G   24G  14% /
$

Granted, the examples above are not the most useful commands, but they do show how to pass commands directly to the remote system for execution. Once the command is executed, the connection is broken and you again receive a command prompt on your local system.

Now, suppose that your mission was to report on how much disk space was available on a large number of systems. You could easily write a script that would just pull the available disk space from the output of the command that was executed remotely.  The example below runs the ssh connection command in a sub-shell by putting it in parenthesis. In this case, it assures us that all of the output of the command is returned over the ssh connection so it can be processed on our local machine.  Without the parenthesis, the entire command would have been executed remotely. The command below shows a UNIX pipeline which, in my opinion, is one of the most powerful concepts in computer science. In short, the output of the first command is passed as input into the second command, the output of the second command is passed to the third, and so on. Each additional piece of the command pipeline can further process or alter the results as they pass by. This alleviates the need to store the output of each operation in a temporary file. This example pulls the fourth field from all lines that contain the string “loop”.

$ (ssh sample@10.0.1.37 df -h /) | grep loop | awk '{print $4}'
sample@10.0.1.37's password:
24G
$

As you might imagine, entering your password every time you want to connect to a remote system can become quite a chore. Many experienced users establish an environment which will allow them to connect to remote machines without entering a password for each connection attempt.  This is known as passwordless-ssh. Essentially, you share a copy of your RSA public key with the host that you would like to connect with. This allows the remote system to verify your identity by matching the shared key with your account information.  Some benefits of passwordless-ssh include the ability to automate interaction with the remote machines without the need to hard-code passwords within the scripts.  On the negative side, if any one of the machines becomes compromised, the perpetrator may impersonate you as they connect to any other machine in your network where your key has been shared. This may be considered a security risk by some organizations. Several different methods exist for creating and sharing these RSA keys. Specific implementation details for each type of system are beyond the scope of this particular post.

One of the things that makes ssh so useful is its simplicity.  Any command that you can run from the command line on the remote system can be executed over ssh.

So far, we have covered remote access, remote command execution and passwordless-ssh. A future post will cover tunneling over ssh, data transfer using the ssh protocol and some tips and tricks to allow you to make the most out of using ssh.