Machine #2 (Red Hat Linux 7.2 "firewall/gateway")
      -Two NICs
    One external IP eth0 (68.45.77.145)
    One internal IP eth1 (192.168.1.1)
      -Many services running on this machine
      -Packet filtering software running- ipchains
      -Masquerading (NAT) running
 
Machine #3 (Mandrake Linux 8.2 "the internet")
 -One NIC eth0 (external ip 68.45.76.219)
 -Apache webserver and ssh server running for demonstration purposes
-----------------------------------------------
Introduction:
The purpose of the discussion/demostration is to bring a typical Linux network setup into the meeting and discuss various principles involved in setup and administration.
Many specifics will left out, but the some principles will be discussed in detail.
They are as follows-
     1)Network diagnostics with tcpdump
     2)Advanced technique with ssh
--------------------------------------------------
--------------------------------------------------
1)tcpdump- a network monitoring program AKA a "sniffer"
   A.setting your NIC into the promiscuous mode
      From the terminal, as root, type
      tcpdump
      Watch network traffic as it comes into contact with the default interface of the machine (eth0 in this case).
      If you don't have the command available to you then you probably don't have the tcpdump program installed.
      it is available on the installation disks.
      If you use Debian you can just apt-get install it from the net. BTW- apt-get is now available for Red Hat and works nicely.
   B.tcpdump with option -i will allow you to indicate alternative interfaces other than the default (eth0)
  tcpdump -i eth1

   C.grep -v to filter noise
   Running tcpdump will many times output alot of network noise.
   For example, your ISP or some other program might be probing NICs for MAC addresses every few seconds.
   Use the pipe to output tcpdump into a grep filter.
   tcpdump | grep -v arp
   That command says listen to everything on the default interface, eth0, and output everything EXCEPT lines having the expression "arp" in them.
   This effectively filters out ISP MAC address probes so that you can just see packets that you are looking for.
   You can use the pipe and filter multiple times so that you can hone in on the specific output
   that you want to see to diagnose a network problem.
 
   For example, to get rid of mail traffic and DNS queries.
   tcpdump | grep -v arp| grep -v smtp| grep -v comcast.net.domain
 
   It also important to remember that if you are remotely connected via ssh and run the tcpdump sniffer
   you will be sniffing your own ssh transmissions.
   tcpdump will output over the network using the ssh protocol  which will create more ssh transmissions
   thereby effectively creating an infinite loop.
   To prevent infinite loops on remote ssh connections.
   tcpdump | grep -v ssh

Alternatively: tcpdump not ssh     works as well.
 
2)Reading the output of tcpdump
  The man page for tcpdump explains the above contents really well
  Excerpt from man tcpdump...

  TCP Packets

(N.B.:The following description assumes familiarity with
the TCP protocol described in RFC-793. If you are not
familiar with the protocol, neither this description nor
tcpdump will be of much use to you.)

The general format of a tcp protocol line is:
              src > dst: flags data-seqno ack window urgent options
Src and  dst are the source and destination IP addresses
       and ports.  Flags are  some  combination  of  S  (SYN),  F
       (FIN),  P  (PUSH)  or  R (RST) or a single `.' (no flags).
       Data-seqno describes the portion of sequence space covered
       by  the  data  in this packet (see example below).  Ack is
       sequence number of the next data expected the other direc-
       tion on this connection.  Window is the number of bytes of
       receive buffer space available the other direction on this
       connection.   Urg indicates there is `urgent' data in the
       packet.  Options are tcp options enclosed in angle  brack-
       ets (e.g., <mss 1024>).

       Src, dst and flags are always present.  The other fields
       depend on the contents of the packet's tcp protocol header
       and are output only if appropriate.

       Here is the opening portion of an rlogin from host rtsg to
       host csam.
           rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
                csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
                rtsg.1023 > csam.login: . ack 1 win 4096
          rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
              csam.login > rtsg.1023: . ack 2 win 4096
              rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
              csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
              csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
              csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
       The first line says that tcp port 1023 on rtsg sent a
