ACC SHELL

Path : /usr/share/gnome/help/opensuse-manuals/C/
File Upload :
Current File : //usr/share/gnome/help/opensuse-manuals/C/cha.ssh.html

<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 13. SSH: Secure Network Operations</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.network_security.html" title="Part III. Network Security"><link rel="prev" href="part.network_security.html" title="Part III. Network Security"><link rel="next" href="cha.security.firewall.html" title="Chapter 14. Masquerading and Firewalls"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> &gt; </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> &gt; </span><a href="part.network_security.html">Network Security</a><span class="breadcrumbs-sep"> &gt; </span><strong><a accesskey="p" title="Part III. Network Security" href="part.network_security.html"><span>&#9664;</span></a>  <a accesskey="n" title="Chapter 14. Masquerading and Firewalls" href="cha.security.firewall.html"><span>&#9654;</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 13. SSH: Secure Network Operations"><div class="titlepage"><div><div><h2 class="title"><a name="cha.ssh"></a>Chapter 13. SSH: Secure Network Operations<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.ssh">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.impl">13.1. The OpenSSH Package</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.programm">13.2. The ssh Program</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.copy">13.3. scp&#8212;Secure Copy</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.sftp">13.4. sftp&#8212;Secure File Transfer</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.sshdserver">13.5. The SSH Daemon (sshd)&#8212;Server-Side</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.authentic">13.6. SSH Authentication Mechanisms</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.pipe">13.7. X, Authentication, and Forwarding Mechanisms</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.ssh.yast">13.8. Configuring An SSH Daemon with YaST</a></span></dt><dt><span class="sect1"><a href="cha.ssh.html#sec.security.ssh.moreinfo">13.9. For More Information</a></span></dt></dl></div><a class="indexterm" name="id587240"></a><a class="indexterm" name="id587248"></a><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>
   In networked environments, it is often necessary to access hosts from a
   remote location. If a user sends login and password strings for
   authentication purposes as plain text, they could be intercepted and
   misused to gain access to that user account without the authorized user
   knowing about it. This would open all the user's files to an attacker and
   the illegal account could be used to obtain administrator or
   <code class="systemitem">root</code> access, or to penetrate
   other systems. In the past, remote connections were established with
   telnet, which offers no guards against eavesdropping in the form of
   encryption or other security mechanisms. There are other unprotected
   communication channels, like the traditional FTP protocol and some remote
   copying programs.
  </p></div><p>
  The SSH suite provides the necessary protection by encrypting the
  authentication strings (usually a login name and a password) and all the
  other data exchanged between the hosts. With SSH, the data flow could
  still be recorded by a third party, but the contents are encrypted and
  cannot be reverted to plain text unless the encryption key is known. So
  SSH enables secure communication over insecure networks, such as the
  Internet. The SSH implementation coming with openSUSE is OpenSSH.
 </p><div class="sect1" title="13.1. The OpenSSH Package"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.impl"></a>13.1. The OpenSSH Package<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.impl">¶</a></span></h2></div></div></div><a class="indexterm" name="id587296"></a><p>
   openSUSE installs the OpenSSH package by default. The
   <span class="command"><strong>ssh</strong></span>, <span class="command"><strong>scp</strong></span>, and
   <span class="command"><strong>sftp</strong></span> command line tools are then available as
   alternatives to <span class="command"><strong>telnet</strong></span>, <span class="command"><strong>rlogin</strong></span>,
   <span class="command"><strong>rsh</strong></span>, <span class="command"><strong>rcp</strong></span>, and
   <span class="command"><strong>ftp</strong></span>. In the default configuration, system access of a
   openSUSE system is only possible with the OpenSSH utilities, and
   only if <code class="systemitem">sshd</code> is running and the firewall permits
   access.
  </p></div><div class="sect1" title="13.2. The ssh Program"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.programm"></a>13.2. The ssh Program<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.programm">¶</a></span></h2></div></div></div><a class="indexterm" name="id587360"></a><a class="indexterm" name="id587368"></a><p>
   Using the ssh program, it is possible to log in to remote systems and
   work interactively. It replaces both telnet and rlogin. The slogin
   program is just a symbolic link pointing to ssh. For example, log in to
   the host <code class="literal">sun</code> with the command
   <span class="command"><strong>ssh</strong></span> <code class="option">sun</code>. The host
   then prompts for the password on <code class="literal">sun</code>.
  </p><p>
   After successful authentication, you can work on the remote command line
   or use interactive applications, such as YaST. If the local username is
   different from the remote username, log in using a different login name
   with <span class="command"><strong>ssh</strong></span> <code class="option">-l augustine
   sun</code> or
   <span class="command"><strong>ssh</strong></span> <code class="option">augustine@sun</code>.
  </p><p>
   Furthermore, ssh offers the possibility to run commands on remote
   systems, as known from rsh. In the following example, run the command
   <span class="command"><strong>uptime</strong></span> on the host sun and create a
   directory with the name <code class="filename">tmp</code>. The program output is
   displayed on the local terminal of the host jupiter.
  </p><pre class="screen">ssh otherplanet "uptime; mkdir tmp"
