Step 2.1 Use the OpenSSH Tool Suite to Replace Clear-Text Programs

Problem: Now that the OpenSSH software is installed, we need to learn how to utilize it for invoking remote interactive connections and transferring files. We also need some way to verify that our connections are truly encrypted.

Action 2 1 1 Use OpenSSH as a replacement for telnet rsh rlogin

The ssh command is used to make secure, remote, interactive connections. This command can be used as the replacement for the unencrypted telnet , rsh and rlogin programs.

The format of the ssh command is as follows :
ssh [ -l login_name ] hostname user @hostname [ command ]

where:

• login_name = the account you are attempting to access on the remote system
• hostname = the remote system
• user@hostname = this is just an alternate format for combining account and remote system info
• command = the command on the remote host you are wanting to run; if you want an interactive shell, you would leave this blank

The following is an example where the local system is trying to connect to remote system server.example.com with account sshuser to run the ls ˆ’ l command:

$ ssh -l sshuser server.example.com ls -l
 The authenticity of host 'server.example.com (172.16.121.6)' can't be established.
 RSA key fingerprint is a4:f0:02:eb:11:84:70:c2:c3:24:18:61:89:49:ac:4b.
 Are you sure you want to continue connecting (yes/no)?

yes

Warning: Permanently added server.example.com,172.16.121.6' (RSA) to the list of known hosts

 total 3188
 -rw-r--r-- 1 sshuser admin 0 Feb 24 14:31 a
 drwxr-xr-x 10 sshuser admin 512 Dec 19 10:48 etc
 drwx------ 2 root other 512 Jun 26 2000 nsmail
 -rw-r--r-- 1 sshuser admin 1620193 May 15 2002 openssh31.zip
 $

The first several lines of output are normal for the first time you connect to a particular system running an sshd daemon “ after the first successful connection, you should not see these messages. However, prior to accepting this fingerprint and storing it in the list of known hosts, you will have to verify through a secure means that this is the correct fingerprint for the system to which you are attempting to connect.

In order to do this, somebody on the target machine will have to execute

$ ssh-keygen -l -f file

where file is the name of the host's public SSH key, such as /etc/ssh/ssh_host_key.pub . The result will look similar to the following and should match the key fingerprint previously given:

a4:f0:02:eb:11:84:70:c2:c3:24:18:61:89:49:ac:4b

Keep in mind that the fingerprint must be transmitted in a secure way (i.e. by a phone call to the administrator of the remote system), since SSH relies on these keys and the fingerprint is the simple proof for a valid key. For obvious reasons, SSH does not provide a way to fetch such fingerprints remotely from an SSH server.

Here is the second attempt using the same command:

$ ssh -l sshuser server.example.com ls
 [e-mail]'s password:
 nsmail
 openssh31.zip
 $

If you wish to connect to the remote system and receive a shell (as opposed to running a command and then exiting), then omit the optional "command string". For example:

$ ssh -l sshuser server.example.com
 [e-mail]'s password:
 Last login: Fri Nov 15 16:12:22 2002 from KII-1QZ7611
 Sun Microsystems Inc. SunOS 5.8 Generic February 2000
 $

You can now proceed just as if you had connected via "telnet" and nothing should appear different to you. The only difference is that all the communication between the local and remote systems are now encrypted.

Action 2 1 2 Use the sftp command as a replacement for FTP to exchange files with a remote system

The sftp command is used to perform file transfers to/from remote connections. This command can be used as the replacement for the unencrypted FTP program. This document assumes that you are familiar with FTP; sftp is very similar in that an initial command is issued to connect to an sftp server and if the authentication is successful, the client is placed into sftp interactive mode.

Although there are many options, the basic format of the sftp command is as follows :
sftp [ user @]hostname

where:

• user = the account you are attempting to access on the remote system “ if not specified, the current account name is assumed.
• hostname = the remote system

The following is an example where the local system connects via sftp to remote system server.example.com with account sshuser, then transfers a file from the remote /tmp filesystem:

$ sftp server.example.com
 Connecting to server.example.com...
 [e-mail]'s password:

********

sftp> cd /tmp
 sftp> ls
 .
 ..
 .X11-pipe
 .X11-unix
 .pcmcia
 .removable
 .s.PGSQL.5432
 dtdbcache_172.16.124
 dtdbcache_KII-1QZ7611:0
 openssh-3.4p1
 openssh-3.4p1.tar
 openssl-0.9.6g
 openssl-0.9.6g.tar
 perl-5.8.0-sol8-sparc-local
 ps_data
 snoop.txt
 sftp> lcd /tmp
 sftp> get snoop.txt
 Fetching /tmp/snoop.txt to snoop.txt
 sftp> bye
 $

If this sftp attempt is the first SSH connection attempted to the remote system, you will also receive an authenticity warning and a prompt similar to the following:

