% Nick Urbanik <nicku@vtc.edu.hk>
% Copyright 2000 under the conditions of the GNU Free Documentation License,
% a copy of which is available at http://www.gnu.org/copyleft/fdl.html
% Copy and modify freely as long as this paragraph remains intact.
% Suggestions for improvement (and the improvements themselves!) welcome.
\chapter{SSH --- The Secure Shell}
\label{cha:secure-shell}
{\mns

\subsection{Objectives}

\begin{itemize}
\item After completing this section, you will be able to:
  \begin{itemize}
  \item Use secure shell as a replacement for {\cmdn telnet}

  \item Understand the weaknesses of the secure shell, and in
    particular, how to protect your connections from being hijacked

  \item Understand some of the dangers of {\cmdn telnet}

  \item Use {\cmdn scp} to copy files

%   \item Install and use {\cmdn sftp} as a secure replacement for
%     {\cmdn ftp}
    
  \item Understand how to create private and public keys for the
    secure shell using {\cmdn ssh-keygen}
    
  \item Understand how to configure the files {\fn
      $\sim$/.ssh/authorized\_keys}, {\fn /etc/ssh/ssh\_known\_hosts} with
    public keys
    
  \item Know how to configure {\pgn ssh-agent} and {\pgn ssh-add} to
    allow login without a password.

  \item Be able to configure some important options of the client and
    server, including X11 forwarding.
  \end{itemize}
\end{itemize}


\section{What is the Secure Shell?}
\label{sec:what-is-ssh}

\begin{itemize}
\item Allows users to log into remote computers and use them
  interactively.

\item Provides secure network access for system administrators,
  replacing obsolete protocols such as {\cmdn telnet} and many others
  
\item Allows tunneling of other protocols (such as X) through the
  encrypted connection

\item Allows secure, encrypted copying of data over the Internet with
  {\pgn scp}

\item Very useful for remote backup of servers and firewalls.

\item After it is set up, it is very easy to use
\end{itemize}  


\section{But what's wrong with {\cmdn telnet}?}
\label{sec:telnet-problems}

\begin{itemize}
\item We still use {\cmdn telnet} for some of our other classes.  What
  could be wrong with it?

\item The program {\cmdn hunt}, freely available from
  \url{http://lin.fsid.cvut.cz/~kra/}, lets you very easily:
  \begin{itemize}
  \item read passwords
  \item hijack telnet sessions
  \item monitor what the person is typing
  \end{itemize}

\item Pavel Krauz wrote the program just to show how insecure {\cmdn
    telnet} is---try it out!

\item Other tools can do this too (but just with less convenience)

\item Spread the news!  {\cmdn telnet} is dead!  Demand the Secure
  Shell\@!  Use the secure shell at your work; persuade people to stop
  using {\cmdn telnet}, except where passwords are not required, and
  the information is not useful (in which case, you should be doing
  something else!)
\end{itemize}


\section{Cryptography}
\label{sec:crytography}

\begin{itemize}
\item Two main categories of encryption:
  \begin{itemize}
  \item \emph{public key} or \emph{asymmetric} cryptography
    \begin{itemize}
    \item Different key used to encrypt and decrypt the data
    \item The public key used to encrypt
    \item private key used to decrypt
    \end{itemize}
  \item \emph{secret key} or \emph{symmetric} cryptography
    \begin{itemize}
    \item Same key used to encrypt and decrypt the data
    \item In Secure Shell, the \emph{session key} performs the
      encryption and decryption at each end.
    \end{itemize}
  \end{itemize}
\end{itemize}

\section{OpenSSH and its history}
\label{sec:openssh-history}

\enlargethispage{\baselineskip}
{\myss
\begin{itemize}
\item Originally, SSH was free, developed by Tatu Yl\"onen,
  
\item later, increasingly restrictive licensing.
  
\item Two versions of SSH: SSH1 and SSH2, available from \emph{SSH
    Communications Security}, and \emph{Datafellows}, at high prices
  (\$3120.00 US for a 25 user \emph{client only} license when I
  checked!)

% Fsecure most expensive: http://www.fsecure.com/download-purchase/:
% http://www1.buyonet.com/s/b?id=4.53.48&design=fsecure_eng_design&pa=pis&co_id=1053&pi=5656
% $714.00 for a single user Unix license!
% http://www1.buyonet.com/s/b?id=4.53.48&design=fsecure_eng_design&pa=pis&co_id=1053&pi=5693

% But SSH http://commerce.ssh.com/: charges $99, $495 and $475
  
\item International group of programmers chose to develop a completely
  free SSH from Tatu's original SSH
  \begin{itemize}
  \item Development moving very rapidly

  \item well implemented

  \item used by many system administrators round the world
  
  \item Completely free (both in the sense of ``freedom'' and in the
    sense of ``free beer''), open protocol
    
  \item now IETF is standardising SSH
  \end{itemize}
  
\item Provides a very nice blowfish logo, seen here burying the old
  insecure protocols: {\cmdn telnet}, {\cmdn rlogin},  {\cmdn rsh}.
\end{itemize}}
\begin{center}\label{fig:SSHerrif}
  \includegraphics[clip=true,width=0.7\columnwidth]{../images/shherrif}
\end{center}

% \begin{itemize}
% \item Originally developed as free software.
% \item Licences become more restrictive
% \end{itemize}

\section{Okay, I like the blowfish---what else does OpenSSH provide?}
\label{sec:openssh-files}

\begin{itemize}
\item OpenSSH 2.3 and onward is compatible with both SSH1 and SSH2,
  and interoperates with the commercial versions

\item OpenSSH provides powerful encryption to the entire session

\item OpenSSH 2.3 and above provides the following main programs:
  \begin{itemize}
  \item A server {\pgn sshd} which provides services for all the
    clients below, as well as {\pgn sftp}, an {\pgn ftp} replacement,
    that works with {\pgn CuteFTP} among many other clients

  \item The clients {\pgn ssh}, {\pgn scp}:
    \begin{itemize}
    \item {\pgn ssh} is for executing programs on other remote
    computers, and replaces {\pgn telnet}
    \item {\pgn scp} is a network copy program; works like {\pgn cp},
      but over the network.
    \end{itemize}

  \item The utilities:
    \begin{itemize}
    \item {\pgn ssh-keygen} for generating the private and public keys
      used by SSH
    \item {\pgn ssh-agent} to conveniently hold the personal private
      key to allow you to login without typing passwords

    \item {\pgn ssh-add} for adding the personal private key to {\pgn
        ssh-agent}
    \end{itemize}
  \end{itemize}
\end{itemize}


\section{So okay, how do I use this Secure Shell?}
\label{sec:how-use-ssh-to-login}

\begin{itemize}
\item To use it like {\cmdn telnet} is easy

\item Just type {\cmdn ssh \meta{computer name or IP}}
  
\item The first time you connect, you will receive a warning something
  like this:
{\myts
%% $ ssh nms.tyict.vtc.edu.hk
%% The authenticity of host 'nms.tyict.vtc.edu.hk (172.19.64.56)' can't
%%   be established.
%% RSA key fingerprint is
%%   df:a6:46:c5:a5:13:28:b6:5d:97:4b:cf:4f:db:9a:30.
%% Are you sure you want to continue connecting (yes/no)?
%$
\begin{verbatim}
The authenticity of host 'nms.tyict.vtc.edu.hk (172.19.64.56)' can't be established.
RSA key fingerprint is 48:2a:cb:1f:ac:7d:21:89:39:de:47:20:cf:06:d3:44
Are you sure you want to continue connecting (yes/no)?
\end{verbatim}}
For now, enter {\uin yes} (but see section~\vref{sec:host-keys}).  The
program will reply something like this:%
{\myts
\begin{verbatim}
Warning: Permanently added 'nms.tyict.vtc.edu.hk'(RSA) to the list of known hosts.
\end{verbatim}}

\item Enter your password when prompted
  
\item You now have a high security, military-strength encrypted link
  to the other computer.\footnote{Provided your connection was not
  hijacked!  See section~\vref{sec:host-keys}.}
\end{itemize}

% /var/log/messages:
% Feb  1 16:34:41 nicksbox sshd[5656]: Accepted publickey for nicku from 192.168.0.4 port 1033 ssh2
% Feb  1 16:34:41 nicksbox PAM_unix[5656]: (sshd) session opened for user nicku by (uid=0)


\section{Using {\cmdn scp} to copy files over the network}
\label{sec:how-use-scp}

\begin{itemize}
\item Use like the {\cmdn cp} command

\item Put the computer name and a colon in front of a remote file

\item Put a username then {\cmdn @} in front of this if you want to
  connect as a different user from yourself

\item Enough!  An example of copying a file {\fn file} from your home directory
  on machine {\usb neighbour} to the current directory:
\begin{alltt}
$ \textbf{scp \meta{neighbour's IP}:file \(\sim\)} 
\end{alltt}%$
\item Here is an another example: copying a file from my account
  \texttt{nickl} on the remote computer called \texttt{server} to
  my home directory on my local workstation:
\begin{alltt}\myss
$ \textbf{scp nick@server:/usr/share/emacs/site-lisp/site-start.el \(\sim\)}
\end{alltt}%$

  \item To copy a file called {\fn file} from your current directory
  to the existing directory {\fn /tmp/directory} on your neighbour's
  computer (that you have an account on), do:
\begin{alltt}
$ \textbf{scp file \meta{neighbour's IP}:/tmp/directory}
\end{alltt}%$
\end{itemize}

\section{Useful options with {\cmdn scp}}
\label{sec:scp-options}
\begin{itemize}
\item The most useful options to {\cmdn scp}:

  \begin{tabularx}{0.9\linewidth}[t]{@{}>{\ttfamily}cX@{}}
    \toprule%
    \textnormal{\emph{option}} & \emph{purpose}\\
    \midrule%
    -p & preserve the permissions (and owner if you are root)\\
    -r & recursively copy all the subdirectories and their contents\\
    -C & enable compression.  Good for modem speed links.\\
    -P 23 & use port 23 instead of port 22.  Good for transferring
            files to or from home through a firewall that has port
            23 open, but which blocks port 22. \\
    \bottomrule
  \end{tabularx}
\end{itemize}


% \section{Using {\cmdn sftp} to copy files over the network}
% \label{sec:how-use-sftp}

% \begin{itemize}
% \item 
% \end{itemize}


\section{SSH uses public and private keys}
\label{sec:public-private-keys}

\begin{itemize}
\item The Secure Shell uses a public key and a private key for each
  computer (public key cryptography)

\item Each user can also have their own private and public keys

\item Public key cryptography allows a public key (a very long number)
  to be freely distributed and made public
  
\item The private key \emph{must be kept secret}.  Your personal
  private key is usually stored encrypted on the hard disk, protected
  by a long pass phrase

\item The \emph{host} keys are used to:
  \begin{itemize}
  \item make sure the computer you are connecting to is really the one
    you want
    
  \item to establish secret \emph{session} keys used to encrypt all
    communication in the session, including any passwords
  \end{itemize}
  
\item The \emph{user} keys are used to:
  \begin{itemize}
  \item To establish the identity of the person who has initiated the
    session (authentication)
  \end{itemize}
\end{itemize}

\section{SSH Architecture}
\label{sec:ssh-architecture}

\noindent%
\makebox[\textwidth][c]%
{\includegraphics[width=1.1\textwidth]{../images/ssh-keys}}


\section{Overview of SSH}
\label{sec:overview-of-ssh}

\begin{itemize}
\item The \emph{client} computer is usually the system administrator's
  computer (or the person who wants to establish the connection)
\item The \emph{server} computer is often exactly that --- a server
  the system administrator needs to administer.
\item The host keys are used to:
  \begin{itemize}
  \item authenticate the server (make sure it really is the company
    server, and does not belong to the competitor who wants to steal
    your company's secrets)
  \item Establish the session key at each end of the connection.
  \end{itemize}
\item Note: the actual encryption of the session is done using the
  session keys, with symmetric encryption, since it is \emph{much}
  faster than public key encryption.
\item The \emph{user} keys are optional; they allow strong
  authentication without passwords.
\item The user private key is encrypted with a strong passphrase.
\item The \emph{agent} is a program used to hold the decrypted private
  key on the client, to make the private key available to SSH
  applications.
\end{itemize}

\section{Steps of establishing a connection}
\label{sec:steps-ssh}

The following steps are not complete; SSH2 is actually three separate
protocols, which can be used in various ways.  Here I give an
approximate view of SSH establishing a connection.
\begin{itemize}
\item The client makes a TCP connection to the port the server is
  listening on (normally 22)
\item The client and server announce the protocols they support, and
  decide on what they will use
\item If the client does not have the server's public host key, then
  the client will be prompted as to whether they want to accept the
  host key.  This is the warning given in
  section~\vref{sec:how-use-ssh-to-login}.  If you type
  ``\texttt{yes}'', then the host key will be transferred in clear
  text over the network, and appended to your $\sim${\fn
  /.ssh/known\_hosts} file.  At this point, your session is
  vulnerable to hijacking.  To avoid this risk, transfer the public
  host key yourself (manually) and append it to
  {\fn/etc/ssk/ssh\_known\_hosts} on the client as described in
  section~\vref{sec:host-keys}.
\item Now the server and client generate and share a session key using
  an algorithm called the \emph{Diffie-Hellman Key Exchange}\@.  They
  use the host key pair to do this.
\item The session is now encrypted, and authentication of the user now
  takes place, using either the user key pair, or a password.
\end{itemize}

\section{Using {\cmdn ssh-keygen} to create a personal pair of private
  and public keys}
\label{sec:ssh-keygen}

\begin{itemize}
\item When you first booted Red Hat Linux, the startup script for
  \texttt{sshd} generated the public and private \emph{host keys}
  automatically.

\item You can create your own pair of user keys: just type
\begin{alltt}
$ \textbf{ssh-keygen -t rsa}
\end{alltt}%$
  
  \begin{itemize}
  \item accept the default file name
  \item when asked for a pass phrase, type a long sentence that you
    can easily remember, but which will be impossible for other people
    to guess.
  \end{itemize}
  
{\myfs
\begin{verbatim}
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nicku/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/nicku/.ssh/id_rsa.
Your public key has been saved in /home/nicku/.ssh/id_rsa.pub.
The key fingerprint is:
13:6f:6b:1f:ac:6a:21:89:f0:de:47:20:d4:06:5c:2b
\end{verbatim}}%$

\item This will generate the files $\sim${\fn /.ssh/id\_rsa.pub} and
  $\sim${\fn /.ssh/id\_rsa}
  
\item The private key $\sim${\fn /.ssh/id\_rsa} \emph{must} have access
  permissions \emph{only} for you, the owner, i.e., ``{\str
    -rw-------}'' or ``{\str -r--------}''
\end{itemize}


\section{The host keys in {\fn /etc/ssh/ssh\_known\_hosts} and
  {\fn $\sim$/.ssh/known\_hosts}}
\label{sec:host-keys}

\begin{itemize}
\item An important step in using SSH is having the public host key of
  the computers you want to connect to.  Unfortunately, the only
  really secure way is to copy it on a floppy disk from the remote
  machine, and take it to your own computer.

\item Copy the file {\fn /etc/ssh/ssh\_host\_rsa\_key.pub} from the
  remote machine to a floppy.
  
\item On the local machine, append the file \emph{as one line} to the
  file {\fn /etc/ssh/ssh\_known\_hosts}
  
\item An alternative is just to enter {\uin yes} when asked, as in
  section~\vref{sec:how-use-ssh-to-login}
  \begin{itemize}
  \item The public host key will be copied over the network from {\fn
      /etc/ssh/ssh\_host\_rsa\_key.pub} on the server and appended to
    $\sim${\fn /.ssh/known\_hosts} on the client.
    
  \item But: this is a serious security hazard, and cracking tools
    exist ({\fn sshmitm}) to easily hijack SSH sessions before the
    host key is transferred,
  \end{itemize}
  
\item There are tools to automate this insecure procedure (of building
  the {\fn /etc/ssh/ssh\_known\_hosts} file).
\end{itemize}


\section{The file {\fn $\sim$/.ssh/authorized\_keys}}
\label{sec:authorized_keys}

\begin{itemize}
\item This file contains the personal public keys of user accounts
  that you trust (your own) to connect to your computer without a
  password.
  
\item To set it up on a remote computer:
  \begin{itemize}
  \item Copy your local personal public key to the remote computer (do
    not copy to $\sim${\fn /.ssh}, or you will overwrite your own
    local key!)  Here put the host name of the remote computer instead
    of ``\meta{remote IP}''.  Note: ``\texttt{local \$}'' and
    ``\texttt{remote \$}'' are shell prompts; don't type them!
\begin{alltt}
local $ \textbf{scp -p \(\sim\)/.ssh/id_rsa.pub \meta{remote IP}:}
\end{alltt}%$

  \item Log into the remote machine using {\pgn ssh}:
\begin{alltt}
local $ \textbf{ssh \meta{remote IP}}
\end{alltt}%$

  \item Make the directory $\sim${\fn /.ssh} if it does not exist, and
    change to mode 700:
\begin{alltt}\myss
remote $ \textbf{mkdir \(\sim\)/.ssh}
remote $ \textbf{chmod 700 \(\sim\)/.ssh}
\end{alltt}

%%     {\cmdn \$ mkdir $\sim${\fn /.ssh}\\
%%       \$ chmod 700 $\sim${\fn /.ssh}}
    
  \item Append $\sim$/id\_rsa.pub to $\sim${\fn
      /.ssh/authorized\_keys} on the remote machine, in the {\pgn
      ssh} session:
\begin{alltt}\myss
remote $ \textbf{cat \(\sim\)/id_rsa.pub >> \(\sim\)/.ssh/authorized_keys}
remote $ \textbf{rm \(\sim\)/id_rsa.pub}
remote $ \textbf{chmod 600 \(\sim\)/.ssh/authorized_keys}
remote $ \textbf{exit}
\end{alltt}
  \end{itemize}
\enlargethispage*{0.8\baselineskip}  
\item You now have installed your personal public key from your local
  computer account to the remote computer, allowing you to log in to
  the remote computer using public key cryptography instead of
  passwords.
\end{itemize}


\section{The User's Public and Private Keys}
\label{sec:users-public-and-private-keys}

\begin{itemize}
\item There are two computers here: the local \emph{client} machine,
  and the remote \emph{server} machine.

\item When configuring SSH, most of the work is done on your local
  \emph{client} computer.
  
\item You generate a public and private key pair using {\cmdn
    ssh-keygen~-t~rsa} on your \emph{client} computer---see
  section~\vref{sec:ssh-keygen}.  You do \emph{not} need to generate
  public and private user keys in your account on the remote server.

\item Your private key is on the client.  Your public key must be on
  the server, in the file {\fn $\sim$/.ssh/authorized\_keys}.  The
  client does \emph{not} need a file {\fn
    $\sim$/.ssh/authorized\_keys}.
  
\item You install the secure shell agent on your client machine---see
  section~\vref{sec:ssh-agent}.  You do \emph{not} need to install it
  on the server.

\item You add your private key $\sim${\fn/.ssh/id\_rsa} on the
  \emph{client} computer to the agent, which is \emph{also} on the
  client computer, using the {\cmdn ssh-add} command.
\end{itemize}

\section{SSH1 and SSH2}
\label{sec:ssh1-cf-ssh2}

\begin{itemize}
\item SSH1 and SSH2 use totally different, incompatible protocols.

\item The commercial programs have separate programs for each protocol
  (pay for each separately)

\item OpenSSH supports both SSH1 and SSH2.

\item SSH2 is more secure than SSH1\e.  It is best to avoid SSH1
  clients and servers wherever possible.

\item SSH1 uses only RSA authentication, while SSH2 uses both RSA and DSA

\item See \url{http://www.snailbook.com/faq/ssh-1-vs-2.auto.html}
\end{itemize}

\section{The public and private key pairs: a summary}
\label{sec:keys-summary}


\begin{itemize}
\item SSH1 and SSH2 use different files to hold the public and private
  keys.  I've made a table to summarise their purposes:
\end{itemize}

% \newcolumntype{Y}{>{\raggedright\arraybackslash}X}
% set in masterfile.tex.

{\myts\setlength{\extrarowheight}{4pt}
  \begin{tabularx}{\linewidth}[t]{@{}>{\ttfamily}l>{\ttfamily}lY@{}}
    \toprule%
    \textnormal{SSH1 file} & \textnormal{SSH2 file} & Purpose\\
    \midrule%
    $\sim$/.ssh/known\_hosts & $\sim$/.ssh/known\_hosts & other host
    public keys added automatically when you type {\uin yes} as in
    section~\ref{sec:how-use-ssh-to-login}\\
    /etc/ssh/ssh\_known\_hosts & /etc/ssh/ssh\_known\_hosts & other
    host public keys added manually, as in section~\ref{sec:host-keys}\\
    /etc/ssh/ssh\_host\_key & /etc/ssh/ssh\_host\_rsa\_key & host
    private key ({\cmdn chmod 400}) \\
    /etc/ssh/ssh\_host\_key.pub & /etc/ssh/ssh\_host\_rsa\_key.pub &
    host public key \\
    $\sim$/.ssh/identity & $\sim$/.ssh/id\_rsa & User's personal
    private key\\
    $\sim$/.ssh/identity.pub & $\sim$/.ssh/id\_rsa.pub & User's
    personal public key (just used for copying into the {\fn
      authorized\_keys*}
    files of other servers)\\
    $\sim$/.ssh/authorized\_keys & $\sim$/.ssh/authorized\_keys &
    Holds personal public keys of clients authorised to log into this
    account on this SSH server\\
    \bottomrule
  \end{tabularx}}


\section{Files and Permissions I Recommend}
\label{sec:ssh-permissions}

\begin{itemize}
\item If permissions are wrong, SSH will just not work.  The manual
  pages recommend permissions, but here I have made a list from my own
  experience:

  {\myss
  \begin{tabular}[t]{@{}>{\ttfamily}l>{\ttfamily}c>{\ttfamily}c@{}}
    \toprule%
    \textnormal{\emph{File}} & \textnormal{\emph{Min Permission}}
      & \textnormal{\emph{Max Permission}} \\
    \midrule%
    $\sim$/.ssh                   & drwx------ & drwxr-xr-x \\
    $\sim$/.ssh/known\_hosts      & -rw------- & -rw-r--r-- \\
    %$\sim$/.ssh/known\_hosts      & -rw------- & -rw-r--r-- \\
    $\sim$/.ssh/identity          & -r-------- & -rw------- \\
    $\sim$/.ssh/id\_rsa           & -r-------- & -rw------- \\
    $\sim$/.ssh/identity.pub      & -r-------- & -rw-rw-r-- \\
    $\sim$/.ssh/id\_rsa.pub       & -r-------- & -rw-rw-r-- \\
    $\sim$/.ssh/authorized\_keys  & -rw------- & -rw-r--r-- \\
    %$\sim$/.ssh/authorized\_keys2 & -rw------- & -rw-r--r-- \\ 
    \bottomrule
  \end{tabular}}

\vspace{1ex}

\item I use and recommend the minimum permissions.  Note that SSH will
  \emph{refuse} to work if:
  \begin{itemize}
  \item the private keys are readable, writeable or executable by group/others

  \item the {\fn authorized\_keys*} are writable by group/others
    
  \item the {\fn$\sim$/.ssh} directory is \emph{not} readable or
    executable by group/others
    
  \item the {\fn$\sim$/.ssh} directory \emph{is} writable by
    group/others
  \end{itemize}
%% \item Use permission {\str-rw-r--r--} for {\fn authorized\_keys*} if
%%   user's home directory is shared over the network by NFS (see
%%   section~\vref{sec:nfs}).
\end{itemize}


\section{Using {\cmdn ssh-agent} to log in without typing passwords}
\label{sec:ssh-agent}

\begin{itemize}
\item Now you can use public key cryptography to login to the remote
  machine.  But you need to type that long pass phrase each time!
  Oh, that's not convenient.
  
\item So let's use the utilities {\pgn ssh-agent} and {\pgn ssh-add}
  to store the private key on your \emph{client} computer.

\item Your private key is stored encrypted on the hard disk of your
  client computer in your account, protected by your pass phrase.

\item The agent provides a container to hold your decrypted private
  key in the memory of your client machine.

\item You use the program {\cmdn ssh-add} to add the private key to
  the agent once after you boot your client machine.
\end{itemize}


\section{Setting up {\cmdn ssh-agent}: logging in without typing passwords}
\label{sec:ssh-agent-config}


\begin{itemize}
\item We do this on the \emph{client} machine only.  Here's what we
  do, once only:
  \begin{itemize}
  \item edit your login script $\sim${\fn /.bash\_profile} in your
    account on the client machine, and add the line:

    {\cmdn eval \$(ssh-agent)}

    \emph{Note} this is command substitution.
    
%%   \item Edit the logout script $\sim${\fn /.bash\_logout} in your
%%     account on the client machine and add the two lines:

%%     {\cmdn ssh-add -D\\
%%       sudo -k}

  \item Log out of {\pgn X} and log back in again.
  \end{itemize}
\end{itemize}


\section{Using {\cmdn ssh-add}: logging in without typing
  passwords}
\label{sec:ssh-add}

\begin{itemize}
\item We do the following every time you boot your \emph{client}
  computer:
  \begin{itemize}
  \item Open a window, and type:
\begin{alltt}
$ \textbf{ssh-add}
\end{alltt}%$
    then type your pass phrase when prompted.
  \end{itemize}
  
\item Your client user's secret key is now held decrypted by the agent
  in the memory of the client machine, letting you conveniently log
  in to your account on a  remote server.  If you do this:
\begin{alltt}
local $ \textbf{ssh \meta{remote IP}}
\end{alltt}%$
  you will connect to your account on the remote computer without
  having to type a password.  And that's not all!
  
  Note: ``\texttt{local \$}'' is the shell prompt; you do not type
  that.
\end{itemize}


\section{An easier way: using \texttt{keychain}}
\label{sec:keychain}

\begin{itemize}
\item {\pgn keychain} is a very useful shell script that automates the
  management of personal private keys and the agent.

\item It is also very useful in automating the use of secure shell
  using {\pgn cron}; see section~\S\vref{sec:tools_basic-crontab}.
\item Get it from \url{http://www.gentoo.org/projects/keychain}.
\item Installation is simple:
  \begin{enumerate}
  \item get the tarball (click on the link to
  \url{http://gentoo.oregonstate.edu/distfiles/keychain-2.2.0.tar.bz2},
  save it to your home directory).
  \item Unpack it into any directory
\begin{alltt}
$ \textbf{tar xvjf \(\sim\)/keychain-2.2.0.tar.bz2}
\end{alltt}%$
  \item change into the directory {\fn keychain-$x.x$}
  \item install it into the directory {\fn /usr/bin} with:
\begin{alltt}
$ \textbf{sudo install -m 755 keychain /usr/bin}
\end{alltt}%$
  \end{enumerate}
\end{itemize}

\section{What \texttt{keychain} Does}
\label{sec:keychain-flowchart}

\begin{itemize}
\item The agent holds your user private key, decrypted
\item \SSH clients talk to the agent through a \emph{socket}
  \begin{itemize}
  \item A \emph{socket} is a method of inter-process communication
    (\acro{IPC})
  \item It is a special file that allows two processes to talk to each
    other in both directions at the same time
  \end{itemize}
\item When the agent starts, it creates a socket, and writes commands
  to standard output that create environment variables that let \SSH
  clients know how to find the agent; for example:
\begin{alltt}\myfs
$ \textbf{ssh-agent}
SSH_AUTH_SOCK=/tmp/ssh-sif17405/agent.17405; export SSH_AUTH_SOCK;
SSH_AGENT_PID=17406; export SSH_AGENT_PID;
\end{alltt}%$

\item You can see this socket:
\begin{alltt}\myfs
$ \textbf{ls -l /tmp/ssh-sif17405/agent.17405}
srwxrwxr-x  1 nicku nicku 0 May  2 11:19 /tmp/ssh-sif17405/agent.17405
\end{alltt}%$
  
\item The \texttt{keychain} shell script makes sure that a file
  \(\sim\!\!\)\nolinebreak[4]\path{/.keychain/${HOSTNAME}-sh} %$
  contains these two values, and that they are correct.  The algorithm
  is:
\begin{alltt}\myfs
if \(\sim\)/.keychain/${HOSTNAME}-sh holds info about a running agent
        if that agent does not hold all required keys
                add those keys
        else
                exit
else
        terminate all running agents
        start new agent
        store socket, \PID info in \(\sim\)/.keychain/${HOSTNAME}-sh
        add all required private user keys
\end{alltt}%
\end{itemize}

\section{Setting your hostname}
\label{sec:setting-your-hostname}

\begin{itemize}
\item \texttt{keychain} will save the information about your \SSH
  agent in the file \texttt{$\sim$/.keychain/\$\{HOSTNAME\}-sh}.
  \begin{itemize}
  \item Previously, I set up a name server so that each of our
    computers would have its own name, but technical staff have
    disabled it.
  \item The problem is that because all our machines are called
    \texttt{localhost.localdomain}, \texttt{keychain} will save your
    \texttt{ssh-agent} information in the same file name, overwriting
    the information about the agent in your own desktop.
  \item To avoid this problem, we can give our own computer a
  hostname.  Here I explain how you can do that.
  \end{itemize}
\end{itemize}
\begin{enumerate}
\item Edit the file \path{/etc/sysconfig/network}:
\begin{alltt}
$ \textbf{xhost +localhost}
$ \textbf{sudo -v}
$ \textbf{sudo emacs /etc/sysconfig/network &}
\end{alltt}%$
 and edit the line
\begin{verbatim}
HOSTNAME=localhost.localdomain
\end{verbatim}
and change it into
\begin{alltt}
HOSTNAME=\meta{your name}.tyict.vtc.edu.hk
\end{alltt}
where \meta{your name} is your own name; please try to make this
unique, so that it is not the same as anyone elses.
\begin{itemize}
\item Do \emph{not} add spaces, or any characters except letters and
  digits and hyphen.  Note the first character of a host name should
  be a letter.  I suggest just use lower case letters.
\end{itemize}
\item Edit the host file, \texttt{/etc/hosts}:
\begin{alltt}
$ \textbf{sudo -v}
$ \textbf{sudo emacs /etc/hosts &}
\end{alltt}%$
  This file is used by
  the operating system to map host names to \IP addresses and back,
  before the operating sytem checks the name server.
  \begin{explanation}
    Note that on Windows, the file is in
\begin{verbatim}
%SystemRoot%/System32/drivers/etc/hosts
\end{verbatim}
  \end{explanation}
Edit the line
\begin{verbatim}
127.0.0.1 localhost.localdomain localhost
\end{verbatim}
and change it to:
\begin{alltt}\myfs
127.0.0.1 \meta{your name}.tyict.vtc.edu.hk \meta{your name} localhost.localdomain localhost
\end{alltt}

\item Then restart networking with:
\begin{alltt}
$ \textbf{sudo service network restart}
\end{alltt}%$

\item Log out and log in again.
\end{enumerate}
Your hostname is now changed to \texttt{\meta{your
    name}.tyict.vtc.edu.hk}.

\section{Configuring your own account to use \texttt{keychain} }
\label{sec:keychain-account}

\begin{itemize}
\item Next add these lines to the end of your login script \texttt{$\sim$/.bash\_profile}:
  {\myfs
\begin{verbatim}
[ -x /usr/bin/keychain ] && keychain ~/.ssh/id_rsa
[ -r ~/.keychain/${HOSTNAME}-sh ] && source ~/.keychain/${HOSTNAME}-sh
\end{verbatim}
}
\item Remove the line:
\begin{verbatim}
eval $(ssh-agent)
\end{verbatim}%$
from your log in script \texttt{$\sim$/.bash\_profile}.
\item Add this to the end of \texttt{$\sim$/.bashrc}:
  {\myfs
\begin{verbatim}
[ -r ~/.keychain/${HOSTNAME}-sh ] && source ~/.keychain/${HOSTNAME}-sh
\end{verbatim}
  }
\begin{explanation}
Note that when you log in, \texttt{bash} will \emph{source} your log
in script, \texttt{$\sim$/.bash\_profile}.  Every time you start a new
\texttt{bash} process, then \texttt{bash} will source
\texttt{$\sim$/.bashrc}.
\end{explanation}
\item Log out and log back into the computer.  You will be prompted to
  enter your passphrase.  You will never need to enter it again until
  you reboot the computer.

\end{itemize}

\subsection{Automating network transfers using \texttt{keychain} and SSH}
\label{sec:cron-keychain}

\begin{itemize}
\item You can run shell scripts from your {\pgn cron} table. See
  section~\S\vref{sec:tools_basic-crontab}.  Add the line:
  {\myfs
\begin{verbatim}
[ -r ~/.keychain/${HOSTNAME}-sh ] && source ~/.keychain/${HOSTNAME}-sh
\end{verbatim}
  }
near the beginning of your script.  It will be able to use the secure
shell commands to connect to other computers.
\end{itemize}

\section{Running X applications remotely}
\label{sec:remote-X-with-ssh}

\begin{itemize}
\item You can run {\kwd X} applications remotely.
  
\item Simply log into the remote machine using {\pgn ssh},
  
\item type the name of the graphical program, and it just works, as if
  it were running locally!

\item The program executes on the remote computer, but the {\kwd X}
  protocol sends the graphics commands through the encrypted session,
  
\item the application is displayed on your local machine, though the
  processing is done remotely.
  
\item Great for running remote graphical system administration
  applications (remote administration)
\end{itemize}


\section{Configuring SSH for {\cmdn X}}
\label{sec:configuring-ssh}

Note that the settings of the RPMs from Red Hat are already configured
to support X forwarding.
\begin{itemize}
\item The configuration file for the client is {\fn /etc/ssh/ssh\_config}

\item The configuration file for the server is {\fn
    /etc/ssh/sshd\_config}

\item Letting {\pgn X} work over SSH:
  \begin{itemize}
  \item An important configuration option in {\fn /etc/ssh/ssh\_config} is:

    {\cmdn ForwardX11 yes}

  \item An important configuration option in {\fn /etc/ssh/sshd\_config} is:

    {\cmdn X11Forwarding yes}

  \item These enable {\pgn X} to work over SSH as described in
    section~\ref{sec:remote-X-with-ssh}
  \end{itemize}
\end{itemize}


\section{Security options for the client in {\fn /etc/ssh/ssh\_config}}
\label{sec:security-options}

\begin{itemize}
\item {\cmdn RhostsAuthentication no}
  
  disable fallback to insecure remote hosts file ``authentication.''
  The default is ``yes''.  This option applies to protocol version 1
  only.
  
\item {\cmdn RhostsRSAAuthentication no}
  
  disable fallback to insecure remote hosts file and host key
  authentication.  The default is ``yes''.  This option applies to
  protocol version 1 only.
  
\item {\cmdn FallBackToRsh no}
  
  Totally avoid {\cmdn rsh} (buried on page \pageref{fig:SSHerrif}!)
  The default is ``no''.
   
  
\item {\cmdn PubkeyAuthentication yes}

  Usually turned on by default, but if you have trouble with logging
  in without passwords, add to {\fn /etc/ssh/ssh\_config}.

\item {\cmdn UsePrivilegedPort no}

  This makes SSH work better with some firewalls.  The default is
  ``no'' Also remove the SUID bit from {\fn /usr/bin/ssh}:

  {\cmdn \$ \textbf{sudo chmod u-s /usr/bin/ssh}}
\end{itemize}


\section{{\pgn rsync}: using it with SSH to mirror data}
\label{sec:rsync-1}

More often than {\pgn scp} I use {\pgn rsync} to transfer data.
\begin{itemize}
\item Advantages:
  \begin{itemize}
  \item {\pgn rsync} can preserve the time stamps, ownership, and can
    transfer device files and symbolic links accurately
  \item {\pgn rsync} only transfers the differences between files, not
    the whole file.
    \begin{itemize}
    \item For example, if a single 50\,megabyte email file has one
      email added at the end, and one deleted from the middle of the
      file, only a very small fraction of the total file will be
      transferred.
    \end{itemize}
  \item The tool of choice for mirroring web sites, ftp sites, and for
    downloading ISO images.
  \end{itemize}
  
\item To use it with Secure Shell, either:
  \begin{itemize}
  \item use the option \texttt{-e ssh} with {\cmdn rsync}, or
  \item Add the following line to your login script:
\begin{verbatim}
export RSYNC_RSH=ssh
\end{verbatim}
  \end{itemize}
\item Most useful options (besides \texttt{-e ssh}):
  \begin{description}
  \item[\texttt{-a}] Preserve \textbf{a}ll properties (permissions,
    ownership, use recursion to copy subdirectories, keep synmbolic
    links,\ldots
  \item[\texttt{-v}] \textbf{v}erbose; show the files as they are
    transferred;
  \item[\texttt{-z}] use compression.
  \end{description}
\end{itemize}


\section{Examples of using \texttt{rsync}}
\label{sec:rsync-examples} 

\begin{itemize}
\item Make a copy of \texttt{$\sim$/tmp} on \texttt{ictlab} in the current
  directory.
\begin{alltt}
$ \textbf{rsync -avz -e ssh ictlab:tmp .}
\end{alltt}%$
  \begin{itemize}
  \item If \texttt{tmp} is a directory containing files,
    \begin{itemize}
    \item all of the files will be copied, and
    \item their ownership and permissions will be preserved
      as far as possible
    \item If you are \texttt{root}, they will be preserved exactly
    \item \emph{Without} a trailing `\texttt{/}', the directory
      \texttt{tmp} will be created on the local computer in the
      current directory.
    \end{itemize}
  \end{itemize}

\item Make a copy of \texttt{$\sim$/tmp} on \texttt{ictlab} in the
    current directory.
\begin{alltt}
$ \textbf{rsync -avz -e ssh ictlab:tmp/ .}
\end{alltt}%$
  \begin{itemize}
  \item If \texttt{tmp} is a directory containing files, same as
    previous example except that:
    \begin{itemize}
    \item \emph{With} a trailing `\texttt{/}', the directory
      \texttt{tmp} will \emph{not} be created on the local computer in
      the current directory; the files and subdirectories of
      \texttt{$\sim$/tmp} on \texttt{ictlab} will be copied to the
      current directory.
    \end{itemize}
  \end{itemize}
\end{itemize}


\section{Using \texttt{ssh} from Windows, with Cygwin}
\begin{itemize}
\item Install Cygwin by:
  \begin{itemize}
  \item Go to \url{http://cygwin.com/}, click on the ``Install Cygwin
    now'' icon
  \item Install at least \texttt{XFree86}, \texttt{openssh} and
    \texttt{cygrunsrv}, but I prefer to install the lot (it makes
    Windows much less painful to me).
    \begin{explanation}
      Note that Henry has already installed cygwin on all the
      computers in our A204 laboratories.
    \end{explanation}
  \end{itemize}
\item From the Cygwin icon on your desktop, or the Cygwin menu item
  at \textsf{Start} $\to$ \textsf{Programs} $\to$ \textsf{Cygwin},
  start a \texttt{bash} shell.
\item At the \texttt{bash} prompt, type:
\begin{alltt}
$ \textbf{startx &}
\end{alltt}%$
  \begin{explanation}
    On older Cygwin installations in our laboratories, this starts a
    \texttt{twm} window manager session.  You can type
\begin{alltt}
$ \texttt{man twm}
\end{alltt}%$
    on the Windows machine (if you installed \texttt{man}), or on any
    Linux machine for the manual that explains how it works.
  \end{explanation}
\item In a terminal window in the resulting X session, type:
\begin{alltt}
$ \textbf{ssh -X \meta{your user name}@\meta{IP address}}
\end{alltt}%$
\item When you connect to the remote machine, you can run any
  graphical application on that machine, and display it locally, so
  you could run emacs remotely on this Windows machine in a graphical mode:
\begin{alltt}
$ \textbf{emacs assignment &}
\end{alltt}%$
\end{itemize}


%% \section{Using {\cmdn PuTTY} from Windows, with {\cmdn Cygwin}: setting up}
%% \label{sec:putty-setup}

%% \begin{itemize}
%% \item Install Putty (freely available telnet client for
%%   Windows) by copying it to your desktop.
  
%% \item start putty, and enable X forwarding in the options, and save
%%   them.
%% \item Restart putty.
  
%%   %% from the \textsf{Setup} menu, select \textsf{SSH Forwarding}, and
%%   %% check \textsf{Display remote X applications on local X server}

%% %% \item Start \texttt{XWin32}.

%% %% \item I configured {\pgn XWin32} to connect to \textsf{localhost},
%% %%   use \textsf{XDMCP}, \texttt{query}, and set the window type to
%% %%   \texttt{multiple}.
%% \end{itemize}

%% \section{Using {\pgn ssh} from Windows, with {\pgn XWin32}}
%% \label{sec:putty-using-it}

%% \begin{itemize}
%% \item Once it is set up, using it is simple:

%% \item start up {\pgn putty} to connect to a remote computer that has:
%%   \begin{itemize}
%%   \item X applications
%%   \item A secure shell server
%%   \end{itemize}
%%   such as one running Linux

%% \item Type any graphical command; you will see the result appear in a
%%   window on your windows screen.
%% \end{itemize}

\section{What else can SSH do?}
\label{sec:what-else-with-ssh}

\begin{itemize}
\item Can execute programs remotely (i.e., for doing a backup of a
  remote computer)
  
\item Can do ``port forwarding'', allowing amazing flexibility in
  sending any protocol over the encrypted tunnel, so that the
  application appears to be executing locally.  Useful for {\pgn VNC}
  (\url{http://www.uk.research.att.com/vnc/sshvnc.html}), many other
  applications.

\item Can provide a basic type of encrypted tunnel, a simple VPN
  (virtual private network)
  
\item Many other things.  There is a great book published in 2001
  about it: Daniel Barrett and Richard Silverman, \emph{SSH, The
    Secure Shell: The Definitive Guide} see details at
  \url{http://www.oreilly.com/catalog/sshtdg/} (the Snail Book)
\end{itemize}

\section{Summary}
\label{sec:summary}

\begin{itemize}
\item SSH allows remote login using strong encryption
\item The host public key must be transferred using some other secure
  means: if you transfer it automatically, it is subject to a \emph{trivial
  man-in-the-middle attack}.
\item The \emph{host key pair} performs two importand functions:
  \begin{itemize}
  \item authenticate the server (only possible if you transfer the
  public host key from the server to the client in some secure way,
  such as by floppy disk)
  \item begin encryption
  \end{itemize}
\item The \emph{user key pair} has only one role: to provide strong
  authentication of the user.
\item The \emph{agent} is used to hold the decrypted private user key
  on the client computer.  Without the agent, you would need to type
  your pass phrase with every \SSH connection.
\item The public user key is appended to the file
  \texttt{$\sim$/.ssh/authorized\_keys} in your user account on the
  servers you will connect to.  You can do this over the network once
  the public host key is securely copied.
\item The actual encryption is done using the \emph{session key}.  The
  session key is never stored on the hard disk, and a new pair is
  generated regularly during a session.
\item The session is encypted using \emph{symmetric encryption},
  because it is \emph{much} faster than public key (asymmetric)
  encryption.
\end{itemize}


\section{SSH References}
\label{sec:ssh-references}

\begin{itemize}
\item A useful guide to OpenSSH:
  \url{http://perso.club-internet.fr/ffaure/openssh.html}

\item A concise guide to OpenSSH:
  \url{http://www.samag.com/archive/0910/feature.shtml}, the
  \emph{SysAdmin Magazine}

\item The OpenSSH press page lists many useful resources:
  \url{http://www.openssh.com/press.html}
  
\item The Red Hat Reference Guide has a chapter on SSH:
  \url{http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/ch-ssh.html},
  or locally,
  \url{http://ictlab.tyict.vtc.edu.hk/doc/rhl-rg-en-9/ch-ssh.html}

\item The Snail Book FAQ: \url{http://www.snailbook.com/faq/} (and, of
  course, the Snail Book itself in the library)

\item SSH FAQ: \url{http://www.onsight.com/faq/ssh/ssh-faq.html}

\item OpenSSH FAQ: \url{http://www.openssh.com/faq.html}

\item USENET SSH FAQ:
  \url{http://www.faqs.org/faqs/computer-security/ssh-faq/}

\item ssh mailing list:
  \url{http://www.onsight.com/faq/ssh/ssh-faq-8.html#ss8.3}

\item OpenSSH developer's mailing list:
  \url{http://www.openssh.com/list.html}

\item Don't forget the OpenSSH {\pgn man} pages!
\end{itemize}

}% end of \mns started at beginning of this file.

\section{Secure Shell Exercises}
\label{sec:ssh-exercises}

% Our setup is a laboratory of 45 computers behind a Linux firewall
% using IP masquerade to map all addresses to one address
% (192.168.128.51), since our Computer Centre staff are unable to
% allocate us enough private addresses because the only competent
% staff member left to get a better job "in the real world", leaving
% the only other person in the Computer Centre who had even the slightest
% clue about 3Com routers and switches (having the lowly position of
% "Computer Operator") unable to cope, the remainder burdened by
% lack of competence with routers  (Oh, you people should blush
% with shame!  I believe that they feel it, but do not act to remedy
% their ignorance.)  The firewall also runs the ISC DHCP server 3.0b2pl11,
% allocating the addresses 10.1.1.1 to 10.1.1.100 dynamically. It also
% dynamically updates our name server.  Students have given their
% machines a name, and maybe our BIND 8.2.2_P7 will not like all of
% the names, while some names are duplicated.
{\normalsize
\begin{enumerate}
\item Set up {\pgn sudo} with a line like this:

{\cmdn {\usb your-user-name}\ \ \ \ ALL=(ALL) ALL}

as described in the handout about {\pgn sudo}.

% solution to question~\vref{qes:sudo-all-all}.

%% \item \label{qes:ok-names}The name of your computer must be unique,
%%   and contain no other characters besides a\ldots z, 0\ldots9, A\ldots
%%   Z and the hyphen `\texttt{-}'.  If you suspect that it does not
%%   match these criteria, type {\cmdn \$~sudo~netcfg} and modify your
%%   hostname.  Make sure that your hostname ends with our domain:
%%   \texttt{tycm.vtc.edu.hk}
  
%% \item If you have already changed your hostname in
%%   step~\ref{qes:ok-names}, do the following:
%%   \begin{itemize}
%%   \item If when you type {\cmdn \$ hostname} you get a different name
%%     from the name you entered in {\pgn netcfg}, then type:\\
%%     {\cmdn \$ sudo hostname {\usb newhostname}.tycm.vtc.edu.hk\\
%%       \$ sudo ifdown eth0\\
%%       \$ sudo ifup eth0}\\
%%     This will ensure that the DHCP server sends your new host name to
%%     the name server using a dynamic update.
%%   \item You may then need to log out, and log back in again, since
%%     {\pgn X} authentication depends on the name of the computer not
%%     changing.

%%   \end{itemize}
  
%% \item Check that the name of your computer in the name
%%   server matches your IP address.  Do the following:
%%   \begin{itemize}
%%   \item type: {\cmdn \$ hostname} to find the name of your computer.
%%   \item type: {\cmdn \$ ifconfig} and read the IP address of your
%%     Ethernet card, \texttt{eth0}.
%%   \item type: {\cmdn \$ nslookup \usb your-hostname} where {\usb
%%       your-hostname} is the name you found in front of our domain
%%     \texttt{tycm.vtc.edu.hk}\footnote{The program {\cmdn nslookup} is
%%       a powerful tool for debugging name server problems.  The same
%%       program was compiled by Microsoft on Windows 2000, and you can
%%       use it there too.}
%%   \item If {\pgn nslookup} says ``Non-existent host/domain'', then
%%     check the conditions at step~\ref{qes:ok-names}.  Ask Nick if you
%%     see no other problem.
%%   \end{itemize}
  
%% \item Turn to your neighbour and ask them to make an account for you
%%   with the same name as your own account on your own computer.  Make
%%   sure that you type your password for your account yourself.
%

\item Check that the directories \texttt{/sbin} and \texttt{/usr/sbin}
  are on your \texttt{PATH}:
\begin{alltt}
$ \textbf{echo $PATH}    
\end{alltt}
  These directories contain system administrator's commands. If you do
  not see them there,
  \begin{itemize}
  \item add this command to your login script.  Be careful: do not
    overwrite your login script!
\begin{alltt}
$ \textbf{echo 'PATH=$PATH:/sbin:/usr/sbin' >> \(\sim\)/.bash_profile}    
\end{alltt}

\item \emph{source} this file into your shell process:
\begin{alltt}
$ \textbf{source \(\sim\)/.bash_profile}
\end{alltt}%$
\item Now check your \texttt{PATH} contains those two directories:
\begin{alltt}
$ \textbf{echo $PATH}    
\end{alltt}
\end{itemize}
\item Identify your \IP address, and tell your neighbour:
\begin{alltt}
$ \textbf{ip addr}    
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:01:03:45:99:12 brd ff:ff:ff:ff:ff:ff
    inet 172.19.32.30/22 brd 172.19.35.255 scope global eth0
\end{alltt}%$
You can see my address is \texttt{172.19.32.30}.
\item Connect to your neighbour's computer, then log out again:
\begin{alltt}
$ \textbf{ssh \meta{neighbour's IP address}}
$ \textbf{exit}
\end{alltt}

\item After your neighbour connected to you, compare the content of
  your {\fn $\sim$/.ssh/known\_hosts} file with the public host key on
  your partner's computer, in {\fn/etc/ssh/ssh\_host\_rsa\_key.pub}.  Are
  they different?  Why or why not?

\item Use the {\pgn scp} program (see section~\vref{sec:how-use-scp})
  to copy a file to the {\fn /tmp} directory on your neighbour's
  computer.
  
\item Log into your account on your neighbour's computer (as described
  in section~\vref{sec:how-use-ssh-to-login}) and verify that you
  copied the file to their machine.
  
\item Set up your own private and public keys as described in
  section~\ref{sec:ssh-keygen}.  You should \emph{use a pass phrase}
  for this exercise.  Do this on the client machine only.
  
\item Set up your $\sim${\fn /.ssh/authorized\_keys} on the server
  using the methods described in section~\ref{sec:authorized_keys}.
  Note: your network drive is the same for your account, both on the
  local client and on the remote server, so you can simply append your
  public key to your $\sim${\fn /.ssh/authorized\_keys} file without
  using {\pgn scp}.  Think about it!
  % Note that the permission for
  % $\sim${\fn /.ssh/authorized\_keys} is different with NFS\@.  (Why?)
  
\item Setup {\pgn ssh-agent} on your client computer and use {\pgn
    ssh-add} to make your personal private key available to {\pgn
    ssh}, as described in section~\ref{sec:ssh-agent}.
  
\item Configure {\pgn keychain} as explained in
  section~\vref{sec:keychain}.

  
%% \item Open the \emph{Red Hat Cusomisation Guide} at
%%   \url{http://ictlab.tyict.vtc.edu.hk/doc/rhl-cg-en-9/s1-openssh-client-config.html},
%%   and configure ssh-agent as explained in the section \emph{15.3.4.4.
%%     Configuring ssh-agent with GNOME}.

\item Demonstrate to your tutor that you can log in to your account on
  your neighbour's computer without typing any passwords.  Show that
  you can execute a graphical program, such as {\pgn emacs} or {\pgn
    xclock}.
  
\item Transfer the entire content of your home directory (complete
  with the directory name) to the \texttt{/tmp} directory of your
  neighbour, using \texttt{rsync}, preserving all timestamps and
  permissions.  Use the \texttt{--stats} option to \texttt{rsync}.
  Verify the the permissions and time stamps are preserved.
  
\item Modify one or two files in your home directory a little.  Repeat
  the data transfer of your home directory to the same location in
  your same neighbour's \texttt{/tmp} directory, again using the
  \texttt{--stats} option.  Do you notice any difference?

%% \item One neighbour should shut down Linux, remove their removable
%%   hard disk, and boot Windows 2000 from the built-in hard disk.  You
%%   will see that {\pgn putty} is installed, as is {\pgn XWin32}\@.  Use
%%   these to log into your account on your neighbour's computer, and
%%   execute a graphical program, such as {\pgn emacs} or {\pgn xclock}.
%%   Use section~\ref{sec:putty-setup} as a guide.

\item To avoid being hihacked, it is wise to transfer a host public
  key on a floppy disk and append it to the file {\fn
    /etc/ssh/ssh\_known\_hosts}.
  \begin{enumerate}
  \item Should you take the host key from your client machine to the
    {\fn /etc/ssh/ssh\_known\_hosts} on the server, or should you
    take the public key from the server and install it on your client?
  \item What two important functions are performed using the \emph{host}
    public and private key pair?
  \item What function is performed by the \emph{user} public and
    private key pair?
  \end{enumerate}
  
\item Install Cygwin on your Windows 2000 machine, and then set up the
  secure shell server, as described in
  \url{http://tech.erdelynet.com/cygwin-sshd.html}.
\end{enumerate}


\section{Secure Shell Solutions}
\label{sec:ssh-solutions}

\includeversion{Solutions}
\excludeversion{noSolutions}

\begin{Solutions}
\begin{enumerate}
  \addtocounter{enumi}{4}
\item The host public key (in
  \texttt{/etc/ssh/ssh\_host\_rsa\_key.pub}) is copied automatically
  over the network and appended to your
  \texttt{$\sim$/.ssh/known\_hosts} file if a copy is not stored in
  any of your \texttt{known\_hosts} files.  So they must be the same.

  \addtocounter{enumi}{5}
\item Because the name service that I set up has been disabled by the
  technical staff, you will need to set the hostname of your computer
  as I described in section~\vref{sec:setting-your-hostname}.  You
  will need to install the \texttt{keychain} shell script as I
  described in section~\vref{sec:keychain}, and edit your login
  scripts \texttt{$\sim$/.bash\_profile} and \texttt{$\sim$/.bashrc}
  as described in section~\vref{sec:keychain-account}.  And no,
  copying this text into a text file and submitting it will \emph{not}
  answer question~8 of your assignment!

  %\addtocounter{enumi}{7}

  \stepcounter{enumi}

\item Verify that your terminal window is open on your own computer by
  checking its \IP address:
\begin{alltt}
$ ip a
\end{alltt}%$
then just transfer it:
\begin{alltt}
$ \textbf{rsync -avz -e ssh \(\sim\) \meta{neighbour's-IP-address}:/tmp}
\end{alltt}%$

  \stepcounter{enumi}

\item 
  \begin{enumerate}
  \item Take the public host key from the server to your client
    machine.  Use a floppy disk or some secure means of transfer (that
    does not use \SSH to the server) to avoid a man-in-the-middle
    attack.  Specifically you could do it like this.  On the server:
\begin{alltt}
$ \textbf{mount /mnt/floppy}
$ \textbf{cp -a /etc/ssh/ssh_host_dsa_key.pub /mnt/floppy}
$ \textbf{umount /mnt/floppy}
\end{alltt}%$
   Then take this floppy to your workstation, and then:
\begin{alltt}
$ \textbf{mount /mnt/floppy}
$ \textbf{sudo sh -c "cat /mnt/floppy/ssh_host_dsa_key.pub >> /etc/ssh/ssh_known_hosts"}
$ \textbf{umount /mnt/floppy}
\end{alltt}%$

\paragraph{A simpler way to avoid hijacking:}

   Note that a possibly more convenient alternative to transferring
   the key on a floppy disk is to first print out the fingerprint of
   your public host key, and put this in your wallet.  Then, when you
   log into your machine from a new remote host, check that the
   fingerprint matches that on the paper in your wallet, and you are
   safe from hijacking if they match.

   Here is how you can determine the fingerprint of your host key:
\begin{alltt}
$ \textbf{ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key}
1024 c6:23:d6:5b:e9:7c:d2:04:0e:69:63:94:c4:3b:b6:95 /etc/ssh/ssh_host_rsa_key.pub
\end{alltt}%$

  \item The host public and private key pair are essential to:
    \begin{enumerate}
    \item \emph{authenticate the server} to your client machine (to
      ensure that no one is performing a man-in-the middle attack on
      you)
    \item initiate the creation of the session keys, used to \emph{encrypt}
      all subsequent communication.
    \end{enumerate}
  \item The client user account is \emph{authenticated} to the server by the
    fact that it has the user's private key, that matches the user
    public key held in the user's account on the server.
  \end{enumerate}
\item Try it; it's really worth while, especially if the server has
  the Microsoft resource kit installed (or most of cygwin, and Perl
  and some useful Windows system administration modules).  You could
  then adminster the Windows machine over a slow network connection,
  even it were on the other side of the world.

  All you need to do is:
  \begin{enumerate}
  \item Go to \url{http://cygwin.com/}, click on the ``Install Cygwin
    now'' icon
  \item Install an absolute minimum of \texttt{cygrunsrv},
    \texttt{openssh}, but I prefer to install the lot (it makes
    Windows much less painful to me).
    \begin{explanation}
      Note that Henry has already installed cygwin on all the
      computers in our A204 laboratories.
    \end{explanation}
  \item Open a \texttt{bash} shell, and type:
\begin{alltt}
$ \textbf{ssh-host-config -y}
\end{alltt}%$
    Just press \key{Enter} to accept the default when asked about what
    value to set \texttt{CYGWIN} to
  \item Then type:
\begin{alltt}
$ \textbf{cygrunsrv -S sshd}
\end{alltt}%$
    and you can then go and log into the machine remotely.
  \end{enumerate}
\end{enumerate}
\end{Solutions}
\begin{noSolutions}
  We will provide solutions soon.
\end{noSolutions}

}% end of normalsize

\excludeversion{Solutions}
\includeversion{noSolutions}

% permissions (from ssh man page):
% $HOME/.ssh/known_hosts see sshd man page: These files should be writable only by root/the own�
%              er.  /etc/ssh/ssh_known_hosts should be world-readable, and
%              $HOME/.ssh/known_hosts can but need not be world-readable.
% $HOME/.ssh/identity, $HOME/.ssh/id_dsa: should be readable by the
%              user but not accessible by others (read/write/execute).  Note
%              that ssh ignores a private key file if it is accessible by oth-
%              ers.
% $HOME/.ssh/identity.pub $HOME/.ssh/id_dsa.pub: These files are not
%              sensitive and
%              can (but need not) be readable by anyone.  These files are never
%              used automatically and are not necessary; they is only provided
%              for the convenience of the user.
% $HOME/.ssh/config: recommended permissions are read/write for the
% user, and not accessible by others.
% $HOME/.ssh/authorized_keys: This file is not highly sensitive, but the recommended
%              permissions are read/write for the user, and not accessible by
%              others.
% From sshd man page: $HOME/.ssh/authorized_keys
%              Lists the RSA keys that can be used to log into the user's ac�
%              count.  This file must be readable by root (which may on some ma�
%              chines imply it being world-readable if the user's home directory
%              resides on an NFS volume).  It is recommended that it not be ac�
%              cessible by others.
% $HOME/.ssh/authorized_keys: recommended permis-
%              sions are read/write for the user, and not accessible by
%              others.  Cannot be group/world writable.
% $HOME/.ssh/rc: This file should be writable only by the user, and need not be
%              readable by anyone else.
% $HOME/.ssh/environment: The file
%              should be writable only by the user; it need not be readable by
%              anyone else.


%          [redhat.com]

% [logo]   [logo]                                       [Image]
%                                                                                            bug #

%  Bugzilla Bug -  18069       Login: nicku@vtc.edu.hk     My Bug List: ( 65 of 254) First |  Last |
%                                                                                       Prev |  Next
%                             Bugzilla: Version 2.8

%  Product - Version         Component    Status      Short Summary
%  Red Hat Linux - 7.0       openssh      ASSIGNED    Please provide a hook for ssh-agent

%  Opened by thilo@innominate.de on  2000-10-02 06:14:33   Long Description

%  SSH works best when you let the ssh-agent take control of the key
%  management.  In order to turn this feature on, you usually start
%  your GUI as a child of the ssh-agent.

%  In 6.2, I always changed /etc/X11/xdm/Xsession to this:

%  gnome)
%         exec ssh-agent gnome-session

%  Of course, for a clean support of the ssh-agent you would want to
%  enhance switchdesk as well and maybe control it via a variable in
%  /etc/sysconfig/* like SSH_AGENT="yes|no".

%  ------- Additional comments from droesen@entire-systems.com 2000-10-03 02:26 -------

%  I wouldn't subscribe to "SSH works best" (then it's most convenient, yes, but
%  also has security implications as you have to trust _all_ child processes of the
%  ssh-agent to not be trojaned and/or leak you secret key anywhere).

%  But I would vote for hooks to easily integrate ssh-agent into the system, yes.

%  ------- Additional comments from nalin@redhat.com 2000-10-04 07:08 -------

%  Probably this would be best done in switchdesk itself with an added flag.

%  ------- Additional comments from kroenner@innominate.de 2000-10-05 08:56 -------

%  I second this feature request.

%  The security issue is not in ssh-agent itself, but comes to play when user
%  executes ssh-add (i.e. via GNOME session-manager) manually. I merely oppose
%  transparently integrating ssh-agent/ssh-add for the uneducated user.

%  ------- Additional comments from dwmw2@infradead.org 2000-10-05 04:17 -------

%  The way I'm doing this at the moment is to add a script
%  /etc/X11/xinit/xinitrc.d/ssh-agent:

%  #!/bin/sh
%  # (c) 2000 Red Hat, Inc.
%  export SSH_ASKPASS=/usr/libexec/ssh/gnome-ssh-askpass
%  eval `/usr/bin/ssh-agent`

%  Making this configurable by the user, and making it use the correct askpass, is
%  left as an exercise for the reader.

%  Additional Information

%             Bug#:18069                    Product:Red Hat Linux                 Version:7.0
%         Platform:All                     Reporter:thilo@innominate.de         Component:openssh
%           Status:ASSIGNED                Priority:normal
%       Resolution:                        Severity:
%      Assigned To:nalin@redhat.com

%                  Cc: droesen@entire-systems.com,kroenner@innominate.de
%          QA Contact:
%                 URL:
%             Summary: Please provide a hook for ssh-agent
%   Status Whiteboard:

%         Attachments:

%  Dependencies: Bug 18069 depends on:  Show dependency tree
%                    Bug 18069 blocks:  Show dependency graph

%  Additional Comments

%  Public Changes
%  (Non-members will need to create account)



%  [View Bug Activity]   [Format For Printing]

%   ------------------------------------------------------------------------

%   Home |  News |  New Bug |  Query |  Help |  LogOut |
%                          Errata                          This is Bugzilla: the Mozilla bug system.
%        --------------------------------------------       For more information about what Bugzilla
%    For questions or comments on bugzilla send mail to     is and what it can do, see mozilla.org's
%                 bugzilla-owner@redhat.com                                bug pages.
% From - Mon Jan 29 10:43:28 2001
% Return-Path: <owner-ssh@clinet.fi>
% Received: from localhost (IDENT:nicku@localhost [127.0.0.1])
%       by nickpc.tycm.vtc.edu.hk (8.11.0/8.11.0) with ESMTP id eB8943C01019
%       for <nicku@localhost>; Fri, 8 Dec 2000 17:04:04 +0800
% Received: from hqmail.vtc.edu.hk [192.168.79.199]
%       by localhost with POP3 (fetchmail-5.5.0)
%       for nicku@localhost (single-drop); Fri, 08 Dec 2000 17:04:04 +0800 (CST)
% Received: from mail.clinet.fi ([194.100.0.7]) by
%           hqmail.vtc.edu.hk (Netscape Messaging Server 4.15) with ESMTP id
%           G58RK700.C0C for <nicku@vtc.edu.hk>; Fri, 8 Dec 2000 16:57:43 +0800 
% Received: (from majordom@localhost)
%       by mail.clinet.fi (8.9.3/8.9.3) id DAA03905
%       for ssh-outgoing; Fri, 8 Dec 2000 03:54:01 +0200
% Received: from odo.brooklin.on.ca (IDENT:root@Oshawa-ppp109382.sympatico.ca [216.209.113.59])
%       by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA03899
%       for <ssh@clinet.fi>; Fri, 8 Dec 2000 03:53:57 +0200
% Received: from sympatico.ca (IDENT:mcgfre@localhost [127.0.0.1])
%       by odo.brooklin.on.ca (8.9.3/8.9.3) with ESMTP id UAA03225;
%       Thu, 7 Dec 2000 20:59:24 -0500
% Message-ID: <3A30407A.F9A77901@sympatico.ca>
% Date: Thu, 07 Dec 2000 20:59:22 -0500
% From: Fred McGuirk <fmcguirk@sympatico.ca>
% X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586)
% X-Accept-Language: en
% MIME-Version: 1.0
% To: ssh@clinet.fi
% Subject: Re: Using ssh-agent with GNOME
% Content-Type: text/plain; charset=us-ascii
% Content-Transfer-Encoding: 7bit
% Sender: owner-ssh@clinet.fi
% Precedence: bulk

% G'day

% In response to a message that i saw in the message archive...


% "Braden N. McDaniel" wrote:
% > I'm trying to use ssh-agent with GNOME. I have placed the line
% >
% >   ssh-agent gnome-session
% >
% > in my .gnomerc file. But when I attempt to run ssh-add, I get
% >
% >  Could not open a connection to your authentication agent.
% >
% > "ps -A" shows that ssh-agent is indeed running. What might I be doing
% > wrong?



% I have been doing this for several months now...

% I am running on a RedHat 6.2 system, this approach should be easily
% adapted for almost any other environment...

% My system is configured to start in X-Windows with GDM managing the
% login (this approach also works for both kdm and xdm)...

% The Gnome Display Manager (gdm) uses several configuration files to
% control the initial display and the login process.  The important files
% to consider here are the files in the '/etc/X11/gdm/Session' directory.

% One of these files will be used to setup the session once a valid login
% has been entered (I will use the default session - adjust as required).

% The 'default' session file actually uses '/etc/X11/xdm/Xsession'.

% I have added the following lines into this file BEFORE the block of
% logic that starts the desktop environment:

% # SSH Password Dialog for X
% #SSH_ASKPASS=/usr/lib/ssh/openssh-askpass
% SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
% export SSH_ASKPASS
% eval `ssh-agent`

% Then, in the GNOME Control Center under 'Session' / 'Startup Programs' I
% have added the command 'ssh-add' with a priority of 50.

% As the GNOME initialization completes, the 'ssh-add' command is
% executed; since there is no terminal session available it looks to the
% environment variable 'SSH_ASKPASS' to get the name of the program to
% execute to prompt for the password.

% I hope this helps.



% -- 
% Fred McGuirk
% ------------------------------------------------------------------------
% memorable comment to be added later... when memory permits
% ------------------------------------------------------------------------
