os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update OpenSSH section

Browse source 
* Incorporate more information about SSH v2
   client, DSA keys
 * Explain scp in better terms
 * Change tunneling section
 * Add two "Practical Tunneling Examples"

Reviewed by:	murray
This commit is contained in:
Chern Lee 2001-08-31 00:10:35 +00:00
parent acc8614939
commit 48be3c9f93
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10507
1 changed files with 101 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

117
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.72 2001/08/16 18:35:07 chern Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.73 2001/08/30 18:59:28 chern Exp $
-->
<chapter id="security">
@ -2879,7 +2879,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<secondary>OpenSSH</secondary>
</indexterm>
<para>Secure shell is a set of network connectivity tools used to
<para>Secure shell is a set of network connectivity tools used to
access remote machines securely. It can be used as a direct
replacement for <command>rlogin</command>,
<command>rsh</command>, <command>rcp</command>, and
@ -2946,8 +2946,18 @@ user@foobardomain.com's password: <userinput>*******</userinput></screen>
verified against the saved fingerprint key. The SSH client
will alert you if the saved fingerprint differs from the
received fingerprint on future login attempts. The fingerprints
are saved in <filename>~/.ssh/known_hosts</filename>
are saved in <filename>~/.ssh/known_hosts</filename>, or
<filename>~/.ssh/known_hosts2</filename> for SSH v2 fingerprints.
</para>
<para>By default, OpenSSH servers are configured to accept both
SSH v1 and SSH v2 connections. The client, however, can choose
between the two. Version 2 is known to be more robust and
secure than its predecessor.</para>
<para><command>ssh</command> can be forced to use either protocol
by passing it the <option>-1</option> or <option>-2</option> argument
for v1 and v2, respectively.</para>
</sect2>
<sect2>
@ -2971,6 +2981,14 @@ COPYRIGHT 100% |*****************************| 4735
previous example, it is verified when using <command>scp</command>
here.
</para>
<para>The arguments passed to <command>scp</command> are similar
to <command>cp</command>, with the file or files in the first
argument, and the destination in the second. Since the file is
fetched over the network, through SSH, one or more of the file
arguments takes on the form
<option>user@host:&lt;path_to_remote_file></option>.</para>
</sect2>
<sect2>
@ -2988,6 +3006,11 @@ COPYRIGHT 100% |*****************************| 4735
settings, while <filename>sshd_config</filename> configures the
daemon.
</para>
<para>Additionally, the <option>sshd_program</option>
(<filename>/usr/sbin/sshd</filename> by default), and
<option>sshd_flags</option> <filename>rc.conf</filename>
options can provide more levels of configuration.</para>
</sect2>
<sect2>
@ -3024,6 +3047,16 @@ Your identification has been saved in /home/user/.ssh/identity.
will be prompted for a password each time in order to use the private
key.</para>
<para>A SSH v2 DSA key can be created for the same purpose by using
the <command>ssh-keygen -t dsa</command> command. This will
create a public/private DSA key for use in SSH v2 sessions only.
The public key is stored in <filename>~/.ssh/id_dsa.pub</filename>,
while the private key is in <filename>~/.ssh/id_dsa</filename>.</para>
<para>DSA public keys are placed in
<filename>~/.ssh/authorized_keys2</filename> on the remote
machine.</para>
<para>&man.ssh-agent.1; and &man.ssh-add.1; are
utilities used in managing multiple passworded private keys.
</para>
@ -3058,9 +3091,10 @@ Your identification has been saved in /home/user/.ssh/identity.
in the background.</para>
</listitem>
<listitem>
<para><emphasis>-L</emphasis> indicates a local tunnel in
<replaceable>localport:localhost:remoteport</replaceable> fashion.
</para>
<para><emphasis>-L</emphasis> indicates a local tunnel in
<replaceable>localport:remotehost:remoteport</replaceable>
fashion.
</para>
</listitem>
<listitem>
<para><replaceable>foo.bar.com</replaceable> is the remote/target
@ -3069,16 +3103,16 @@ Your identification has been saved in /home/user/.ssh/identity.
</listitem>
</itemizedlist>
<para>An SSH tunnel works by creating a listen socket on the specified
local host and port. It then forwards any connection to the local
host/port via the SSH connection to the remote machine on the
specified remote port.
</para>
<para>An SSH tunnel works by creating a listen socket on localhost
on the specified port. It then forwards any connection received
on the local host/port via the SSH connection to the specified
remote host and port.</para>
<para>In the example, port <replaceable>5023</replaceable> on localhost
is being forwarded to port <replaceable>23</replaceable> on the remote
machine. Since <replaceable>23</replaceable> is telnet, this would
create a secure telnet session through an SSH tunnel.
<para>In the example, port <replaceable>5023</replaceable> on
localhost is being forwarded to port
<replaceable>23</replaceable> on localhost of the remote
machine. Since <replaceable>23</replaceable> is telnet, this
would create a secure telnet session through an SSH tunnel.
</para>
<para>This can be used to wrap any number of insecure TCP protocols
@ -3098,7 +3132,58 @@ Escape character is '^]'.
and additional user accounts to create a more seamless/hassle-free
SSH tunneling environment. Keys can be used in place of typing
a password, and the tunnels can be run as a separate user.
</para>
</para>
<sect3>
<title>Practical SSH Tunneling Examples</title>
<sect4>
<title>Secure Access of a POP3 server</title>
<para>At work, there is an SSH server that accepts
connections from the outside. On the same office network
resides a mail server running a POP3 server. The network,
or network path between your home and office may or may not
be completely trustable. Because of this, you need to check
your e-mail in a secure manner. The solution is to create
an SSH connection to your office's SSH server, and tunnel
through to the mail server.</para>
<screen>&prompt.user; ssh -2 -N -f -L 2110:mail.office-foobar.com user@ssh-server.office-foobar.com
user@ssh-server.office-foobar.com's password: ******</screen>
<para>When the tunnel is up and running, you can point your
mail client to send POP3 requests to <hostid>localhost</hostid>
port 2110. A connection here will be forwarded securely across
the tunnel to <hostid>mail.office-foobar.com</hostid>.</para>
</sect4>
<sect4>
<title>Bypassing a Draconian Firewall</title>
<para>Some network administrators impose extremely Draconian
firewall rules, filtering not only incoming connections,
but outgoing connections. You may be only given access
to contact remote machines on ports 22 and 80 for SSH
and web surfing.</para>
<para>You may wish to access another (perhaps non-work
related) service, such as an Ogg Vorbis server to stream
music. If this Ogg Vorbis server is streaming on some other
port than 22 or 80, you will not be able to access it.</para>
<para>The solution is to create an SSH connection to a machine
outside of your network's firewall, and use it to tunnel to
the Ogg Vorbis server.</para>
<screen>&prompt.user; ssh -2 -N -f -L 8888:music.foobar.com:8000 user@unfirewalled.myserver.com
user@unfirewalled.myserver.com's password: *******</screen>
<para>Your streaming client can now be pointed to
<hostid>localhost</hostid> port 8888, which will be
forwarded over to <hostid>music.foobar.com</hostid> port
8000, successfully evading the firewall.</para>
</sect3>
</sect2>
<sect2>