Password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02</pre><p>
   Quotation marks are necessary here to send both instructions with one
   command. It is only by doing this that the second command is executed on
   sun.
  </p></div><div class="sect1" title="13.3. scp&#8212;Secure Copy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.copy"></a>13.3. scp&#8212;Secure Copy<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.copy">¶</a></span></h2></div></div></div><a class="indexterm" name="id587452"></a><a class="indexterm" name="id587460"></a><p>
   scp copies files to a remote machine. It is a secure and encrypted
   substitute for rcp. For example,
   <span class="command"><strong>scp</strong></span> <code class="option">MyLetter.tex
   sun:</code> copies the file
   <code class="filename">MyLetter.tex</code> from the host jupiter to the host
   sun. If the username on jupiter is different than the username
   on sun, specify the latter using the
   <code class="option">username@host</code> format. The <code class="option">-l</code> option has
   a different meaning for this command.
  </p><p>
   After the correct password is entered, scp starts the data transfer and
   shows a growing row of asterisks, simulating a progress bar. In addition,
   the program displays the estimated time of arrival to the right of the
   progress bar. Suppress all output with the <code class="option">-q</code> option.
  </p><p>
   scp also provides a recursive copying feature for entire directories. The
   command <span class="command"><strong>scp</strong></span> <code class="option">-r src/
   sun:backup/</code> copies the entire contents of the
   directory <code class="filename">src</code> including all subdirectories to the
   <code class="filename">backup</code> directory on the host sun. If
   this subdirectory does not exist it is created automatically.
  </p><p>
   The <code class="option">-p</code> option tells scp to leave the time stamp of files
   unchanged. <code class="option">-C</code> compresses the data transfer. This
   minimizes the data volume to transfer, but creates a heavier burden on
   the processor.
  </p></div><div class="sect1" title="13.4. sftp&#8212;Secure File Transfer"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.sftp"></a>13.4. sftp&#8212;Secure File Transfer<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.sftp">¶</a></span></h2></div></div></div><a class="indexterm" name="id587547"></a><a class="indexterm" name="id587556"></a><p>
   The sftp program can be used instead of scp for secure file transfer.
   During an sftp session, you can use many of the commands known from ftp.
   The sftp program may be a better choice than scp, especially when
   transferring data for which the filenames are unknown.
  </p></div><div class="sect1" title="13.5. The SSH Daemon (sshd)&#8212;Server-Side"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.sshdserver"></a>13.5. The SSH Daemon (sshd)&#8212;Server-Side<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.sshdserver">¶</a></span></h2></div></div></div><a class="indexterm" name="id587581"></a><a class="indexterm" name="id587590"></a><p>
   To work with the SSH client programs ssh and scp, a server (the SSH
   daemon) must be running in the background, listening for connections on
   <code class="literal">TCP/IP port 22</code>. The daemon generates three key pairs
   when starting for the first time. Each key pair consists of a private and
   a public key. Therefore, this procedure is referred to as public
   key&#8211;based. To guarantee the security of the communication via SSH,
   access to the private key files must be restricted to the system
   administrator. The file permissions are set accordingly by the default
   installation. The private keys are only required locally by the SSH
   daemon and must not be given to anyone else. The public key components
   (recognizable by the name extension <code class="filename">.pub</code>) are sent
   to the client requesting the connection. They are readable for all users.
   <a class="indexterm" name="id587616"></a>
  </p><p>
   A connection is initiated by the SSH client. The waiting SSH daemon and
   the requesting SSH client exchange identification data to compare the
   protocol and software versions, and to prevent connections through the
   wrong port. Because a child process of the original SSH daemon replies to
   the request, several SSH connections can be made simultaneously.
  </p><p>
   For the communication between SSH server and SSH client, OpenSSH supports
   versions 1 and 2 of the SSH protocol. Version 2 of the SSH
   protocol is used by default. Override this to use version 1 of
   protocol with the <code class="option">-1</code> option.
  </p><p>
   When using version 1 of SSH, the server sends its public host key
   and a server key, which is regenerated by the SSH daemon every hour. Both
   allow the SSH client to encrypt a freely chosen session key, which is
   sent to the SSH server. The SSH client also tells the server which
   encryption method (cipher) to use. Version 2 of the SSH protocol
   does not require a server key. Both sides use an algorithm according to
   Diffie-Hellman to exchange their keys.
  </p><p>
   The private host and server keys are absolutely required to decrypt the
   session key and cannot be derived from the public parts. Only the
   contacted SSH daemon can decrypt the session key using its private keys.
   This initial connection phase can be watched closely by turning on
   verbose debugging using the <code class="option">-v</code> option of the SSH client.
  </p><p>
   The client stores all public host keys in
   <code class="filename">~/.ssh/known_hosts</code> after its first contact with a
   remote host. This prevents any man-in-the-middle attacks&#8212;attempts
   by foreign SSH servers to use spoofed names and IP addresses. Such
   attacks are detected either by a host key that is not included in
   <code class="filename">~/.ssh/known_hosts</code>, or by the server's inability to
   decrypt the session key in the absence of an appropriate private
   counterpart.
  </p><p>
   It is recommended to back up the private and public keys stored in
   <code class="filename">/etc/ssh/</code> in a secure, external location. In this
   way, key modifications can be detected and the old ones can be used again
   after reinstallation. This spares users any unsettling warnings. If it is
   verified that, despite the warning, it is indeed the correct SSH server,
   the existing entry for the system must be removed from
   <code class="filename">~/.ssh/known_hosts</code>.
  </p></div><div class="sect1" title="13.6. SSH Authentication Mechanisms"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.authentic"></a>13.6. SSH Authentication Mechanisms<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.authentic">¶</a></span></h2></div></div></div><a class="indexterm" name="id587701"></a><a class="indexterm" name="id587709"></a><p>
   Now the actual authentication takes place, which, in its simplest form,
   consists of entering a password as mentioned above. The goal of SSH was
   to introduce secure software that is also easy to use. Because it is
   meant to replace rsh and rlogin, SSH must also be able to provide an
   authentication method appropriate for daily use. SSH accomplishes this by
   way of another key pair, which is generated by the user. The SSH package
   provides a helper program for this: ssh-keygen. After entering
   <span class="command"><strong>ssh-keygen</strong></span> <code class="option">-t rsa</code> or
   <span class="command"><strong>ssh-keygen</strong></span> <code class="option">-t dsa</code>, the key pair
   is generated and you are prompted for the base filename in which to store
   the keys.
  </p><a class="indexterm" name="id587741"></a><a class="indexterm" name="id587750"></a><p>
   Confirm the default setting and answer the request for a passphrase. Even
   if the software suggests an empty passphrase, a text from 10 to 30
   characters is recommended for the procedure described here. Do not use
   short and simple words or phrases. Confirm by repeating the passphrase.
   Subsequently, you will see where the private and public keys are stored,
   in this example, the files <code class="filename">id_rsa</code> and
   <code class="filename">id_rsa.pub</code>.
  </p><p>
   Use <span class="command"><strong>ssh-keygen</strong></span> <code class="option">-p -t rsa</code> or
   <span class="command"><strong>ssh-keygen</strong></span> <code class="option">-p -t dsa</code> to change
   your old passphrase. Copy the public key component
   (<code class="filename">id_rsa.pub</code> in the example) to the remote machine
   and save it to <code class="filename">~/.ssh/authorized_keys</code>. You will be
   asked to authenticate yourself with your passphrase the next time you
   establish a connection. If this does not occur, verify the location and
   contents of these files.
  </p><p>
   In the long run, this procedure is more troublesome than giving your
   password each time. Therefore, the SSH package provides another tool,
   ssh-agent, which retains the private keys for the duration of an X
   session. The entire X session is started as a child process of ssh-agent.
   The easiest way to do this is to set the variable
   <code class="literal">usessh</code> at the beginning of the
   <code class="filename">.xsession</code> file to <code class="literal">yes</code> and log in
   via a display manager, such as KDM or GDM. Alternatively, enter
   <span class="command"><strong>ssh-agent</strong></span> <code class="option">startx</code>.
  </p><a class="indexterm" name="id587827"></a><a class="indexterm" name="id587836"></a><a class="indexterm" name="id587844"></a><p>
   Now you can use <span class="command"><strong>ssh</strong></span> or <span class="command"><strong>scp</strong></span> as
   usual. If you have distributed your public key as described above, you
   are no longer prompted for your password. Take care of terminating your X
   session or locking it with a password protection application, such as
   xlock.
  </p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: File Permissions for Host-Based Authentication"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">File Permissions for Host-Based Authentication</th></tr><tr><td colspan="2" align="left" valign="top"><p>
    If the host-based authentication is to be used, the file
    <code class="filename">/usr/lib/ssh/ssh-keysign</code> or
    <code class="filename">/usr/lib64/ssh/ssh-keysign</code> should have setuid bit
    set, which is not the default setting in openSUSE. In such a case,
    set the file permissions manually. You should use
    <code class="filename">/etc/permissions.local</code> for this purpose, to make
    sure that the setuid bit is preserved after security updates of openssh.
   </p></td></tr></table></div></div><div class="sect1" title="13.7. X, Authentication, and Forwarding Mechanisms"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.pipe"></a>13.7. X, Authentication, and Forwarding Mechanisms<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.pipe">¶</a></span></h2></div></div></div><a class="indexterm" name="id587905"></a><a class="indexterm" name="id587913"></a><p>
   Beyond the previously described security-related improvements, SSH also
   simplifies the use of remote X applications. If you run
   <span class="command"><strong>ssh</strong></span> with the <code class="option">-X</code> option, the
   <code class="envar">DISPLAY</code> variable is automatically set on the remote
   machine and all X output is exported to the remote machine over the
   existing SSH connection. At the same time, X applications started
   remotely and locally viewed with this method cannot be intercepted by
   unauthorized individuals.
  </p><p>
   By adding the <code class="option">-A</code> option, the ssh-agent authentication
   mechanism is carried over to the next machine. This way, you can work
   from different machines without having to enter a password, but only if
   you have distributed your public key to the destination hosts and
   properly saved it there.
  </p><a class="indexterm" name="id587950"></a><p>
   Both mechanisms are deactivated in the default settings, but can be
   permanently activated at any time in the systemwide configuration file
   <code class="filename">/etc/ssh/sshd_config</code> or the user's
   <code class="filename">~/.ssh/config</code>.
  </p><a class="indexterm" name="id587971"></a><p>
   ssh can also be used to redirect TCP/IP connections. In the examples
   below, SSH is told to redirect the SMTP and the POP3 port, respectively:
  </p><pre class="screen">ssh -L 25:sun:25 jupiter</pre><p>
   With this command, any connection directed to jupiter port 25 (SMTP) is
   redirected to the SMTP port on sun via an encrypted channel.
   This is especially useful for those using SMTP servers without SMTP-AUTH
   or POP-before-SMTP features. From any arbitrary location connected to a
   network, e-mail can be transferred to the <span class="quote">&#8220;<span class="quote">home</span>&#8221;</span> mail server
   for delivery. Similarly, all POP3 requests (port 110) on jupiter can
   be forwarded to the POP3 port of sun with this command:
  </p><pre class="screen">ssh -L 110:sun:110 jupiter</pre><p>
   Both commands must be executed as
   <code class="systemitem">root</code>, because the connection is
   made to privileged local ports. E-mail is sent and retrieved by normal
   users in an existing SSH connection. The SMTP and POP3 host must be set
   to <code class="literal">localhost</code> for this to work. Additional information
   can be found in the manual pages for each of the programs described above
   and also in OpenSSH package documentation under
   <code class="filename">/usr/share/doc/packages/openssh</code>.
  </p></div><div class="sect1" title="13.8. Configuring An SSH Daemon with YaST"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.ssh.yast"></a>13.8. Configuring An SSH Daemon with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.ssh.yast">¶</a></span></h2></div></div></div><p>

   The YaST SSHD Configuration module is not part of the default
   installation. To install it, start YaST and select
   <span class="guimenu">Software</span>+<span class="guimenu">Software
   Management</span> and search for
   <code class="systemitem">yast2-sshd</code>. Confirm the found item and install
   it.
  </p><p>
   To configure an sshd server with YaST run YaST and choose
   <span class="guimenu">Network Services</span>+<span class="guimenu">SSHD
   Configuration</span>. Then proceed as follows:
  </p><div class="procedure"><ol class="procedure" type="1"><li><p>
     On the <span class="guimenu">General</span> tab, select the ports sshd should
     listen on in the <span class="guimenu">SSHD TCP Ports</span> table. The default
     port number is 22. Multiple ports are allowed. To add a new port, click
     <span class="guimenu">Add</span>, enter the port number and click
     <span class="guimenu">OK</span>. To delete port, select it in the table, click
     <span class="guimenu">Delete</span> and confirm.
    </p></li><li><p>
     On the <span class="guimenu">General</span> tab, select the features the sshd
     daemon should support. To disable TCP forwarding, uncheck
     <span class="guimenu">Allow TCP Forwarding</span>. Disabling TCP forwarding does
     not improve security unless users are also denied shell access, as they
     can always install their own forwarders. See
     <a class="xref" href="cha.ssh.html#sec.ssh.pipe" title="13.7. X, Authentication, and Forwarding Mechanisms">Section 13.7, &#8220;X, Authentication, and Forwarding Mechanisms&#8221;</a> for more information about TCP
     forwarding.
    </p><p>
     To disable X forwarding, uncheck <span class="guimenu">Allow X11
     Forwarding</span>. If this option is disabled, any X11 forward
     requests by the client will return an error. However users can always
     install their own forwarders. See <a class="xref" href="cha.ssh.html#sec.ssh.pipe" title="13.7. X, Authentication, and Forwarding Mechanisms">Section 13.7, &#8220;X, Authentication, and Forwarding Mechanisms&#8221;</a> for
     more information about X forwarding.
    </p><p>
     In <span class="guimenu">Allow Compression</span> determine, whether the
     connection between the server and clients should be compressed. After
     setting these options, click <span class="guimenu">Next</span>.
    </p></li><li><p>
     The <span class="guimenu">Login Settings</span> tab contains general login and
     authentication settings. In <span class="guimenu">Print Message of the Day After
     Login</span> determine, whether sshd should print message from
     <code class="filename">/etc/motd</code> when a user logs in interactively. If
     you want to disable connection of a user
     <code class="systemitem">root</code>, uncheck <span class="guimenu">Permit
     Root Login</span>.
    </p><p>
     In <span class="guimenu">Maximum Authentication Tries</span> enter the maximum
     allowed number of authentication attempts per connection.


     <span class="guimenu">RSA Authentication</span> specifies whether pure RSA
     authentication is allowed. This option applies to SSH protocol version
     1 only. <span class="guimenu">Public Key Authentication</span> specifies whether
     public key authentication is allowed. This option applies to protocol
     version 2 only.
    </p></li><li><p>
     On the <span class="guimenu">Protocol and Ciphers</span> tab, determine which
     versions of the SSH protocol should be supported. You can choose to
     support version 1 only, version 2 only, or to support both SSH version
     2 and 1.
    </p><p>
     Under <span class="guimenu">Supported Ciphers</span>, all supported ciphers are
     listed. You can remove a cipher by selecting it in the list and
     clicking <span class="guimenu">Delete</span>. To add a cipher to the list, select
     it from the dropdown menu and click <span class="guimenu">Add</span>.
    </p></li><li><p>
     Click <span class="guimenu">Finish</span> to save the configuration.
    </p></li></ol></div></div><div class="sect1" title="13.9. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.ssh.moreinfo"></a>13.9. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ssh.moreinfo">¶</a></span></h2></div></div></div><p></p><div class="variablelist"><dl><dt><span class="term"><a class="ulink" href="http://www.openssh.com" target="_top">http://www.openssh.com</a>
    </span></dt><dd><p>
      The homepage of OpenSSH
     </p></dd><dt><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh_config</code>
    </span></dt><dd><p>
      Manpage of OpenSSH SSH client configuration files
     </p></dd><dt><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh_config</code>
    </span></dt><dd><p>
      Manpage of OpenSSH SSH daemon configuration file
     </p></dd><dt><span class="term"><span class="command"><strong>man</strong></span> <code class="option">sshd</code>
    </span></dt><dd><p>
      Manpage of OpenSSH daemon
     </p></dd><dt><span class="term"><span class="command"><strong>man</strong></span> <code class="option">scp</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">sftp</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">slogin</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh-add</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh-agent</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh-copy-id</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh-keyconvert</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh-keygen</code>
    , </span><span class="term"><span class="command"><strong>man</strong></span> <code class="option">ssh-keyscan</code>
    </span></dt><dd><p>
      Manpage of several binary files to copy (<span class="command"><strong>scp</strong></span>,
      <span class="command"><strong>sftp</strong></span>), login (<span class="command"><strong>slogin</strong></span>,
      <span class="command"><strong>ssh</strong></span>), and manage keys.
     </p></dd></dl></div></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> &gt; </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> &gt; </span><a href="part.network_security.html">Network Security</a><span class="breadcrumbs-sep"> &gt; </span><strong><a accesskey="p" title="Part III. Network Security" href="part.network_security.html"><span>&#9664;</span></a>  <a accesskey="n" title="Chapter 14. Masquerading and Firewalls" href="cha.security.firewall.html"><span>&#9654;</span></a></strong></p></div></td></tr></table></div></body></html>

ACC SHELL 2018