The authenticity of host 'server.example.com (172.16.121.6)' can't be established.
 RSA key fingerprint is a4:f0:02:eb:11:84:70:c2:c3:24:18:61:89:49:ac:4b.
 Are you sure you want to continue connecting (yes/no)?

yes

Note  

Once you enter "yes" to the prompt, the host will be added to the SSH "known hosts " file and you shouldn't be prompted with this information for subsequent attempts:

Warning: Permanently added 'server.example.com,172.16.121.6' (RSA) to the list of known hosts

Note  

It is strongly recommended that the host key be verified the first time it is used to prevent potential risk of man-in-the-middle attacks. See Action 2.1.1 for instructions to verify the host's fingerprint.

You can also specify the user name as part of the sftp connection command, as shown below:

$ sftp [e-mail]
 Connecting to server.example.com...
 [e-mail]'s password:

*********

sftp>

There are many command line options to sftp, too numerous to cover in this document. As always, use the man command to get the details, as shown below:

$ man sftp
 Reformatting page. Please Wait... done

 User Commands SFTP(1)

 NAME
 sftp - Secure file transfer program

 SYNOPSIS
 sftp [-vC1] [-b batchfile] [-o ssh_option] [-s subsystem 
 sftp_server] [-B buffer_size] [-F ssh_config] [-P
 sftp_server path] [-R num_requests] [-S program] host
 sftp [[user@]host[:file [file]]]
 sftp [[user@]host[:dir[/]]]

 DESCRIPTION
 sftp is an interactive file transfer program, similar to
 ftp(1), which performs all operations over an encrypted
 ssh(1) transport. It may also use many features of ssh,
 such as public key authentication and compression. sftp
 connects and logs into the specified host, then enters an
 interactive command mode.

 The second usage format will retrieve files automatically if
 --More--(13%)

You can use the Solaris snoop utility to verify that FTP does not encrypt communication and that sftp does encrypt “ see Action 2.1.5 for examples of using the snoop utility.

Action 2 1 3 Use the scp command as a replacement for rcp to exchange files with a remote system

The scp (secure copy) command is used to copy files and directories to and from remote servers. This command can be used as the replacement for the unencrypted rcp program. The scp command can also be used as a substitute for sftp , although there are some key differences.

One difference is that scp does not have an "interactive" mode as sftp does and therefore doesn't have as many capabilities, although it is still a quite powerful utility. One advantage of scp over sftp is that directory and recursive copies are much easier. Additionally, the scp command can be used in conjunction with an .shosts file to bypass interactive authentication “ this is strongly discouraged since it provides yet another avenue for attackers . See Action 2.1.4 for more detail regarding host-based authentication with .shosts files.

So, if you have a need to copy directory entries in addition to files and/or you need to copy a directory structure recursively, scp is probably what you should use. If you're copying files only and they exist in multiple directories, or if you prefer interactivity, sftp is probably the better choice.

Although there are many options, the basic format of the scp command is as follows :

scp [options] [[ user @]host1:] path -to-source [ ] [[ user2@]host2: ] path-to-destination

Where:

• options = one of the valid options as referenced in the scp man page
• user = the account you are attempting to access on the remote system “ if not specified, the current user name will be assumed.
• hostX = the remote system(s) to which you are attempting to copy to/from
• path-of-source = the source location of files/directories to copy
• path-of-destination = the destination location of files/directories to copy

The following example uses scp to duplicate the FTP file transfer from the last example (host is server.example.com , account is sshuser , file is /tmp/snoop.txt ):

$ scp [e-mail]:/tmp/snoop.txt .
 [e-mail]'s password:

********

snoop.txt 100% ***************************** 7956 00:00
 $ ls -l
 total 24
 drwxr-xr-x 2 root root 512 May 20 1999 103346-22
 drwxr-xr-x 3 sshuser 150 512 Nov 10 09:39 ns_imap
 drwx------ 2 sshuser 150 512 Nov 10 09:39 nsmail
 -rw-r--r-- 1 sshuser 150 7956 Dec 18 14:30 snoop.txt
 drwxrwxr-x 3 root other 512 Jul 10 1999 upgrade
 $

Besides the obvious advantage of encrypting communication, note that another advantage of scp over rcp is the verification of completion and the reporting of the number of bytes transferred.

You can also omit the user name as part of the command; if you do so, then the current user name will be assumed, as shown below:

$ scp server.example.com:/tmp/snoop.txt .
 [e-mail]'s password:

*******

snoop.txt 100% ***************************** 7956 00:00
 $

In this example, we use the command line options -r to recursively copy a directory structure and -p to keep the original permissions of all files and directories:

$ scp -pr [e-mail]:/tmp/patches /tmp
 [e-mail]'s password:

********

105395-09.tar.Z 100% ***************************** 537 KB 00:00
 107684-09.zip 100% ***************************** 851 KB 00:00
 110615-09.zip 100% ***************************** 868 KB 00:01
 dsmerror.log 100% ***************************** 150	00:00

