From owner-svn-doc-all@FreeBSD.ORG Thu Apr 10 20:52:24 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4184FFB0; Thu, 10 Apr 2014 20:52:24 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7A31392; Thu, 10 Apr 2014 20:52:24 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s3AKqODv032801; Thu, 10 Apr 2014 20:52:24 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s3AKqOM0032800; Thu, 10 Apr 2014 20:52:24 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201404102052.s3AKqOM0032800@svn.freebsd.org> From: Dru Lavigne Date: Thu, 10 Apr 2014 20:52:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44525 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:52:24 -0000 Author: dru Date: Thu Apr 10 20:52:23 2014 New Revision: 44525 URL: http://svnweb.freebsd.org/changeset/doc/44525 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu Apr 10 20:37:05 2014 (r44524) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu Apr 10 20:52:23 2014 (r44525) @@ -2437,9 +2437,10 @@ racoon_enable="yes" OpenSSH is a set of network - connectivity tools used to provide secure access to remote machines. - Additionally, TCP/IP connections can be tunneled or forwarded - securely through SSH connections. + connectivity tools used to provide secure access to remote + machines. Additionally, TCP/IP connections + can be tunneled or forwarded securely through + SSH connections. OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. @@ -2473,9 +2474,9 @@ racoon_enable="yes" client - To log into a SSH server, use + To log into a SSH server, use ssh and specify a username that exists on - that server and the IP address or hostname + that server and the IP 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: @@ -2489,24 +2490,24 @@ Password for user@example.com: SSH 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 - yes when connecting for the first time, a - copy of the key is saved to - .ssh/known_hosts in the user's home directory. - Future attempts to login are verified against the saved - key and ssh 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. - - By default, recent versions of OpenSSH only accept - SSHv2 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 ssh to only use the specified protocol, include - or . Additional - options are described in &man.ssh.1;. + connects. When the user accepts the key's fingerprint by + typing yes when connecting for the first + time, a copy of the key is saved to + .ssh/known_hosts in the user's home + directory. Future attempts to login are verified against the + saved key and ssh 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. + + By default, recent versions of + OpenSSH only accept + SSHv2 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 + ssh to only use the specified protocol, + include or . + Additional options are described in &man.ssh.1;. OpenSSH @@ -2516,10 +2517,11 @@ Password for user@example.com: &man.scp.1; - Use &man.scp.1; to securely copy a file to or from a remote machine. - This example copies COPYRIGHT on the - remote system to a file of the same name in the current - directory of the local system: + Use &man.scp.1; to securely copy a file to or from a + remote machine. This example copies + COPYRIGHT on the remote system to a file + of the same name in the current directory of the local + system: &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT Password for user@example.com: ******* @@ -2531,13 +2533,13 @@ COPYRIGHT 100% |************* the server's key is automatically checked before prompting for the user's password. - The arguments passed to scp are similar to - cp. 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 + The arguments passed to scp are similar + to cp. 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 . - + To open an interactive session for copying files, use sftp. Refer to &man.sftp.1; for a list of available commands while in an sftp @@ -2546,14 +2548,14 @@ COPYRIGHT 100% |************* Key-based Authentication - Instead of using passwords, a client can be configured - to connect to the remote machine - using keys. To generate DSA or - RSA authentication keys, use - ssh-keygen. 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. + Instead of using passwords, a client can be configured + to connect to the remote machine using keys. To generate + DSA or RSA + authentication keys, use ssh-keygen. 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. &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. @@ -2566,12 +2568,12 @@ Your public key has been saved in /home/ The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com - Depending upon the specified protocol, the private key is stored - in ~/.ssh/id_dsa (or + Depending upon the specified protocol, the private key + is stored in ~/.ssh/id_dsa (or ~/.ssh/id_rsa), and the public key is stored in ~/.ssh/id_dsa.pub (or - ~/.ssh/id_rsa.pub). - The public key must be first copied to + ~/.ssh/id_rsa.pub). The + public key must be first copied to ~/.ssh/authorized_keys on the remote machine in order for key-based authentication to work. @@ -2580,10 +2582,11 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 Many users believe that keys are secure by design and will use a key without a passphrase. This is dangerous 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 ENCRYPTED, 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 + ENCRYPTED, the key owner is using a + passphrase. In addition, to better secure end users, from may be placed in the public key file. For example, adding from="192.168.10.5" in the front of @@ -2592,29 +2595,29 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 that IP address. - The various options and files can be different - according to the OpenSSH - version. To avoid problems, consult - &man.ssh-keygen.1;. - - If a passphrase is used, the user - will be prompted for the passphrase each time a connection - is made to the server. To load SSH keys - into memory, without needing to type the passphrase - each time, use &man.ssh-agent.1; and &man.ssh-add.1;. - - Authentication is handled by ssh-agent, using - the private key(s) that are loaded into it. Then, - ssh-agent should be used to launch another - application such as a + The various options and files can be different + according to the OpenSSH version. + To avoid problems, consult &man.ssh-keygen.1;. + + If a passphrase is used, the user will be prompted for + the passphrase each time a connection is made to the server. + To load SSH keys into memory, without + needing to type the passphrase each time, use + &man.ssh-agent.1; and &man.ssh-add.1;. + + Authentication is handled by + ssh-agent, using the private key(s) that + are loaded into it. Then, ssh-agent + should be used to launch another application such as a shell or a window manager. - To use ssh-agent in a shell, start it with a - shell as an argument. Next, add the identity by running - ssh-add and providing it the passphrase for the - private key. Once these steps have been completed, the user - will be able to ssh to any host that has the - corresponding public key installed. For example: + To use ssh-agent in a shell, start it + with a shell as an argument. Next, add the identity by + running ssh-add and providing it the + passphrase for the private key. Once these steps have been + completed, the user will be able to ssh + to any host that has the corresponding public key installed. + For example: &prompt.user; ssh-agent csh &prompt.user; ssh-add @@ -2625,18 +2628,18 @@ Identity added: /usr/home/user/.ssh/id_d To use ssh-agent in &xorg;, add an entry for it in ~/.xinitrc. This provides the - ssh-agent services to all programs launched in - &xorg;. An example + ssh-agent services to all programs + launched in &xorg;. An example ~/.xinitrc might look like this: exec ssh-agent startxfce4 - This launches ssh-agent, which in turn launches - XFCE, every time + This launches ssh-agent, which in + turn launches XFCE, every time &xorg; starts. Once &xorg; has been restarted so that - the changes can take effect, run ssh-add to load all - of the SSH keys. + the changes can take effect, run ssh-add + to load all of the SSH keys. @@ -2651,8 +2654,9 @@ Identity added: /usr/home/user/.ssh/id_d create a tunnel to encapsulate another protocol in an encrypted session. - The following command tells ssh to create a - tunnel for telnet: + The following command tells ssh to + create a tunnel for + telnet: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; @@ -2664,8 +2668,8 @@ Identity added: /usr/home/user/.ssh/id_d - Forces ssh to use version 2 to connect to - the server. + Forces ssh to use version 2 to + connect to the server. @@ -2674,7 +2678,8 @@ Identity added: /usr/home/user/.ssh/id_d Indicates no command, or tunnel only. If omitted, - ssh initiates a normal session. + ssh initiates a normal + session. @@ -2709,21 +2714,21 @@ Identity added: /usr/home/user/.ssh/id_d An SSH tunnel works by creating a listen socket on localhost on the - specified localport. It then forwards any connections received - on localport via the SSH - connection to the specified remotehost:remoteport. - In the example, port 5023 on - the client is forwarded to port - 23 on - the remote machine. - Since port 23 is used by - telnet, this creates an encrypted telnet + specified localport. It then forwards + any connections received on localport via + the SSH connection to the specified + remotehost:remoteport. In the example, + port 5023 on the client is forwarded to + port 23 on the remote machine. Since + port 23 is used by telnet, this + creates an encrypted telnet session through an SSH tunnel. - This method can be used to wrap any number of insecure TCP - protocols such as SMTP, - POP3, and FTP, as seen - in the following examples. + This method can be used to wrap any number of insecure + TCP protocols such as + SMTP, POP3, and + FTP, as seen in the following + examples. 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 + Secure Access of a <acronym>POP3</acronym> + Server In this example, there is an SSH server that accepts connections from the outside. On the - same network resides a mail server running a POP3 server. - To check email in a secure manner, create an - SSH connection to the - SSH server and tunnel through to the - mail server: + same network resides a mail server running a + POP3 server. To check email in a + secure manner, create an SSH connection + to the SSH server and tunnel through to + the mail server: &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** @@ -2771,10 +2777,11 @@ user@ssh-server.example.com's password: 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 SSH and web surfing. - This prevents access to any other service which uses a - port other than 22 or 80. + example, a firewall might limit access from remote + machines to ports 22 and 80 to only allow + SSH and web surfing. This prevents + access to any other service which uses a port other than + 22 or 80. The solution is to create an SSH connection to a machine outside of the network's firewall @@ -2805,16 +2812,15 @@ user@unfirewalled-system.example.org's p SSH server, accepting connections from other SSH clients. - To see if sshd is enabled, check - /etc/rc.conf for this line and add it if - it is missing: + To see if sshd is enabled, + check /etc/rc.conf for this line and add + it if it is missing: sshd_enable="YES" - This will start sshd, the daemon program for - OpenSSH, the next time the system - boots. To start it - now: + This will start sshd, the + daemon program for OpenSSH, the + next time the system boots. To start it now: &prompt.root; service sshd start @@ -2830,10 +2836,10 @@ user@unfirewalled-system.example.org's p and the various configuration files. It is a good idea to limit which users can log into the - SSH server - and from where using the AllowUsers keyword - in the OpenSSH server configuration file. For - example, to only allow SSH server and from where using the + AllowUsers keyword in the + OpenSSH server configuration file. + For example, to only allow root to log in from 192.168.1.32, add this line to /etc/ssh/sshd_config: @@ -2850,31 +2856,34 @@ user@unfirewalled-system.example.org's p so: AllowUsers root@192.168.1.32 admin + After making changes to - /etc/ssh/sshd_config, tell sshd - to reload its configuration file by running: + /etc/ssh/sshd_config, + tell sshd to reload its + configuration file by running: &prompt.root; service sshd reload - 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 + 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 OpenSSH 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. Don't confuse /etc/ssh/sshd_config - with /etc/ssh/ssh_config (note the extra - d 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,. + with /etc/ssh/ssh_config (note the + extra d 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,.