White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
c06a3df4d0
commit
f13f1ae640
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44525
1 changed files with 135 additions and 126 deletions
|
|
@ -2437,9 +2437,10 @@ racoon_enable="yes"</programlisting>
|
|||
</indexterm>
|
||||
|
||||
<para><application>OpenSSH</application> is a set of network
|
||||
connectivity tools used to provide secure access to remote machines.
|
||||
Additionally, <acronym>TCP/IP</acronym> connections can be tunneled or forwarded
|
||||
securely through <acronym>SSH</acronym> connections.
|
||||
connectivity tools used to provide secure access to remote
|
||||
machines. Additionally, <acronym>TCP/IP</acronym> connections
|
||||
can be tunneled or forwarded securely through
|
||||
<acronym>SSH</acronym> connections.
|
||||
<application>OpenSSH</application> encrypts all traffic to
|
||||
effectively eliminate eavesdropping, connection hijacking, and
|
||||
other network-level attacks.</para>
|
||||
|
|
@ -2473,9 +2474,9 @@ racoon_enable="yes"</programlisting>
|
|||
<secondary>client</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>To log into a <acronym>SSH</acronym> server, use
|
||||
<para>To log into a <acronym>SSH</acronym> server, use
|
||||
<command>ssh</command> and specify a username that exists on
|
||||
that server and the <acronym>IP</acronym> address or hostname
|
||||
that server and the <acronym>IP</acronym> address or hostname
|
||||
of the server. If this is the first time a connection has
|
||||
been made to the specified server, the user will be prompted
|
||||
to first verify the server's fingerprint:</para>
|
||||
|
|
@ -2489,24 +2490,24 @@ Password for user@example.com: <userinput><replaceable>user_password</replaceabl
|
|||
|
||||
<para><acronym>SSH</acronym> utilizes a key fingerprint system
|
||||
to verify the authenticity of the server when the client
|
||||
connects. When the user accepts the key's fingerprint by typing
|
||||
<literal>yes</literal> when connecting for the first time, a
|
||||
copy of the key is saved to
|
||||
<filename>.ssh/known_hosts</filename> in the user's home directory.
|
||||
Future attempts to login are verified against the saved
|
||||
key and <command>ssh</command> will display an
|
||||
alert if the server's key does not match the saved key. If
|
||||
this occurs, the user should first verify
|
||||
why the key has changed before continuing with the
|
||||
connection.</para>
|
||||
connects. When the user accepts the key's fingerprint by
|
||||
typing <literal>yes</literal> when connecting for the first
|
||||
time, a copy of the key is saved to
|
||||
<filename>.ssh/known_hosts</filename> in the user's home
|
||||
directory. Future attempts to login are verified against the
|
||||
saved key and <command>ssh</command> will display an alert if
|
||||
the server's key does not match the saved key. If this
|
||||
occurs, the user should first verify why the key has changed
|
||||
before continuing with the connection.</para>
|
||||
|
||||
<para>By default, recent versions of <application>OpenSSH</application> only accept
|
||||
<acronym>SSH</acronym>v2 connections. By default, the client will use
|
||||
version 2 if possible and will fall back to version 1 if the
|
||||
server does not support version 2. To
|
||||
force <command>ssh</command> to only use the specified protocol, include
|
||||
<option>-1</option> or <option>-2</option>. Additional
|
||||
options are described in &man.ssh.1;.</para>
|
||||
<para>By default, recent versions of
|
||||
<application>OpenSSH</application> only accept
|
||||
<acronym>SSH</acronym>v2 connections. By default, the client
|
||||
will use version 2 if possible and will fall back to version 1
|
||||
if the server does not support version 2. To force
|
||||
<command>ssh</command> to only use the specified protocol,
|
||||
include <option>-1</option> or <option>-2</option>.
|
||||
Additional options are described in &man.ssh.1;.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>OpenSSH</primary>
|
||||
|
|
@ -2516,10 +2517,11 @@ Password for user@example.com: <userinput><replaceable>user_password</replaceabl
|
|||
<primary>&man.scp.1;</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Use &man.scp.1; to securely copy a file to or from a remote machine.
|
||||
This example copies <filename>COPYRIGHT</filename> on the
|
||||
remote system to a file of the same name in the current
|
||||
directory of the local system:</para>
|
||||
<para>Use &man.scp.1; to securely copy a file to or from a
|
||||
remote machine. This example copies
|
||||
<filename>COPYRIGHT</filename> on the remote system to a file
|
||||
of the same name in the current directory of the local
|
||||
system:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
|
||||
Password for user@example.com: <userinput><replaceable>*******</replaceable></userinput>
|
||||
|
|
@ -2531,13 +2533,13 @@ COPYRIGHT 100% |*****************************| 4735
|
|||
the server's key is automatically checked before prompting for
|
||||
the user's password.</para>
|
||||
|
||||
<para>The arguments passed to <command>scp</command> are similar to
|
||||
<command>cp</command>. The file or files to copy is the first
|
||||
argument and the destination to copy to is the second. Since the file
|
||||
is fetched over the network, one or more of the file
|
||||
arguments takes the form
|
||||
<para>The arguments passed to <command>scp</command> are similar
|
||||
to <command>cp</command>. The file or files to copy is the
|
||||
first argument and the destination to copy to is the second.
|
||||
Since the file is fetched over the network, one or more of the
|
||||
file arguments takes the form
|
||||
<option>user@host:<path_to_remote_file></option>.</para>
|
||||
|
||||
|
||||
<para>To open an interactive session for copying files, use
|
||||
<command>sftp</command>. Refer to &man.sftp.1; for a list of
|
||||
available commands while in an <command>sftp</command>
|
||||
|
|
@ -2546,14 +2548,14 @@ COPYRIGHT 100% |*****************************| 4735
|
|||
<sect3 xml:id="security-ssh-keygen">
|
||||
<title>Key-based Authentication</title>
|
||||
|
||||
<para>Instead of using passwords, a client can be configured
|
||||
to connect to the remote machine
|
||||
using keys. To generate <acronym>DSA</acronym> or
|
||||
<acronym>RSA</acronym> authentication keys, use
|
||||
<command>ssh-keygen</command>. To generate a
|
||||
public and private key pair, specify the type of key and
|
||||
follow the prompts. It is recommended to protect the keys
|
||||
with a memorable, but hard to guess passphrase.</para>
|
||||
<para>Instead of using passwords, a client can be configured
|
||||
to connect to the remote machine using keys. To generate
|
||||
<acronym>DSA</acronym> or <acronym>RSA</acronym>
|
||||
authentication keys, use <command>ssh-keygen</command>. To
|
||||
generate a public and private key pair, specify the type of
|
||||
key and follow the prompts. It is recommended to protect
|
||||
the keys with a memorable, but hard to guess
|
||||
passphrase.</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
|
||||
Generating public/private dsa key pair.
|
||||
|
|
@ -2566,12 +2568,12 @@ Your public key has been saved in /home/user/.ssh/id_dsa.pub.
|
|||
The key fingerprint is:
|
||||
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>
|
||||
|
||||
<para>Depending upon the specified protocol, the private key is stored
|
||||
in <filename>~/.ssh/id_dsa</filename> (or
|
||||
<para>Depending upon the specified protocol, the private key
|
||||
is stored in <filename>~/.ssh/id_dsa</filename> (or
|
||||
<filename>~/.ssh/id_rsa</filename>), and the public key
|
||||
is stored in <filename>~/.ssh/id_dsa.pub</filename> (or
|
||||
<filename>~/.ssh/id_rsa.pub</filename>).
|
||||
The <emphasis>public</emphasis> key must be first copied to
|
||||
<filename>~/.ssh/id_rsa.pub</filename>). The
|
||||
<emphasis>public</emphasis> key must be first copied to
|
||||
<filename>~/.ssh/authorized_keys</filename> on the remote
|
||||
machine in order for key-based authentication to
|
||||
work.</para>
|
||||
|
|
@ -2580,10 +2582,11 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>
|
|||
<para>Many users believe that keys are secure by design and
|
||||
will use a key without a passphrase. This is
|
||||
<emphasis>dangerous</emphasis> behavior. An
|
||||
administrator can verify that a key pair is protected by a passphrase
|
||||
by viewing the private key manually. If the private key file
|
||||
contains the word <literal>ENCRYPTED</literal>, the key
|
||||
owner is using a passphrase. In addition, to better secure end users,
|
||||
administrator can verify that a key pair is protected by a
|
||||
passphrase by viewing the private key manually. If the
|
||||
private key file contains the word
|
||||
<literal>ENCRYPTED</literal>, the key owner is using a
|
||||
passphrase. In addition, to better secure end users,
|
||||
<literal>from</literal> may be placed in the public key
|
||||
file. For example, adding
|
||||
<literal>from="192.168.10.5"</literal> in the front of
|
||||
|
|
@ -2592,29 +2595,29 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>
|
|||
that <acronym>IP</acronym> address.</para>
|
||||
</warning>
|
||||
|
||||
<para>The various options and files can be different
|
||||
according to the <application>OpenSSH</application>
|
||||
version. To avoid problems, consult
|
||||
&man.ssh-keygen.1;.</para>
|
||||
<para>The various options and files can be different
|
||||
according to the <application>OpenSSH</application> version.
|
||||
To avoid problems, consult &man.ssh-keygen.1;.</para>
|
||||
|
||||
<para>If a passphrase is used, the user
|
||||
will be prompted for the passphrase each time a connection
|
||||
is made to the server. To load <acronym>SSH</acronym> keys
|
||||
into memory, without needing to type the passphrase
|
||||
each time, use &man.ssh-agent.1; and &man.ssh-add.1;.</para>
|
||||
<para>If a passphrase is used, the user will be prompted for
|
||||
the passphrase each time a connection is made to the server.
|
||||
To load <acronym>SSH</acronym> keys into memory, without
|
||||
needing to type the passphrase each time, use
|
||||
&man.ssh-agent.1; and &man.ssh-add.1;.</para>
|
||||
|
||||
<para>Authentication is handled by <command>ssh-agent</command>, using
|
||||
the private key(s) that are loaded into it. Then,
|
||||
<command>ssh-agent</command> should be used to launch another
|
||||
application such as a
|
||||
<para>Authentication is handled by
|
||||
<command>ssh-agent</command>, using the private key(s) that
|
||||
are loaded into it. Then, <command>ssh-agent</command>
|
||||
should be used to launch another application such as a
|
||||
shell or a window manager.</para>
|
||||
|
||||
<para>To use <command>ssh-agent</command> in a shell, start it with a
|
||||
shell as an argument. Next, add the identity by running
|
||||
<command>ssh-add</command> and providing it the passphrase for the
|
||||
private key. Once these steps have been completed, the user
|
||||
will be able to <command>ssh</command> to any host that has the
|
||||
corresponding public key installed. For example:</para>
|
||||
<para>To use <command>ssh-agent</command> in a shell, start it
|
||||
with a shell as an argument. Next, add the identity by
|
||||
running <command>ssh-add</command> and providing it the
|
||||
passphrase for the private key. Once these steps have been
|
||||
completed, the user will be able to <command>ssh</command>
|
||||
to any host that has the corresponding public key installed.
|
||||
For example:</para>
|
||||
|
||||
<screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
|
||||
&prompt.user; ssh-add
|
||||
|
|
@ -2625,18 +2628,18 @@ Identity added: /usr/home/user/.ssh/id_dsa (/usr/home/user/.ssh/id_dsa)
|
|||
<para>To use <command>ssh-agent</command> in
|
||||
<application>&xorg;</application>, add an entry for it in
|
||||
<filename>~/.xinitrc</filename>. This provides the
|
||||
<command>ssh-agent</command> services to all programs launched in
|
||||
<application>&xorg;</application>. An example
|
||||
<command>ssh-agent</command> services to all programs
|
||||
launched in <application>&xorg;</application>. An example
|
||||
<filename>~/.xinitrc</filename> might look like this:</para>
|
||||
|
||||
<programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>
|
||||
|
||||
<para>This launches <command>ssh-agent</command>, which in turn launches
|
||||
<application>XFCE</application>, every time
|
||||
<para>This launches <command>ssh-agent</command>, which in
|
||||
turn launches <application>XFCE</application>, every time
|
||||
<application>&xorg;</application> starts. Once
|
||||
<application>&xorg;</application> has been restarted so that
|
||||
the changes can take effect, run <command>ssh-add</command> to load all
|
||||
of the <acronym>SSH</acronym> keys.</para>
|
||||
the changes can take effect, run <command>ssh-add</command>
|
||||
to load all of the <acronym>SSH</acronym> keys.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3 xml:id="security-ssh-tunneling">
|
||||
|
|
@ -2651,8 +2654,9 @@ Identity added: /usr/home/user/.ssh/id_dsa (/usr/home/user/.ssh/id_dsa)
|
|||
create a tunnel to encapsulate another protocol in an
|
||||
encrypted session.</para>
|
||||
|
||||
<para>The following command tells <command>ssh</command> to create a
|
||||
tunnel for <application>telnet</application>:</para>
|
||||
<para>The following command tells <command>ssh</command> to
|
||||
create a tunnel for
|
||||
<application>telnet</application>:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
|
||||
&prompt.user;</screen>
|
||||
|
|
@ -2664,8 +2668,8 @@ Identity added: /usr/home/user/.ssh/id_dsa (/usr/home/user/.ssh/id_dsa)
|
|||
<term><option>-2</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>Forces <command>ssh</command> to use version 2 to connect to
|
||||
the server.</para>
|
||||
<para>Forces <command>ssh</command> to use version 2 to
|
||||
connect to the server.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -2674,7 +2678,8 @@ Identity added: /usr/home/user/.ssh/id_dsa (/usr/home/user/.ssh/id_dsa)
|
|||
|
||||
<listitem>
|
||||
<para>Indicates no command, or tunnel only. If omitted,
|
||||
<command>ssh</command> initiates a normal session.</para>
|
||||
<command>ssh</command> initiates a normal
|
||||
session.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -2709,21 +2714,21 @@ Identity added: /usr/home/user/.ssh/id_dsa (/usr/home/user/.ssh/id_dsa)
|
|||
|
||||
<para>An <acronym>SSH</acronym> tunnel works by creating a
|
||||
listen socket on <systemitem>localhost</systemitem> on the
|
||||
specified <literal>localport</literal>. It then forwards any connections received
|
||||
on <literal>localport</literal> via the <acronym>SSH</acronym>
|
||||
connection to the specified <literal>remotehost:remoteport</literal>.
|
||||
In the example, port <literal>5023</literal> on
|
||||
the client is forwarded to port
|
||||
<literal>23</literal> on
|
||||
the remote machine.
|
||||
Since port 23 is used by
|
||||
<application>telnet</application>, this creates an encrypted <application>telnet</application>
|
||||
specified <literal>localport</literal>. It then forwards
|
||||
any connections received on <literal>localport</literal> via
|
||||
the <acronym>SSH</acronym> connection to the specified
|
||||
<literal>remotehost:remoteport</literal>. In the example,
|
||||
port <literal>5023</literal> on the client is forwarded to
|
||||
port <literal>23</literal> on the remote machine. Since
|
||||
port 23 is used by <application>telnet</application>, this
|
||||
creates an encrypted <application>telnet</application>
|
||||
session through an <acronym>SSH</acronym> tunnel.</para>
|
||||
|
||||
<para>This method can be used to wrap any number of insecure <acronym>TCP</acronym>
|
||||
protocols such as <acronym>SMTP</acronym>,
|
||||
<acronym>POP3</acronym>, and <acronym>FTP</acronym>, as seen
|
||||
in the following examples.</para>
|
||||
<para>This method can be used to wrap any number of insecure
|
||||
<acronym>TCP</acronym> protocols such as
|
||||
<acronym>SMTP</acronym>, <acronym>POP3</acronym>, and
|
||||
<acronym>FTP</acronym>, as seen in the following
|
||||
examples.</para>
|
||||
|
||||
<example>
|
||||
<title>Create a Secure Tunnel for
|
||||
|
|
@ -2738,23 +2743,24 @@ Escape character is '^]'.
|
|||
220 mailserver.example.com ESMTP</screen>
|
||||
|
||||
<para>This can be used in conjunction with
|
||||
<command>ssh-keygen</command> and additional user accounts to create
|
||||
a more seamless <acronym>SSH</acronym> tunneling
|
||||
<command>ssh-keygen</command> and additional user accounts
|
||||
to create a more seamless <acronym>SSH</acronym> tunneling
|
||||
environment. Keys can be used in place of typing a
|
||||
password, and the tunnels can be run as a separate
|
||||
user.</para>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Secure Access of a <acronym>POP3</acronym> Server</title>
|
||||
<title>Secure Access of a <acronym>POP3</acronym>
|
||||
Server</title>
|
||||
|
||||
<para>In this example, there is an <acronym>SSH</acronym>
|
||||
server that accepts connections from the outside. On the
|
||||
same network resides a mail server running a <acronym>POP3</acronym> server.
|
||||
To check email in a secure manner, create an
|
||||
<acronym>SSH</acronym> connection to the
|
||||
<acronym>SSH</acronym> server and tunnel through to the
|
||||
mail server:</para>
|
||||
same network resides a mail server running a
|
||||
<acronym>POP3</acronym> server. To check email in a
|
||||
secure manner, create an <acronym>SSH</acronym> connection
|
||||
to the <acronym>SSH</acronym> server and tunnel through to
|
||||
the mail server:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:mail.example.com:110 user@ssh-server.example.com</replaceable></userinput>
|
||||
user@ssh-server.example.com's password: <userinput>******</userinput></screen>
|
||||
|
|
@ -2771,10 +2777,11 @@ user@ssh-server.example.com's password: <userinput>******</userinput></screen>
|
|||
|
||||
<para>Some firewalls
|
||||
filter both incoming and outgoing connections. For
|
||||
example, a firewall might limit access from remote machines to
|
||||
ports 22 and 80 to only allow <acronym>SSH</acronym> and web surfing.
|
||||
This prevents access to any other service which uses a
|
||||
port other than 22 or 80.</para>
|
||||
example, a firewall might limit access from remote
|
||||
machines to ports 22 and 80 to only allow
|
||||
<acronym>SSH</acronym> and web surfing. This prevents
|
||||
access to any other service which uses a port other than
|
||||
22 or 80.</para>
|
||||
|
||||
<para>The solution is to create an <acronym>SSH</acronym>
|
||||
connection to a machine outside of the network's firewall
|
||||
|
|
@ -2805,16 +2812,15 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
|
|||
<acronym>SSH</acronym> server, accepting connections from
|
||||
other <acronym>SSH</acronym> clients.</para>
|
||||
|
||||
<para>To see if <application>sshd</application> is enabled, check
|
||||
<filename>/etc/rc.conf</filename> for this line and add it if
|
||||
it is missing:</para>
|
||||
<para>To see if <application>sshd</application> is enabled,
|
||||
check <filename>/etc/rc.conf</filename> for this line and add
|
||||
it if it is missing:</para>
|
||||
|
||||
<programlisting>sshd_enable="YES"</programlisting>
|
||||
|
||||
<para>This will start <application>sshd</application>, the daemon program for
|
||||
<application>OpenSSH</application>, the next time the system
|
||||
boots. To start it
|
||||
now:</para>
|
||||
<para>This will start <application>sshd</application>, the
|
||||
daemon program for <application>OpenSSH</application>, the
|
||||
next time the system boots. To start it now:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service sshd start</userinput></screen>
|
||||
|
||||
|
|
@ -2830,10 +2836,10 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
|
|||
and the various configuration files.</para>
|
||||
|
||||
<para>It is a good idea to limit which users can log into the
|
||||
<acronym>SSH</acronym> server
|
||||
and from where using the <literal>AllowUsers</literal> keyword
|
||||
in the <application>OpenSSH</application> server configuration file. For
|
||||
example, to only allow <systemitem
|
||||
<acronym>SSH</acronym> server and from where using the
|
||||
<literal>AllowUsers</literal> keyword in the
|
||||
<application>OpenSSH</application> server configuration file.
|
||||
For example, to only allow <systemitem
|
||||
class="username">root</systemitem> to log in from
|
||||
<systemitem class="ipaddress">192.168.1.32</systemitem>, add
|
||||
this line to <filename>/etc/ssh/sshd_config</filename>:</para>
|
||||
|
|
@ -2850,31 +2856,34 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
|
|||
so:</para>
|
||||
|
||||
<programlisting>AllowUsers root@192.168.1.32 admin</programlisting>
|
||||
|
||||
<para>After making changes to
|
||||
<filename>/etc/ssh/sshd_config</filename>, tell <application>sshd</application>
|
||||
to reload its configuration file by running:</para>
|
||||
<filename>/etc/ssh/sshd_config</filename>,
|
||||
tell <application>sshd</application> to reload its
|
||||
configuration file by running:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service sshd reload</userinput></screen>
|
||||
|
||||
<note>
|
||||
<para>When this keyword is used, it is important to list each user that needs to log into
|
||||
this machine. Any user that is not specified in that line will be locked out. Also, the
|
||||
<para>When this keyword is used, it is important to list each
|
||||
user that needs to log into this machine. Any user that is
|
||||
not specified in that line will be locked out. Also, the
|
||||
keywords used in the <application>OpenSSH</application>
|
||||
server configuration file are case-sensitive. If the
|
||||
keyword is not spelled correctly, including its case, it will
|
||||
be ignored. Always test changes to this file to make sure
|
||||
that the edits are working as expected. Refer to
|
||||
keyword is not spelled correctly, including its case, it
|
||||
will be ignored. Always test changes to this file to make
|
||||
sure that the edits are working as expected. Refer to
|
||||
&man.sshd.config.5; to verify the spelling and use of the
|
||||
available keywords.</para>
|
||||
</note>
|
||||
|
||||
<tip>
|
||||
<para>Don't confuse <filename>/etc/ssh/sshd_config</filename>
|
||||
with <filename>/etc/ssh/ssh_config</filename> (note the extra
|
||||
<literal>d</literal> in the first filename). The first file
|
||||
configures the server and the second file configures the
|
||||
client. Refer to &man.ssh.config.5; for a listing of the
|
||||
available client settings,.</para>
|
||||
with <filename>/etc/ssh/ssh_config</filename> (note the
|
||||
extra <literal>d</literal> in the first filename). The
|
||||
first file configures the server and the second file
|
||||
configures the client. Refer to &man.ssh.config.5; for a
|
||||
listing of the available client settings,.</para>
|
||||
</tip>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
|
|||
Loading…
Reference in a new issue