The source directory is /tmp/patches , which is a directory with three subdirectories. The destination directory on the local machine is /tmp , so this command completely duplicates the /tmp/patches directory from host server.example.com to the local host, assuming your account has read permissions for all the files and directories in this structure. A quick way to verify that everything was copied is to use the du -sk command on both systems and compare the byte count, as shown below:

$ du -sk /tmp/patches
 2284 /tmp/patches

Both systems should now report the same or roughly the same byte total. A more thorough method for verifying byte totals is to take checksums of files that were copied via scp. See the man pages for cksum, sum or other checksum utilities, depending on the flavor of UNIX you are using. Here's an example of using the cksum command:

$ find . -type f xargs cksum
 2795861523 550601 ./2.6/105395-09.tar.Z
 405161581 872202 ./7/107684-09.zip
 2165853569 889286 ./8/110615-09.zip
 3510532143 150 ./8/dsmerror.log

Note that since we used the "-p" command line option to perform the copy, all permissions of the /tmp/patches and child sub-directories and files should be as they exist on the source system.

It should be noted that both sftp and scp can be utilized for "puts" as well as "gets" ” all of the previous examples have demonstrated "gets". A "put" would be initiated from the machine where the data to be copied exists. The following example does the previous transfer in reverse, using "put" rather than "get":

$ scp -pr /tmp/patches [e-mail]:/tmp
 [e-mail]'s password:

********

105395-09.tar.Z 100% ***************************** 537 KB 00:00
 107684-09.zip 100% ***************************** 851 KB 00:00
 110615-09.zip 100% ***************************** 868 KB 00:00
 dsmerror.log 100% ***************************** 150 00:00
 $ uname -a
 SunOS client.example.com 5.8 Generic_108528-16 sun4m sparc SUNW,SPARCstation-20

scp has many other command line options - to see them, issues scp with on options:

$ scp
 usage: scp [-pqrvBC46] [-F config] [-S program] [-P port]
 [-c cipher] [-i identity] [-o option]
 [[user@]host1:]file1 [...] [[user@]host2:]file2

For more detail of each option, refer to the scp man page.

Action 2 1 4 Use of Unix rhosts shosts files for OpenSSH host based authentication

Host-based authentication, with or without SSH, is considered a security danger in that it does not require interactive authentication (such as a password or passphrase). Host-based authentication is configured with various files to allow automatic (i.e. non-interactive) connections from one UNIX system to another. Since the use of UNIX host-based authentication is strongly discouraged from a security standpoint, the authors initially decided to simply mention the dangers of OpenSSH host-based authentication but not cover details for how to use it. However, we realized that in most environments, improving security via tools such as OpenSSH is rarely an "overnight" endeavor and therefore it is unrealistic to think that one can instantly eliminate the use of host-based authentication. We realize that while few will argue that host-based authentication is dangerous, it is also reality. Therefore, this section will briefly demonstrate OpenSSH's version of host-based authentication, although it is important to note that utilizing OpenSSH with host-based authentication only improves security from the encrypted channel standpoint ” it does not improve the authentication weakness inherent with host-based authentication .

Normal UNIX host-based authentication is performed via the /etc/ hosts .equiv file and .rhosts files. The /etc/hosts.equiv file should be considered the most dangerous and most easily abused method and should never be used ” it performs authentication via client hostnames (or IP addresses) only. The .rhosts file performs authentication on a client hostname AND account name basis. OpenSSH can utilize existing /etc/hosts.equiv and .rhosts files as they exist for host-based authentication. OpenSSH can also utilize the .shosts file - which is simply an optional alternate name for .rhosts files. If you are currently utilizing an .rhosts file for host-based authentication, OpenSSH will also use that file once the host-based authentication is configured properly. You are not required to rename the .rhosts file to .shosts , although it may be a good idea to do so from the standpoint of users taking note of .shosts files and therefore realizing that SSH is in use on your server system.

OpenSSH host-based authentication requires configuration settings on both the SSH client machine (the one initiating the connection) and the server machine (the machine running the "sshd" daemon and performing the authentication).

Tech Tip  

Each account on the SSH client can override settings in the OpenSSH system-wide configuration file (e.g. /usr/local/etc/ssh_config ) by creating his/her own settings file in $HOME/.ssh/config . If a setting is not found in $HOME/.ssh/config , OpenSSH will then check the system-wide file. Configuration settings can also be specified on the command line. For example:

$ ssh -o "ForwardX11 yes" -o "Compression yes" server.example.com
 Enter passphrase for key '/export/home/user_a/.ssh/id_rsa':

command line options always override configuration file settings.

Client Settings

The following configuration option must be set as below in the /usr/local/etc/ssh_config file ( assuming that OpenSSH was installed into /usr/local and that you are using SSHv2):

HostbasedAuthentication yes

(The corresponding setting for SSHv1 is "RhostsAuthentication")

Server Settings

