% Nick Urbanik % 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: 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: 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: % 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 ; 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 ; 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 ; 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 % 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 % ------------------------------------------------------------------------