packet to port login on csam. The S indicates that the
SYN flag was set. The packet sequence number was 768512
and it contained no data. (The notation is
`first:last(nbytes)' which means `sequence numbers first
up to but not including last which is nbytes bytes of user
data'.) There was no piggy-backed ack, the available
receive window was 4096 bytes and there was a max-segment-
size option requesting an mss of 1024 bytes.

Csam replies with a similar packet except  it  includes  a
       piggy-backed  ack  for  rtsg's SYN.  Rtsg then acks csam's
       SYN.  The `.' means no flags were set.   The  packet  con-
       tained  no data so there is no data sequence number.  Note
       that the ack sequence number is a small integer (1).   The
       first  time  tcpdump sees a tcp `conversation', it prints
       the sequence number from the packet.  On subsequent  pack-
       ets  of  the conversation, the difference between the cur-
       rent packet's sequence number and  this  initial  sequence
       number is printed.  This means that sequence numbers after
       the first can be interpreted as relative byte positions in
       the  conversation's  data stream (with the first data byte
       each direction being `1').  `-S' will override  this  fea-
       ture,  causing the original sequence numbers to be output.

       On the 6th line, rtsg sends csam 19 bytes of data (bytes 2
       through  20 in the rtsg -> csam side of the conversation).
       The PUSH flag is set in the packet.  On the 7th line, csam
       says it's received data sent by rtsg up to but not includ-
       ing byte 21.  Most of this data is apparently  sitting  in
       the  socket  buffer since csam's receive window has gotten
       19 bytes smaller.  Csam also sends one  byte  of  data  to
       rtsg in this packet.  On the 8th and 9th lines, csam sends
       two bytes of urgent, pushed data to rtsg.

       If the snapshot was small enough that tcpdump didn't  cap-
       ture  the  full  TCP  header, it interprets as much of the
       header as it can and then reports ``[|tcp]''  to  indicate
       the  remainder  could  not  be interpreted.  If the header
       contains a bogus option (one with a length  that's  either
       too  small  or  beyond  the  end  of  the header), tcpdump
       reports it as ``[bad opt]'' and  does  not  interpret  any
       further  options (since it's impossible to tell where they
       start).  If the header length indicates options  are  pre-
       sent but the IP datagram length is not long enough for the
       options to actually be there, tcpdump reports it as ``[bad
hdr length]''.
-----------------------------------------------------------------------

My  system's example output of listening to port eth0 while pointing web browser to google.com...
 
root@68.45.77.145~#tcpdump
tcpdump: listening on eth0
11:45:43.070306 ns01.trnrsv01.nj.comcast.net.domain > pcp113068pcs.wchryh01.nj.comcast.net.32841:  38065 1/4/4 A www.google.com (184) (DF)
11:45:43.070306 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: S 4218773802:4218773802(0) win 5840 <mss 1460,sackOK,timestamp 67829423 0,nop,wscale 0> (DF)
11:45:43.090306 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: S 280422526:280422526(0) ack 4218773803 win 32120 <mss 1460,sackOK,timestamp 75997387 67829423,nop,wscale 0> (DF)
11:45:43.090306 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 1 win 5840 <nop,nop,timestamp 67829425 75997387> (DF)
11:45:43.090306 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: P 1:551(550) ack 1 win 5840 <nop,nop,timestamp 67829425 75997387> (DF)
11:45:43.120307 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: . ack 551 win 31856 <nop,nop,timestamp 75997390 67829425> (DF)
11:45:43.490315 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: P 1:1323(1322) ack 551 win 31856 <nop,nop,timestamp 75997427 67829425> (DF)
11:45:43.490315 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 1323 win 7932 <nop,nop,timestamp 67829465 75997427> (DF)
11:45:43.660318 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: P 551:1109(558) ack 1323 win 7932 <nop,nop,timestamp 67829482 75997427> (DF)
11:45:43.710319 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: . ack 1109 win 31856 <nop,nop,timestamp 75997449 67829482> (DF)
11:45:43.720320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: P 1323:2771(1448) ack 1109 win 31856 <nop,nop,timestamp 75997449 67829482> (DF)
11:45:43.720320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 2771 win 11584 <nop,nop,timestamp 67829488 75997449> (DF)
11:45:43.720320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: P 2771:4219(1448) ack 1109 win 31856 <nop,nop,timestamp 75997449 67829482> (DF)
11:45:43.720320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 4219 win 14480 <nop,nop,timestamp 67829488 75997449> (DF)
11:45:43.720320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: P 5667:5759(92) ack 1109 win 31856 <nop,nop,timestamp 75997449 67829482> (DF)
11:45:43.720320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 4219 win 14480 <nop,nop,timestamp 67829488 75997449,nop,nop,sack sack 1 {5667:5759} > (DF)
11:45:43.720320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: P 4219:5667(1448) ack 1109 win 31856 <nop,nop,timestamp 75997449 67829482> (DF)
11:45:43.720320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 5759 win 17376 <nop,nop,timestamp 67829488 75997449> (DF)
11:45:43.740320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: . 5759:7207(1448) ack 1109 win 31856 <nop,nop,timestamp 75997452 67829488> (DF)
11:45:43.740320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 7207 win 20272 <nop,nop,timestamp 67829490 75997452> (DF)
11:45:43.740320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: . 7207:8655(1448) ack 1109 win 31856 <nop,nop,timestamp 75997452 67829488> (DF)
11:45:43.740320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 8655 win 23168 <nop,nop,timestamp 67829490 75997452> (DF)
11:45:43.750320 www.google.com.http > pcp113068pcs.wchryh01.nj.comcast.net.42082: P 8655:10087(1432) ack 1109 win 31856 <nop,nop,timestamp 75997452 67829488> (DF)
11:45:43.750320 pcp113068pcs.wchryh01.nj.comcast.net.42082 > www.google.com.http: . ack 10087 win 26064 <nop,nop,timestamp 67829491 75997452> (DF)
 
Notes:
 In line one you can see the DNS lookup for the google.com name space.
 In line two you can see a syn packet (indicated by the S) from my machine to google.com requesting a "conversation".
 In line two you can see that I'm requesting that the mss (maximum-segment-size) be set to 1460.
 In line three you can see google.com sending me a syn packet (indicated by the S) and an ack for my syn.
 So far, packet sequence numbers have been very high; 4218773802 on line 2 and 280422526 on line 3 and have contained no data as indicated by the (0).
 From now on the packet sequence numbers start at 1 and increment higher on the packet data size.
 Only acks are being sent from line 4 on. This indicates that a "conversation" is going on.
 Notice that packet data size sent by google.com never exceeds 1460 (the max. sent is 1448) as my machine requested in line two (mss 1460).
-----------------------------------------------------
-----------------------------------------------------
SSH
1)Automated remote ssh login (logging in without using a password)
     This is the quick and dirty way to get it done.
     On the machine you wish to ssh from...
     cd ~/.ssh
     ssh-keygen -t dsa
     Just enter through the password prompts and whatnot.
     scp id_dsa.pub some.remote.machine.address:~/
     ssh some.remote.machine.address
     cp id_dsa.pub .ssh/authorized_keys2
 
     Try it out.
     exit
     ssh some.remote.machine.address
 
     You should get no password prompt.
     You can use this new power to scp files automatically as in shell and cron scripts.
     Just be careful because a compromised system with automated remote ssh login enabled is a serious risk.
2)Running X Window System program over a network with ssh
   ssh some.remote.machine.address
   Run the program.
   evolution
   netscape
   scalc
   etc.
   The remotely opened X Window System program will run with files opened from the remote system directories.
   It will save files to the remote system directories.
   ssh network traffic is automatically authenticated, encrypted and compressed by using ssh protocol.
   You can have multiple ssh links on one system or multiple ssh hops and still run remote X Window System programs.