1. The following configuration options must be set as below in the /usr/local/etc/sshd_config file (assuming that OpenSSH was installed in /usr/local and you are using SSHv2):

   HostbasedAuthentication yes
    IgnoreRhosts no
   

   (The corresponding setting for host-based authentication for SSHv1 is "RhostsAuthentication")
   Note that the comments in the sshd_config file say to not use Host-based authentication - use at your own risk!

2. Any SSH client that wishes to connect to this SSH server must be "known" - i.e., the clients ' host keys must exist in the appropriate known_hosts file, either $HOME/.ssh/known_hosts for the server user account to which the connection will be made, or the system-wide /usr/local/etc/sshd/ssh_known_hosts file. An easy way to add the SSH client's host key to one of these files is to make an SSH connection from the server (which now temporarily becomes the SSH client) back to the client (temporarily the SSH server). Remember, you will have to first start the "sshd" daemon on the remote system before it will accept connections.
3. Create the .rhosts or .shosts file, if it doesn't already exist. There is no change in format for OpenSSH - use the same format as if you were performing host-based authentication without SSH. The .rhosts/.shosts file should contain one line for each remote client/account name combination that this server will allow to connect via host-based authentication. The first column contains the hostname, the second column is the account name. Spaces or tabs can separate the columns . Here is an example .rhosts file:

   myclient user_a
    myclient.example.com user_a
   

   Both entries here actually refer to the same machine/account - one is just fully qualified. This practice helps to eliminate problems with name resolution and host-based authentication.

4. The SSH server uses a reverse IP lookup as part of the host-based authentication procedure. Therefore, it is important that each portion of the configuration ( known_hosts, .rhosts/.shosts , DNS or /etc/host file) utilize a consistent form for hostname verification/authentication - i.e. non-qualified ( myclient ) or fully-qualified ( myclient.example.com ). In many environments, DNS is the first entity used for hostname lookups. If DNS returns a fully qualified hostname, the SSH host-based authentication may fail, since the known_hosts file may have non-qualified hostname entries. Therefore you will also need to do one of two things in this regard to make sure that the SSH server can properly authenticate the SSH client:
   1. Modify the SSH server's /etc/hosts file to include an entry for the remote SSH client's IP address and hostname. Make sure that you have a non-qualified entry for the hostname so that it will match the hostname associated with the host in the known_hosts file ($HOME/.ssh/known_hosts or /usr/local/etc/ssh_known_hosts). For example, here is an /etc/hosts entry which includes both the non-qualified and fully-qualified hostnames:

      172.16.121.16 myclient myclient.example.com
      

      Next, you may need to modify the SSH server's hostname lookup order, i.e., to search the local /etc/host file for hostname lookups BEFORE searching DNS, so that the non-qualified hostname will be returned. For many Unix versions, the file which controls this is /etc/nsswitch.conf . Following is a portion of that file modified for this example:

      passwd: files
       group: files
       hosts: files dns
       ipnodes: files
      

      OR

   2. Modify the SSH server's known_hosts file to utilize a fully-qualified domain name for the SSH client's host-key entry. Here is a modified entry:

      
      myclient.example.com
      
      ,172.16.121.16 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAr7HxNPFUK2zWaLUSyi/ROby
      
       VPESK9X17HKLaiCKFsxEfvAc6fsLNfRVosQRLeuep/qR7ghbwscUB7PbRE1hK58aohXQUV/VXKlF4G4v
       P6wGNCfdwH9BjTrftDrEbzWprvaAD12fI1l+cjwydrp24+EQsIfHkcrwSP1ZRdk+3TDk=
      

Now that you've made all required host-based authentication configuration changes, you should be able to connect from the SSH client to the SSH server without having to enter a passphrase or password:

$ ssh -l sshuser server.example.com
 Last login: Fri Apr 25 11:03:47 2003 from openv3
 $ uname -a
 SunOS kfs16 5.8 Generic_108528-06 sun4m sparc SUNW,SPARCstation-20
 $

Here's another example, where a single host-based authenticated command is issued from the SSH client to the SSH server:

$ ssh -l sshuser server.example.com "ls -l"
 total 3188
 drwxr-xr-x 10 sshuser admin 512 Dec 19 10:48 etc
 -rw-r--r-- 1 sshuser admin 1620193 May 15 2002 openssh31.zip

Action 2 1 5 Verify the SSH encryption

How can one be sure that the SSH session is indeed encrypted? UNIX/Linux systems provide various network packet inspection utilities which verify ” to a certain extent ” that the transmitted data is encrypted. Following are two examples of connections that are "sniffed" by the Solaris snoop utility “ the first shows a clear-text telnet session while the second shows an encrypted SSH session. TCPDUMP and Ethereal are functionally similar open -source tools which you might also consider for this purpose.

Example 1 Snoop output of telnet session

