\section{SSH}

\begin{frame}
   {SSH}
   \begin{itemize}
      \item \textbf{ssh}: login to or carry out commands on
      remote system.
      \item Includes \textbf{scp}: transfer files
      to and from remote systems
      \item Uses strong encryption for security

      (hence name: \textbf{S}ecure \textbf{SH}ell)
      \begin{cmd}
$ ssh remote_computer.com
$ ssh some_user@remote_computer.com
$ ssh some_user@remote_computer.com apt-get update
$ scp file.txt remote_computer.com:/tmp
$ scp usr1@rem1.com:/tmp/f.txt usr2@rem2.com:/tmp/nf.txt
      \end{cmd}
      \item
      Run a command on multiple systems simultaneously:
      \begin{cmd}
$ for machines in node1 node2 node3
  do
      (ssh $machines some_command &)
  done
      \end{cmd}
   \end{itemize}
\end{frame}

\cprotect\note{

   One often needs to login through the network into a
   remote system, either with the same user name or
   another.  Or one needs to transfer files to and from a
   remote machine.  In either case, one wants to do this
   securely, free from interception.

   \textbf{SSH} (\textbf{S}ecure \textbf{SH}ell) exists for
   this purpose.  It uses encryption based on strong
   algorithms.  Assuming the proper \textbf{ssh} packages
   are installed on a system, one needs no further setup to
   begin using \textbf{ssh}.
   To sign onto a remote system:

   \begin{cmd}
$ ssh farflung.com
   \end{cmd}
   \begin{response}
student@farflung.com's password: (type here)
   \end{response}
   assuming there is a \texttt{student} account on
   \url{farflung.com}.  To log in as a different user:
   \begin{cmd}
$ ssh root@farflung.com
$ ssh -l root farflung.com
   \end{cmd}

   To copy files from one system to another:
   \begin{cmd}
$ scp file.txt farflung.com:/tmp
$ scp file.tex student@farflung.com/home/student
$ scp -r some_dir farflung.com:/tmp/some_dir
   \end{cmd}
   (We have omitted the request for a password to save space.)

}


\begin{frame}
   {ssh Configuration Files}

   \begin{itemize}
      \item
      In home directory:

      \begin{itemize}
         \item
         \filelink{id_rsa}: the user's \textbf{private}
         encryption key.
         \item
         \filelink{id_rsa.pub}: the user's \textbf{public}
         encryption key.
         \item
         \filelink{authorized_keys}: Public keys that are
         permitted to login.
         \item
         \filelink{known_hosts}: Hosts from which logins have
         been allowed in the past.
         \item
         \filelink{config}: File for specifying various
         options.
      \end{itemize}
      \item Public and private keys generated with
      \textbf{ssh-keygen}
   \end{itemize}
\end{frame}

\cprotect\note{
   \small
   {

      One can configure \textbf{SSH} further to expedite its
      use, in particular to permit logging in without a
      password.
      User-specific configuration files are created under every
      user's home directory in the hidden \filelink{.ssh}
      directory:

      First a user has to generate their private and public
      encryption keys with \textbf{ssh-keygen}:
      \begin{cmd}
$ ssh-keygen
   \end{cmd}
      \begin{response}
Generating public/private rsa key pair.
...
   \end{response}
      The private key must \textbf{never} ever be shared with
      anyone. The public key, however, should be given to any
      machine with which you want to permit password-less
      access.  It should also be added to your
      \filelink{authorized_keys} file, together with all the
      public keys from other users who have accounts on your
      machine and you want to permit password-less access to
      their accounts.
      \filelink{known_hosts} is gradually built up as
      \textbf{ssh} accesses occur.  If the system detects
      changes in the users who are trying to log in through
      \textbf{ssh} it will warn you of them and afford the
      opportunity to deny access.

      Note that \file{authorized\_keys} contains information
      about users and machines:
      \begin{cmd}
$ cat authorized_keys
   \end{cmd}
      \begin{response}
ssh-rsa AAAAB3Nza........student@debian
ssh-rsa AAAAB3Nza........student@fedora
   \end{response}
      while  \file{known\_hosts}  contains only
      information about computer nodes:
      \begin{cmd}
$ cat known_hosts
   \end{cmd}
      \begin{response}
x7 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN...... M=
192.168.1.200 ecdsa-sha2-nistp256 AAAA...... bcs=
   \end{response}
      Do \verb?man ssh_config? to see the options that can go
      into the \textbf{ssh} configuration files.
   }

}


\begin{frame}
   {Remote Graphical Login}

   \begin{itemize}
      \item
      Login into remote machine with full graphical
      desktop
      \item
      Often use \textbf{VNC} (\textbf{V}irtual \textbf{N}etwork
      \textbf{C}omputing)
      \item
      Common implementation is \textbf{tigervnc}
      \item
      As simple as:
      \begin{itemize}
         \item
         On remote machine (e.g., \verb?some_machine?):
         \begin{cmd}
$ vncserver
         \end{cmd}
         \item
         On local machine:
         \begin{cmd}
$ vncviewer -via server student@some_machine localhost:2
         \end{cmd}
      \end{itemize}
   \end{itemize}
\end{frame}

\cprotect\note{

   To test this first make sure you have the \textbf{vnc}
   packages installed:
   \begin{cmd}
$ which vncserver vncviewer
   \end{cmd}
   \begin{response}
/usr/bin/vncserver
/usr/bin/vncviewer
   \end{response}
   If you do not find these programs you will have to install
   with something like:
   \begin{cmd}
$ sudo [dnf|zypper|apt-get] install tigervnc*
   \end{cmd}
   using the right package management system command.  (The exact package
   name have varied between \textbf{Linux} distributions,
   so we are not giving exact package names.  You may wind up installing
   more than you need, but the packages are not large.)
   Start the server as a normal user with:
   \begin{cmd}
$ vncserver
   \end{cmd}
   You can test with
   \begin{cmd}
$ vncviewer localhost:2
   \end{cmd}
   (You may have to play with numbers other than 2 (1, 3, 4,
   ...)  depending on what you are running at the moment and
   how your machine is configured.)
   To view from a remote machine it is just slightly
   different:
   \begin{cmd}
$ vncviewer -via student@some_machine localhost:2
   \end{cmd}

   If you get a rather strange message about having to
   authenticate because of ``color profile'' and no passwords
   work, you have to kill the \textbf{colord} daemon on the
   server machine, as in
   \begin{cmd}
$ sudo systemctl stop colord
   \end{cmd}
   This is a bug (not a feature) and will only appear in some
   distributions and some systems for unclear reasons.

}
