SSH (Secure SHell) is a suite of protocols used for secure remote authorization and information transfer that is encryption protocol independent. Tools based on SSH can be used to replace telnet, ftp, and rexec.
Return to Top of Page
With the advent of networks came the lazy user who wished to utilize the network to access systems remotely. Out of this desire, tools such as telnet, ftp, and rexec were born.
telnet allows a user to establish an interactive session with a remote host.
ftp allows a user to transfer file(s) from one system to another.
rexec allows a user to execute a command on a remote system without creating a full interactive session.
Return to Top of Page
telnet, ftp, and rexec are valuable tools that do exactly what they were intended to do. As time passed people learned how to capture data flowing over a network. With telnet, ftp, and rexec sending all data (including username and password) in clear text and people being able to see network traffic we now have the problem that usernames and passwords are now available to anyone. This is not good.
SSH solves this by encrypting all communications. People can still capture the network traffic and look at it but all they see is garbage (the encrypted information). When a strong encrytion algorithm is used with SSH the data is practically impossible to deduce. Not only is your username and password safe from inspection but so is all of your data. Another benefit of SSH is that it provides data integrity, unlike telnet, ftp, and rexec.
Return to Top of Page
To start with, SSH v1 is the predecessor of SSH v2. Both are good ways to encrypt data/sessions. SSH v1 has a couple of flaws. SSH v2 is more robust.
For SSH v1, the encrypted data size highly correlates to the raw data size. By "watching" an SSH v1 session and by knowing what happens in a session it is possible to determine the length of username and password.
Also, SSH v1 can allow for man-in-the-middle (MITM) attacks. Tools exist to allow another machine to insert itself between the client and server and decrypt the session in real-time.
Since SSH v2 does not have these failings it is clearly superior to SSH v1. However, SSH v1 is a very useable, encrypted solution, when compared to the unencrypted predecessors. It far exceeds the original telnet, ftp, and rexec. Running SSH v1 is like a 1000% improvement over the older tools, where SSH v2 would be a 2000% improvement.
For the remainder of this presentation, we will concern ourselves primarily with SSH v2.
Return to Top of Page
SSH uses "public / private" (asymmetric) key pairs as well as "secret" (symetric) keys to authenticate remote hosts, encrypt sessions, and user authentication.
To use a "public / private" key, a public and private key pair is generated. The public key is then shared and is used to encrypt data. Only the private key can decrypt data that has been encrypted with the corresponding public key. A private key can not be derived from its public key. This makes it safe to give everyone a public key. Public keys can only encrypt data and private keys can only decrypt data.
To use a "secret" key, only a single key is generated. This key is used to both encrypt and decrypt data. The problem with this approach is sharing the secret key between both systems without compromising its value.
So, why should you care? Normally, a user supplies the server with their password at the beginning of a session. Unfortunately this is not practical for non-interactive sessions (i.e. automated scripts like cron). Supplying a password every time is also considered inconvenient by some users which is why the old tools like rsh and rlogin were created. A user can utilize keys for authentication instead of the user's password on the server. The user first generates a public / private key pair and then somehow places the public key on the server. Using keys this way makes it possible for SSH to authenticate a user without requiring a password.
Return to Top of Page
Lets break the SSH session down into five layers.
The first layer is independent of SSH. The client contacts the server and a TCP session is created.
At the SSH-TRANS layer, the server sends its public key to the client. The client has the responsibility of ensuring that the server's public key is authentic. The client looks for the server name in its local key table (.ssh/known_hosts2). If the server name is not found, the user will be prompted to add the server name/key to the table. If the server name is found but has a different key, the user will be told that the keys differ and will be warned of a possible man-in-the-middle (MITM) attack.
During this layer, the client and server negotiate which encryption algorithm to use. The session key will also be exchanged.
SSH-AUTH is where the client authenticates its user to the server. This may be done via password, key, or host-based authentication. This layer could also be skipped if user authentication is unnecessary (i.e. anonymous SFTP).
At this layer, SSH handles TCP port forwarding (i.e. X sessions, VNC, ...), remote execution (i.e. rexec like functionality), and interactive session (i.e. telnet parameter negotiations). This is also where compression of data is done if enabled.
Now the actual application (terminal emulation, file transfer, etc.) takes over. The previous layers were done to get to the point where this application could perform its function.
Return to Top of Page
The sshd (SSH server daemon) is able to output log information. In the UNIX world this is usually done via the syslog facility. sshd can report every SSH attempt (successful or not). Here is a small excerpt from a sylog file showing examples of sshd messages:
Jan 14 07:04:50 srvr sshd[889]: authentication failure; logname= tty=ssh ruser= rhost=a.c.d user=root Jan 14 07:04:52 srvr sshd[889]: Failed password for ROOT from 10.0.1.21 port 49154 ssh2 Jan 14 07:04:59 srvr sshd[901]: session opened for user root by (uid=0) Jan 14 07:04:59 srvr sshd[901]: Accepted password for ROOT from 10.0.1.21 port 49154 ssh2 Jan 14 09:43:08 srvr sshd[907]: session opened for user root by (uid=0) Jan 14 09:43:08 srvr sshd[907]: Accepted password for ROOT from 10.0.1.58 port 32993
The first two lines show a single unsuccessful attempt to login. Lines three and four show all the information for a successful login session. Notice that each line provides a date/time and the attempted userid. The last two lines show a single successful login session using SSH v1 (notice that ssh2 is not appended on these lines).
Return to Top of Page
SSH servers are available for many different platforms from several different sources. Here are a few:
| Vendor | License | Supported Platforms | URI |
|---|---|---|---|
| OpenSSH/OpenBSD Project | Open Source | AIX, HP-UX, Irix, Linux, NeXT, SCO, SNI/Reliant Unix, Solaris, Digital Unix/Tru64/OSF, MacOS X, Cygwin | http://www.openssh.com |
| SSH Communications Security | Commercial | SuSE and Redhat Linux 2.2.x; Solaris 2.6, 7, 8; HP-UX 10.20, 11.x; AIX 4.3.x; FreeBSD, NetBSD, BSDI, OpenBSD; OSF/1 4.0, Tru64, Digital Unix; Microsoft Windows NT 4.0 Server or Workstation (Service Pack 5 or above); Microsoft Windows 2000 | http://www.ssh.com |
| F-Secure | Commercial | All major Unix platforms; Solaris, Linux, HP-UX, AIX, BSD Windows 2000, Windows NT 4.0 | http://www.f-secure.com |
Return to Top of Page
Many different clients are available for many platforms. Here are a few:
| Vendor | License | Supported Platforms | URI |
|---|---|---|---|
| OpenSSH/OpenBSD Project | Open Source | AIX, HP-UX, Irix, Linux, NeXT, SCO, SNI/Reliant Unix, Solaris, Digital Unix/Tru64/OSF, MacOS X, Cygwin | http://www.openssh.com |
| Simon Tatham (Putty) | Open Source | Windows (95, 98, ME, NT, 2000) | http://www.chiark.greenend.org.uk/ ~sgtatham/putty |
| appGATE | Commercial (free for non-commercial use) | Java version that may be run in most Java-enabled browsers | http://www.appgate.org/ag.asp?template= products&level1=product_mindterm |
| SSH Communications Security | Commercial | iWindows platforms: 95, 98, NT 4.0, 2000, Me and XP; Unix platforms: Sun Solaris 2.6, 7 and 8, HP/UX 11.x and 10.20, AIX 4.3.x and Linux 2.2.x | http://www.ssh.com |
| F-Secure | Commercial | All major Unix platforms: Solaris, Linux, HP-UX, AIX, BSD; Windows: XP, 2000, NT 4.0, 95, 98, ME, MacOS | http://www.f-secure.com |
| Jean-Pierre Stierlin (MacSSH) | Shareware | Mac OS 8, 9, X | http://www.macsecsh.com |
| Jonas Wallden (NiftyTelnet 1.1 SSH r3) | Freeware | Mac OS | http://www.lysator.liu.se/ ~jonasw/freeware/niftyssh |
Return to Top of Page
Here are a number of links regarding SSH that you might find interesting:
| URI | Comments |
|---|---|
| http://www.openssh.com | Home page for the Open SSH project by OpenBSD. A great implementation of SSH and a lot of good infomation. |
| http://www.ssh.com | Home page of the primary commercial SSH vendor. A lot of good stuff here also. |
| http://www-106.ibm.com/developerworks/library/l-keyc.html | RSA/DSA authentification, Article explaining keys and key management. |
| http://www.isp-planet.com/equipment/ssh_intro.html | SSH: From Secure Administration to Virtual Private Networking |
| http://www.csua.berkeley.edu/ssh-howto.html | How to use SSH |
| http://www.inf.bme.hu/~mulzs/sshfaq/ssh-faq.html | The Secure Shell (SSH) Frequently Asked Questions |
| http://www.boran.com/security/sp/ssh-part1.html | All About SSH Replacing telnet/rlogin/rsh with SSH |
| http://sysadmin.oreilly.com/news/sshtips_0101.html | O'Reilly SysAdmin News: Top Ten Secure Shell FAQs |
| http://sysadmin.oreilly.com/news/silverman_1200.html | O'Reilly SysAdmin News: dsniff and SSH |
| http://www.lsu.edu/ocs/hpc/ssh.html | LSU OCS HPC SSH Documentation |
SSH Reference Book
| O'Reilly Books | SSH: The Secure Shell by Daniel J. Barrett and Richard E. Silverman, ISBN: 0-596-00011-1 |
Return to Top of Page
This page last updated 2002/01/15 12:39:55.