• First, we'll need to login to the root account on the telnet server ( server.example.com ) since the snoop utility requires root permissions. Issue the following snoop command to start capturing network connection information originating from the SSH client machine ( client.example.com ) and related to port 23 (which is the default telnet port):

  $ su -
   Password: ********
   # snoop -o /tmp/snoop.txt port 23 client.example.com
   Using device /dev/le (promiscuous mode)
   0
  

This command saves all the snoop output into a file for later viewing. In the next step, we'll connect from the client via telnet and the packet counter (the 0 shown above) should start increasing to reflect that packets are being captured.

• Next, open a telnet connection to the server from the client, then immediately exit, as shown below:

  $ telnet server.example.com
   Trying 172.16.121.6...
   Connected to server.example.com
   Escape character is '^]'.
  
   SunOS 5.8
  
   login: sshuser
   Password: *******
   Last login: Sat Apr 12 19:03:52 from 172.16.122.159
   $ exit
  

• Now go back to the server session and press CTRL+C to abort the snoop packet capturing. The packet counter displayed by snoop should have incremented, reflecting the number of packets it has "captured" from the network traffic. Use the following command to read what snoop captured:

  # snoop -i /tmp/snoop.txt more
  
   (some output cut for brevity)
  
   3 0.00078 client.example.com -> server.example.com TELNET C port=33861
   4 0.02125 client.example.com -> server.example.com TELNET C port=33861
   5 0.00008 server.example.com -> client.example.com TELNET R port=33861
   6 0.28402 server.example.com -> client.example.com TELNET R port=33861
   7 0.00069 client.example.com -> server.example.com TELNET C port=33861
   8 0.00043 server.example.com -> client.example.com TELNET R port=33861
   9 0.00028 client.example.com -> server.example.com TELNET C port=33861
   10 0.09378 server.example.com -> client.example.com TELNET R port=33861
   11 0.00028 client.example.com -> server.example.com TELNET C port=33861
   12 0.00008 server.example.com -> client.example.com TELNET R port=33861
   13 0.00386 client.example.com -> server.example.com TELNET C port=33861 7
   72
  

  # snoop -i /tmp/snoop.txt more (some output cut for brevity) 3 0.00078 client.example.com -> server.example.com TELNET C port=33861 4 0.02125 client.example.com -> server.example.com TELNET C port=33861 5 0.00008 server.example.com -> client.example.com TELNET R port=33861 6 0.28402 server.example.com -> client.example.com TELNET R port=33861 7 0.00069 client.example.com -> server.example.com TELNET C port=33861 8 0.00043 server.example.com -> client.example.com TELNET R port=33861 9 0.00028 client.example.com -> server.example.com TELNET C port=33861 10 0.09378 server.example.com -> client.example.com TELNET R port=33861 11 0.00028 client.example.com -> server.example.com TELNET C port=33861 12 0.00008 server.example.com -> client.example.com TELNET R port=33861 13 0.00386 client.example.com -> server.example.com TELNET C port=33861 3773 7230VT320377360377372#openv 14 0.02279 server.example.com -> client.example.com TELNET R port=33861 15 0.09331 client.example.com -> server.example.com TELNET C port=33861 16 0.00014 server.example.com -> client.example.com TELNET R port=33861 17 0.00158 client.example.com -> server.example.com TELNET C port=33861 18 0.00048 server.example.com -> client.example.com TELNET R port=33861 19 0.09758 client.example.com -> server.example.com TELNET C port=33861 20 4.28797 server.example.com -> client.example.com TELNET R port=33861 ****** ************** 21 0.09277 client.example.com -> server.example.com TELNET C port=33861 22 0.00027 server.example.com -> client.example.com TELNET R port=33861 23 0.09940 client.example.com -> server.example.com TELNET C port=33861 24 0.78898 client.example.com -> server.example.com TELNET C port=33861 s 25 0.00031 server.example.com -> client.example.com TELNET R port=33861 s 26 0.10070 client.example.com -> server.example.com TELNET C port=33861 27 0.19873 client.example.com -> server.example.com TELNET C port=33861 s 28 0.00037 server.example.com -> client.example.com TELNET R port=33861 s 29 0.01794 client.example.com -> server.example.com TELNET C port=33861 h 30 0.00024 server.example.com -> client.example.com TELNET R port=33861 h 31 0.09264 client.example.com -> server.example.com TELNET C port=33861 32 0.18913 client.example.com -> server.example.com TELNET C port=33861 u 33 0.00033 server.example.com -> client.example.com TELNET R port=33861 u 34 0.03462 client.example.com -> server.example.com TELNET C port=33861 s 35 0.00026 server.example.com -> client.example.com TELNET R port=33861 s 36 0.09568 client.example.com -> server.example.com TELNET C port=33861 37 0.17001 client.example.com -> server.example.com TELNET C port=33861 e 38 0.00035 server.example.com -> client.example.com TELNET R port=33861 e 39 0.07298 client.example.com -> server.example.com TELNET C port=33861 r 40 0.00047 server.example.com -> client.example.com TELNET R port=33861 r 41 0.09634 client.example.com -> server.example.com TELNET C port=33861 42 0.00008 server.example.com -> client.example.com TELNET R port=33861 Password: 43 0.09982 client.example.com -> server.example.com TELNET C port=33861 44 1.47820 client.example.com -> server.example.com TELNET C port=33861 B 45 0.09170 server.example.com -> client.example.com TELNET R port=33861 46 0.14235 client.example.com -> server.example.com TELNET C port=33861 ony 47 0.09765 server.example.com -> client.example.com TELNET R port=33861 48 0.19136 client.example.com -> server.example.com TELNET C port=33861 9t 49 0.09859 server.example.com -> client.example.com TELNET R port=33861 50 0.23350 client.example.com -> server.example.com TELNET C port=33861 o 51 0.09662 server.example.com -> client.example.com TELNET R port=33861 52 0.01480 client.example.com -> server.example.com TELNET C port=33861 e 53 0.09507 server.example.com -> client.example.com TELNET R port=33861 

  VT3207072#

  # snoop -i /tmp/snoop.txt more (some output cut for brevity) 3 0.00078 client.example.com -> server.example.com TELNET C port=33861 4 0.02125 client.example.com -> server.example.com TELNET C port=33861 5 0.00008 server.example.com -> client.example.com TELNET R port=33861 6 0.28402 server.example.com -> client.example.com TELNET R port=33861 7 0.00069 client.example.com -> server.example.com TELNET C port=33861 8 0.00043 server.example.com -> client.example.com TELNET R port=33861 9 0.00028 client.example.com -> server.example.com TELNET C port=33861 10 0.09378 server.example.com -> client.example.com TELNET R port=33861 11 0.00028 client.example.com -> server.example.com TELNET C port=33861 12 0.00008 server.example.com -> client.example.com TELNET R port=33861 13 0.00386 client.example.com -> server.example.com TELNET C port=33861 3773 7230VT320377360377372#openv 14 0.02279 server.example.com -> client.example.com TELNET R port=33861 15 0.09331 client.example.com -> server.example.com TELNET C port=33861 16 0.00014 server.example.com -> client.example.com TELNET R port=33861 17 0.00158 client.example.com -> server.example.com TELNET C port=33861 18 0.00048 server.example.com -> client.example.com TELNET R port=33861 19 0.09758 client.example.com -> server.example.com TELNET C port=33861 20 4.28797 server.example.com -> client.example.com TELNET R port=33861 ****** ************** 21 0.09277 client.example.com -> server.example.com TELNET C port=33861 22 0.00027 server.example.com -> client.example.com TELNET R port=33861 23 0.09940 client.example.com -> server.example.com TELNET C port=33861 24 0.78898 client.example.com -> server.example.com TELNET C port=33861 s 25 0.00031 server.example.com -> client.example.com TELNET R port=33861 s 26 0.10070 client.example.com -> server.example.com TELNET C port=33861 27 0.19873 client.example.com -> server.example.com TELNET C port=33861 s 28 0.00037 server.example.com -> client.example.com TELNET R port=33861 s 29 0.01794 client.example.com -> server.example.com TELNET C port=33861 h 30 0.00024 server.example.com -> client.example.com TELNET R port=33861 h 31 0.09264 client.example.com -> server.example.com TELNET C port=33861 32 0.18913 client.example.com -> server.example.com TELNET C port=33861 u 33 0.00033 server.example.com -> client.example.com TELNET R port=33861 u 34 0.03462 client.example.com -> server.example.com TELNET C port=33861 s 35 0.00026 server.example.com -> client.example.com TELNET R port=33861 s 36 0.09568 client.example.com -> server.example.com TELNET C port=33861 37 0.17001 client.example.com -> server.example.com TELNET C port=33861 e 38 0.00035 server.example.com -> client.example.com TELNET R port=33861 e 39 0.07298 client.example.com -> server.example.com TELNET C port=33861 r 40 0.00047 server.example.com -> client.example.com TELNET R port=33861 r 41 0.09634 client.example.com -> server.example.com TELNET C port=33861 42 0.00008 server.example.com -> client.example.com TELNET R port=33861 Password: 43 0.09982 client.example.com -> server.example.com TELNET C port=33861 44 1.47820 client.example.com -> server.example.com TELNET C port=33861 B 45 0.09170 server.example.com -> client.example.com TELNET R port=33861 46 0.14235 client.example.com -> server.example.com TELNET C port=33861 ony 47 0.09765 server.example.com -> client.example.com TELNET R port=33861 48 0.19136 client.example.com -> server.example.com TELNET C port=33861 9t 49 0.09859 server.example.com -> client.example.com TELNET R port=33861 50 0.23350 client.example.com -> server.example.com TELNET C port=33861 o 51 0.09662 server.example.com -> client.example.com TELNET R port=33861 52 0.01480 client.example.com -> server.example.com TELNET C port=33861 e 53 0.09507 server.example.com -> client.example.com TELNET R port=33861
  

  openv 14 0.02279 server.example.com -> client.example.com TELNET R port=33861 15 0.09331 client.example.com -> server.example.com TELNET C port=33861 16 0.00014 server.example.com -> client.example.com TELNET R port=33861 17 0.00158 client.example.com -> server.example.com TELNET C port=33861 18 0.00048 server.example.com -> client.example.com TELNET R port=33861 19 0.09758 client.example.com -> server.example.com TELNET C port=33861 20 4.28797 server.example.com -> client.example.com TELNET R port=33861 ****** ************** 21 0.09277 client.example.com -> server.example.com TELNET C port=33861 22 0.00027 server.example.com -> client.example.com TELNET R port=33861 23 0.09940 client.example.com -> server.example.com TELNET C port=33861 24 0.78898 client.example.com -> server.example.com TELNET C port=33861 s 25 0.00031 server.example.com -> client.example.com TELNET R port=33861 s 26 0.10070 client.example.com -> server.example.com TELNET C port=33861 27 0.19873 client.example.com -> server.example.com TELNET C port=33861 s 28 0.00037 server.example.com -> client.example.com TELNET R port=33861 s 29 0.01794 client.example.com -> server.example.com TELNET C port=33861 h 30 0.00024 server.example.com -> client.example.com TELNET R port=33861 h 31 0.09264 client.example.com -> server.example.com TELNET C port=33861 32 0.18913 client.example.com -> server.example.com TELNET C port=33861 u 33 0.00033 server.example.com -> client.example.com TELNET R port=33861 u 34 0.03462 client.example.com -> server.example.com TELNET C port=33861 s 35 0.00026 server.example.com -> client.example.com TELNET R port=33861 s 36 0.09568 client.example.com -> server.example.com TELNET C port=33861 37 0.17001 client.example.com -> server.example.com TELNET C port=33861 e 38 0.00035 server.example.com -> client.example.com TELNET R port=33861 e 39 0.07298 client.example.com -> server.example.com TELNET C port=33861 r 40 0.00047 server.example.com -> client.example.com TELNET R port=33861 r 41 0.09634 client.example.com -> server.example.com TELNET C port=33861 42 0.00008 server.example.com -> client.example.com TELNET R port=33861 Password: 43 0.09982 client.example.com -> server.example.com TELNET C port=33861 44 1.47820 client.example.com -> server.example.com TELNET C port=33861 B 45 0.09170 server.example.com -> client.example.com TELNET R port=33861 46 0.14235 client.example.com -> server.example.com TELNET C port=33861 ony 47 0.09765 server.example.com -> client.example.com TELNET R port=33861 48 0.19136 client.example.com -> server.example.com TELNET C port=33861 9t 49 0.09859 server.example.com -> client.example.com TELNET R port=33861 50 0.23350 client.example.com -> server.example.com TELNET C port=33861 o 51 0.09662 server.example.com -> client.example.com TELNET R port=33861 52 0.01480 client.example.com -> server.example.com TELNET C port=33861 e 53 0.09507 server.example.com -> client.example.com TELNET R port=33861

Note the ASCII representation of the dialogue in the far right column. You can see that in this example, the account name and password are in clear-text and easy to detect! This is why telnet and FTP are called "clear-text" utilities “ all communication is sent over the network in clear-text.

Example 2 Snoop output of SSH session

• Now that we know how to use snoop, we can snoop the output of an SSH session and demonstrate that it is encrypted. First, start the snoop session on the server, looking for traffic from client client.example.com and port 22 (which is the default SSH port), as shown below:

  # snoop -o /tmp/snoop.txt port 22 client.example.com
   Using device /dev/le (promiscuous mode
   0
  

• Next, connect via OpenSSH from the client machine and issue an ls command, as shown below:

  $ ssh -l sshuser server.example.com
   [e-mail]'s password:
   Last login: Mon Apr 14 11:13:12 2003 from client.example.com.
   $ ls
   a etc nsmail openssh31.zip
  $
  

• Now go back to the server session and press CTRL+C to abort the snoop packet capturing.
• Use the following command to read what snoop captured:

  # snoop -i /tmp/snoop.txt more
  
   (some output cut for brevity)
  
   1 0.00000 client.example.com -> server.example.com TCP D=22 S=33874 Syn Seq=1
   61238050 Len=0 Win=24820 Options=
   2 0.00003 server.example.com -> client.example.com TCP D=33874 S=22 Syn Ack=1
   61238051 Seq=3683871110 Len=0 Win=24820 Options=
   3 0.00097 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683871111 Seq=161238051 Len=0 Win=24820
   4 0.07606 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61238051 Seq=3683871111 Len=22 Win=24820
   5 0.00067 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683871133 Seq=161238051 Len=0 Win=24820
   6 0.19015 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683871133 Seq=161238051 Len=22 Win=24820
   7 0.00007 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61238073 Seq=3683871133 Len=0 Win=24820
   8 0.01781 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683871133 Seq=161238073 Len=544 Win=24820
   9 0.07882 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61238617 Seq=3683871133 Len=544 Win=24820
   10 0.01344 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683871677 Seq=161238617 Len=24 Win=24820
   11 0.09352 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61238641 Seq=3683871677 Len=0 Win=24820
   12 0.05308 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61238641 Seq=3683871677 Len=424 Win=24820
   13 0.09536 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683872101 Seq=161238641 Len=0 Win=24820
   14 0.74769 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683872101 Seq=161238641 Len=416 Win=24820
   15 0.09385 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61239057 Seq=3683872101 Len=0 Win=24820
   16 1.00661 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61239057 Seq=3683872101 Len=736 Win=24820
   17 0.10202 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683872837 Seq=161239057 Len=0 Win=24820
   18 0.96630 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683872837 Seq=161239057 Len=16 Win=24820
   19 0.09513 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61239073 Seq=3683872837 Len=0 Win=24820
   20 0.00081 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683872837 Seq=161239073 Len=48 Win=24820
   21 0.04351 server.example.com -> client.example.com TCP D=33874 S=22 Ack=1
   61239121 Seq=3683872837 Len=48 Win=24820
  

Note that in this snoop output, there is no readable data in the far right-hand column, since all the data is encrypted.

• For a more thorough analysis of the network packets, you can use the "-x 0" parameter to snoop that will display data in both hex and ASCII format. Note the encryption-related detail displayed in the far right column:

  # snoop -i /tmp/snoop.txt -x 0 more
  
   (some output cut for brevity)
  
   0: 0800 2077 0121 0800 207a 6ae5 0800 4500 .. w.!.. zj...E.
   16: 0028 d071 4000 4006 2027 ac10 7906 ac10 .(.q@.@. '..y...
   32: 7910 0016 8452 db93 699d 099c 4c39 5010 y....R..i...L9P.
   48: 60f4 e539 0000 '..9..
  
   8 0.01781 client.example.com -> server.example.com TCP D=22 S=33874 Ack=3
   683871133 Seq=161238073 Len=544 Win=24820
  
   0: 0800 207a 6ae5 0800 2077 0121 0800 4500 .. zj... w.!..E.
   16: 0248 684f 4000 4006 8629 ac10 7910 ac10 .HhO@.@..)..y...
   32: 7906 8452 0016 099c 4c39 db93 699d 5018 y..R....L9..i.P.
   48: 60f4 8725 0000 0000 021c 0914 b507 d790 '..%............
   64: 8d12 568c 6627 7c75 9487 347b 0000 003d ..V.f'u..4{...=
   80: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g
   96: 726f 7570 2d65 7863 6861 6e67 652d 7368 roup-exchange-sh
   112: 6131 2c64 6966 6669 652d 6865 6c6c 6d61 a1,diffie-hellma
   128: 6e2d 6772 6f75 7031 2d73 6861 3100 0000 n-group1-sha1...
   144: 0f73 7368 2d72 7361 2c73 7368 2d64 7373 .ssh-rsa,ssh-dss
   160: 0000 0066 6165 7331 3238 2d63 6263 2c33 ...faes128-cbc,3
   176: 6465 732d 6362 632c 626c 6f77 6669 7368 des-cbc,blowfish
   192: 2d63 6263 2c63 6173 7431 3238 2d63 6263 -cbc,cast128-cbc
   208: 2c61 7263 666f 7572 2c61 6573 3139 322d ,arcfour,aes192-
   224: 6362 632c 6165 7332 3536 2d63 6263 2c72 cbc,aes256-cbc,r
   240: 696a 6e64 6165 6c2d 6362 6340 6c79 7361 ijndael-cbc@lysa
   256: 746f 722e 6c69 752e 7365 0000 0066 6165 tor.liu.se...fae
   272: 7331 3238 2d63 6263 2c33 6465 732d 6362 s128-cbc,3des-cb
   288: 632c 626c 6f77 6669 7368 2d63 6263 2c63 c,blowfish-cbc,c
   304: 6173 7431 3238 2d63 6263 2c61 7263 666f ast128-cbc,arcfo
   320: 7572 2c61 6573 3139 322d 6362 632c 6165 ur,aes192-cbc,ae
   336: 7332 3536 2d63 6263 2c72 696a 6e64 6165 s256-cbc,rijndae
   352: 6c2d 6362 6340 6c79 7361 746f 722e 6c69 [e-mail]
   368: 752e 7365 0000 0055 686d 6163 2d6d 6435 u.se...Uhmac-md5
   384: 2c68 6d61 632d 7368 6131 2c68 6d61 632d ,hmac-sha1,hmac-
   400: 7269 7065 6d64 3136 302c 686d 6163 2d72 ripemd160,hmac-r
   416: 6970 656d 6431 3630 406f 7065 6e73 7368 ipemd160@openssh