From owner-svn-doc-projects@FreeBSD.ORG Thu May 2 14:22:16 2013 Return-Path: Delivered-To: svn-doc-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FD2E40D; Thu, 2 May 2013 14:22:16 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 5120B1FA5; Thu, 2 May 2013 14:22:16 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.6/8.14.6) with ESMTP id r42EMGtb080646; Thu, 2 May 2013 14:22:16 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.6/8.14.5/Submit) id r42EMGne080645; Thu, 2 May 2013 14:22:16 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201305021422.r42EMGne080645@svn.freebsd.org> From: Dru Lavigne Date: Thu, 2 May 2013 14:22:16 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r41541 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-projects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:22:16 -0000 Author: dru Date: Thu May 2 14:22:15 2013 New Revision: 41541 URL: http://svnweb.freebsd.org/changeset/doc/41541 Log: This patch addresses the following in the second half of this chapter: - you - &os; - some acronym tags - the remaining command/application tags that should be man page entities - some grammar fixes Approved by: bcr (mentor) Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu May 2 13:02:26 2013 (r41540) +++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu May 2 14:22:15 2013 (r41541) @@ -53,7 +53,7 @@ How to configure TCP Wrappers for use - with inetd. + with &man.inetd.8;. @@ -257,7 +257,7 @@ Securing the <username>root</username> Account - su + &man.su.1; Most @@ -355,7 +355,7 @@ sandboxes - sshd + &man.sshd.8; The prudent sysadmin only enables required services @@ -365,12 +365,12 @@ root as many daemons can be run as a separate service account or can be started in a sandbox. Do not activate insecure - services such as telnetd or - rlogind. + services such as &man.telnetd.8; or + &man.rlogind.8;. Another potential security hole is SUID-root and SGID binaries. Most of these binaries, such as - rlogin, reside in /bin, /sbin, /usr/bin, or - sysctl + &man.sysctl.8; Even if bpf is disabled, @@ -525,7 +525,7 @@ The best way to detect an intrusion is to look for modified, missing, or unexpected files. The best way to look for modified files is from another, often centralized, - limited-access system. Writing your security scripts on the + limited-access system. Writing security scripts on the extra-security limited-access system makes them mostly invisible to potential attackers. In order to take maximum advantage, @@ -657,7 +657,7 @@ &man.inetd.8; carefully and pay specific attention to , , and . Spoofed IP attacks will circumvent - to inetd, so + to &man.inetd.8;, so typically a combination of options must be used. Some standalone servers have self-fork-limitation parameters. @@ -681,7 +681,7 @@ reasonable MaxDaemonChildren to prevent cascade failures. - Syslogd can be attacked + &man.syslogd.8; can be attacked directly and it is strongly recommended to use whenever possible, and otherwise. @@ -722,10 +722,10 @@ with ICMP responses. This type of attack can crash the server by running it out of memory, especially if the server cannot drain the ICMP responses it generates fast enough. Use - the sysctl variable + the &man.sysctl.8; variable net.inet.icmp.icmplim to limit these attacks. The last major class of springboard attacks is - related to certain internal inetd + related to certain internal &man.inetd.8; services such as the UDP echo service. An attacker spoofs a UDP packet with a source address of server A's echo port and a destination address of server B's echo port, where @@ -744,7 +744,7 @@ parameters. A spoofed packet attack that uses a random source IP will cause the kernel to generate a temporary cached route in the route table, viewable with netstat -rna | - fgrep W3. These routes typically timeout in 1600 + fgrep W3. These routes typically timeout in 1600 seconds or so. If the kernel detects that the cached route table has gotten too big, it will dynamically reduce the rtexpire but will never decrease it to less @@ -774,15 +774,15 @@ - Access Issues with Kerberos and SSH + Access Issues with Kerberos and &man.ssh.1; - ssh + &man.ssh.1; There are a few issues with both Kerberos and &man.ssh.1; that need to be addressed if they are used. Kerberos is an excellent authentication - protocol, but there are bugs in the kerberized - &man.telnet.1; and &man.rlogin.1; applications that make them + protocol, but there are bugs in the kerberized versions of + &man.telnet.1; and &man.rlogin.1; that make them unsuitable for dealing with binary streams. By default, Kerberos does not encrypt a session unless is used whereas &man.ssh.1; @@ -801,13 +801,14 @@ It is recommended that &man.ssh.1; is used in combination with Kerberos whenever possible for staff - logins and &man.ssh.1; can be compiled with + logins and &man.ssh.1; can be compiled with Kerberos support. This reduces reliance on potentially - exposed ssh keys while protecting passwords via Kerberos. + exposed SSH keys while protecting + passwords via Kerberos. Keys should only be used for automated tasks from secure machines as this is something that Kerberos is unsuited to. It is recommended to either turn off key-forwarding in the - ssh configuration, or to make use + SSH configuration, or to make use of from=IP/DOMAIN in authorized_keys to make the key only usable to entities logging in from specific machines. @@ -971,7 +972,7 @@ Secure Connection Initialization To initialize OPIE for the first time, - execute opiepasswd: + execute &man.opiepasswd.1;: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c @@ -1173,7 +1174,7 @@ Enter secret pass phrase: < Initial Configuration To enable TCP Wrappers in &os;, ensure - the inetd server is started from + the &man.inetd.8; server is started from /etc/rc.conf with . Then, properly configure /etc/hosts.allow. @@ -1189,7 +1190,7 @@ Enter secret pass phrase: < are set to either be permitted or blocked depending on the options in /etc/hosts.allow. The default configuration in &os; is to allow a connection to every daemon - started with inetd. + started with &man.inetd.8;. Basic configuration usually takes the form of daemon : address : action, where @@ -1213,7 +1214,7 @@ Enter secret pass phrase: < # This line is required for POP3 connections: qpopper : ALL : allow - After adding this line, inetd + After adding this line, &man.inetd.8; needs to be restarted: &prompt.root; service inetd restart @@ -1575,7 +1576,7 @@ Verifying password - Password: KDC is functioning by obtaining and - listing a ticket for the principal (user) that you just + listing a ticket for the principal (user) that was just created from the command-line of the KDC itself: @@ -2134,31 +2135,31 @@ kadmind5_server_enable="YES"OpenSSL - One feature that many users overlook is the - OpenSSL toolkit included in &os;. - OpenSSL provides an encryption - transport layer on top of the normal communications layer; - thus allowing it to be intertwined with many network + The + OpenSSL toolkit is included in &os;. + It provides an encryption + transport layer on top of the normal communications layer, + allowing it to be intertwined with many network applications and services. Some uses of OpenSSL may - include encrypted authentication of mail clients, web based - transactions such as credit card payments and more. Many + include encrypted authentication of mail clients and web based + transactions such as credit card payments. Many ports such as www/apache22, and - mail/claws-mail will offer + mail/claws-mail offer compilation support for building with OpenSSL. - In most cases the Ports Collection will attempt to build + In most cases, the Ports Collection will attempt to build the security/openssl - port unless the WITH_OPENSSL_BASE make - variable is explicitly set to yes. + port unless WITH_OPENSSL_BASE + is explicitly set to yes. The version of OpenSSL included - in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3), + in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer Security v1 (TLSv1) network security protocols and can be used as a general cryptographic library. @@ -2168,7 +2169,7 @@ kadmind5_server_enable="YES"MAKE_IDEA variable must be set in - make.conf. + /etc/make.conf. One of the most common uses of @@ -2176,15 +2177,14 @@ kadmind5_server_enable="YES"Certificate - Authorities, or CAs, a warning is - usually produced. A Certificate Authority is a company, such + been verified by a Certificate + Authority (CA), a warning is + produced. A CA is a company, such as VeriSign, - which will sign certificates in order to validate credentials + signs certificates in order to validate the credentials of individuals or companies. This process has a cost - associated with it and is definitely not a requirement for - using certificates; however, it can put some of the more - paranoid users at ease. + associated with it and is not a requirement for + using certificates; however, it can put users at ease. Generating Certificates @@ -2226,22 +2226,23 @@ An optional company name []:< Notice the response directly after the Common Name prompt shows a domain name. This prompt requires a server name to be entered for verification - purposes; placing anything but a domain name would yield a - useless certificate. Other options, for instance expire - time, alternate encryption algorithms, etc. are available. - A complete list may be obtained by viewing the - &man.openssl.1; manual page. - - Two files should now exist in the directory in which the - aforementioned command was issued. The certificate request, - req.pem, may be sent to a certificate - authority who will validate the credentials that you - entered, sign the request and return the certificate to you. - The second file created will be named + purposes and placing anything but a domain name yields a + useless certificate. Other options, such as the expire + time and alternate encryption algorithms, are available. + A complete list of options is described in + &man.openssl.1;. + + Two files should now exist in the directory in which this + command was issued. The certificate request, + req.pem, may be sent to a + CA + who will validate the entered credentials, + sign the request, and return the signed certificate. + The second file is named cert.pem and is the private key for the - certificate and should be protected at all costs; if this + certificate and should be protected at all costs. If this falls in the hands of others it can be used to impersonate - you (or your server). + the user or the server. In cases where a signature from a CA is not required, a self signed certificate can be created. @@ -2263,30 +2264,31 @@ An optional company name []:< new.crt. These should be placed in a directory, preferably under /etc, which is readable - only by root. Permissions of 0700 should - be fine for this and they can be set with the - chmod utility. + only by root. Permissions of 0700 are + appropriate and can be set using + &man.chmod.1;. - Using Certificates, an Example + Using Certificates - So what can these files do? A good use would be to + One use for a certificate is to encrypt connections to the Sendmail MTA. - This would dissolve the use of clear text authentication for + This prevents the use of clear text authentication for users who send mail via the local MTA. - This is not the best use in the world as some - MUAs will present the user with an - error if they have not installed the certificate locally. + Some + MUAs will display + error if the user has not installed the certificate locally. Refer to the documentation included with the software for more information on certificate installation. - The following lines should be placed inside the local + To configure Sendmail, the + following lines should be placed in the local .mc file: dnl SSL Options @@ -2296,24 +2298,24 @@ define(`confSERVER_CERT',`/etc/certs/new define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl - Where /etc/certs/ - is the directory to be used for storing the certificate and - key files locally. The last few requirements are a rebuild - of the local .cf file. This is easily - achieved by typing make - install within the - /etc/mail directory. + In this example, /etc/certs/ + stores the certificate and + key files locally. After saving the edits, rebuild + the local .cf file by typing + make install + within /etc/mail. Follow that up with make restart which should start the Sendmail daemon. - If all went well there will be no error messages in the - /var/log/maillog file and + If all went well, there will be no error messages in + /var/log/maillog and Sendmail will show up in the process list. - For a simple test, simply connect to the mail server - using the &man.telnet.1; utility: + For a simple test, connect to the mail server + using &man.telnet.1;: &prompt.root; telnet example.com 25 Trying 192.0.34.166... @@ -2337,7 +2339,7 @@ Escape character is '^]'. Connection closed by foreign host. If the STARTTLS line appears in the - output then everything is working correctly. + output, everything is working correctly. @@ -2355,15 +2357,12 @@ Connection closed by foreign host. - VPN over IPsec + <acronym>VPN</acronym> over IPsec IPsec - Creating a VPN between two networks, separated by the - Internet, using FreeBSD gateways. - @@ -2380,18 +2379,19 @@ Connection closed by foreign host.Understanding IPsec - This section will guide you through the process of - setting up IPsec. In order to set up IPsec, it is necessary - that you are familiar with the concepts of building a custom + This section demonstrates the process of + setting up IPsec. It assumes + familiarity with the concepts of building a custom kernel (see ). IPsec is a protocol which sits on - top of the Internet Protocol (IP) layer. It allows two or - more hosts to communicate in a secure manner (hence the - name). The FreeBSD IPsec network stack is + top of the Internet Protocol (IP) layer. + It allows two or + more hosts to communicate in a secure manner. + The &os; IPsec network stack is based on the KAME - implementation, which has support for both protocol - families, IPv4 and IPv6. + implementation, which has support for both IPv4 and + IPv6. IPsec @@ -2408,16 +2408,18 @@ Connection closed by foreign host. Encapsulated Security Payload - ESP), protects the IP packet data from - third party interference, by encrypting the contents - using symmetric cryptography algorithms (like Blowfish, - 3DES). + ESP): this protocol + protects the IP packet data from + third party interference by encrypting the contents + using symmetric cryptography algorithms such as Blowfish + and 3DES. - Authentication Header (AH), + Authentication Header + (AH): this protocol protects the IP packet header from third party - interference and spoofing, by computing a cryptographic + interference and spoofing by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the @@ -2439,18 +2441,17 @@ Connection closed by foreign host. IPsec can either be used to directly encrypt the traffic - between two hosts (known as Transport - Mode); or to build virtual - tunnels between two subnets, which could be used for - secure communication between two corporate networks (known - as Tunnel Mode). The latter is more + between two hosts using Transport + Mode or to build virtual + tunnels using + Tunnel Mode. The latter mode is more commonly known as a Virtual Private Network - (VPN). The &man.ipsec.4; manual page should be - consulted for detailed information on the IPsec subsystem in - FreeBSD. + (VPN). Consult &man.ipsec.4; + for detailed information on the IPsec subsystem in + &os;. - To add IPsec support to your kernel, add the following - options to your kernel configuration file: + To add IPsec support to the kernel, add the following + options to the custom kernel configuration file: kernel options @@ -2474,40 +2475,30 @@ options IPSEC_DEBUG #debug for IP sec - The Problem - - There is no standard for what constitutes a VPN. VPNs - can be implemented using a number of different technologies, - each of which have their own strengths and weaknesses. This - section presents a scenario, and the strategies used for - implementing a VPN for this scenario. - - - - The Scenario: Two networks, one home based and one - corporate based. Both are connected to the Internet, and - expected, via this <acronym>VPN</acronym> to behave as - one. + <acronym>VPN</acronym> Between a Home and Corporate + Network VPN creating - The premise is as follows: + There is no standard for what constitutes a + VPN. VPNs can be + implemented using a number of different technologies, each + of which has their own strengths and weaknesses. This + section presents the strategies used for implementing a + VPN for the following scenario: - You have at least two sites - - - - Both sites are using IP internally + There are at least two sites where each site is using + IP internally. - Both sites are connected to the Internet, through a - gateway that is running FreeBSD. + Both sites are connected to the Internet through a + gateway that is running &os;. @@ -2517,15 +2508,15 @@ options IPSEC_DEBUG #debug for IP sec The internal addresses of the two networks can be - public or private IP addresses, it does not matter. - They just may not collide; e.g.: may not both use + either public or private IP addresses. However, the + address space must not collide. For example, both + networks cannot use 192.168.1.x. - - - + + Tom @@ -2536,23 +2527,24 @@ options IPSEC_DEBUG #debug for IP sec Written by - + Configuring IPsec on &os; - To begin, the + To begin, security/ipsec-tools - must be installed from the Ports Collection. This third - party software package provides a number of applications - which will help support the configuration. + must be installed from the Ports Collection. This + software provides a number of applications + which support the configuration. The next requirement is to create two &man.gif.4; pseudo-devices which will be used to tunnel packets and allow both networks to communicate properly. As root, run the following commands, - replacing the internal and - external items with the real - internal and external gateways: + replacing internal and + external with the real IP + addresses of the + internal and external interfaces of the two gateways: &prompt.root; ifconfig gif0 create @@ -2560,18 +2552,19 @@ options IPSEC_DEBUG #debug for IP sec &prompt.root; ifconfig gif0 tunnel external1 external2 - For example, the corporate LAN's - public IP is - 172.16.5.4 having a private - IP of + In this example, the corporate LAN's + external IP address is + 172.16.5.4 and its internal + IP address is 10.246.38.1. The home - LAN's public IP is - 192.168.1.12 with an internal - private IP of + LAN's external IP + address is + 192.168.1.12 and its internal + private IP address is 10.0.0.5. - This may seem confusing, so review the following example - output from the &man.ifconfig.8; command: + If this is confusing, review the following example output + from &man.ifconfig.8;: Gateway 1: @@ -2587,9 +2580,8 @@ tunnel inet 192.168.1.12 --> 172.16.5 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 - Once complete, both private IPs - should be reachable using the &man.ping.8; command like - the following output suggests: + Once complete, both internal IP + addresses should be reachable using &man.ping.8;: priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes @@ -2629,8 +2621,8 @@ round-trip min/avg/max/stddev = 28.106/9 At this point, internal machines should be reachable from each gateway as well as from machines behind the - gateways. This is easily determined from the following - example: + gateways. Again, use &man.ping.8; to + confirm: corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes @@ -2655,12 +2647,13 @@ PING 10.246.38.1 (10.246.38.107): 56 dat round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms Setting up the tunnels is the easy part. Configuring - a secure link is a much more in depth process. The + a secure link is a more in depth process. The following configuration uses pre-shared - (PSK) RSA keys. Aside - from the IP addresses, both - /usr/local/etc/racoon/racoon.conf files - will be identical and look similar to + (PSK) RSA keys. Other than + the IP addresses, the + /usr/local/etc/racoon/racoon.conf on + both gateways + will be identical and look similar to: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete @@ -2720,19 +2713,18 @@ sainfo (address 10.246.38.0/24 any addr compression_algorithm deflate; } - Explaining every available option, along with those - listed in these examples is beyond the scope of this - document. There is plenty of relevant information in the - racoon configuration manual - page. - - The SPD policies need to be - configured so &os; and racoon is - able to encrypt and decrypt network traffic between + For descriptions of each available option, refer to the + manual + page for racoon.conf. + + The Security Policy Database (SPD) + needs to be configured so that &os; and + racoon are + able to encrypt and decrypt network traffic between the hosts. - This task may be undertaken with a simple shell script - similar to the following which is on the corporate gateway. + This can be achieved with a shell script, + similar to the following, on the corporate gateway. This file will be used during system initialization and should be saved as /usr/local/etc/racoon/setkey.conf. @@ -2767,12 +2759,12 @@ Foreground mode. another console and use &man.tcpdump.1; to view network traffic using the following command. Replace em0 with the network interface card as - required. + required: &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Data similar to the following should appear on the - console. If not, there is an issue, and debugging the + console. If not, there is an issue and debugging the returned data will be required. 01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) @@ -2781,9 +2773,9 @@ Foreground mode. At this point, both networks should be available and seem to be part of the same network. Most likely both - networks are protected by a firewall, as they should be. To + networks are protected by a firewall. To allow traffic to flow between them, rules need to be added - to pass packets back and forth. For the &man.ipfw.8; + to pass packets. For the &man.ipfw.8; firewall, add the following lines to the firewall configuration file: @@ -2819,7 +2811,8 @@ pass out quick on gif0 from any to any - + + @@ -2844,65 +2837,63 @@ racoon_enable="yes" OpenSSH is a set of network connectivity tools used to access remote machines securely. - It can be used as a direct replacement for - rlogin, rsh, - rcp, and telnet. Additionally, TCP/IP connections can be tunneled/forwarded - securely through SSH. OpenSSH + securely through SSH connections. + OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. OpenSSH is maintained by the - OpenBSD project, and is based upon SSH v1.2.12 with all the - recent bug fixes and updates. It is compatible with both SSH - protocols 1 and 2. + OpenBSD project and is installed by default in &os;. It is + compatible with both SSH version + 1 and 2 protocols. - Advantages of Using OpenSSH - - Normally, when using &man.telnet.1; or &man.rlogin.1;, - data is sent over the network in a clear, un-encrypted form. - Network sniffers anywhere in between the client and server - can steal your user/password information or data transferred - in your session. OpenSSH offers + Advantages of Using + <application>OpenSSH</application> + + When + data is sent over the network in an unencrypted form, + network sniffers anywhere in between the client and server + can steal user/password information or data transferred + during the session. OpenSSH offers a variety of authentication and encryption methods to prevent this from happening. - Enabling <application>sshd</application> + Enabling &man.sshd.8; OpenSSH enabling - The sshd is an option - presented during a Standard install of - &os;. To see if sshd is enabled, - check the rc.conf file for: + To see if &man.sshd.8; is enabled, + check /etc/rc.conf for this line: sshd_enable="YES" - This will load &man.sshd.8;, the daemon program for - OpenSSH, the next time your + This will start &man.sshd.8;, the daemon program for + OpenSSH, the next time the system initializes. Alternatively, it is possible to use &man.service.8; to - start OpenSSH: + start OpenSSH now: &prompt.root; service sshd start - SSH Client + &man.ssh.1; Client OpenSSH client - The &man.ssh.1; utility works similarly to - &man.rlogin.1;. + To use &man.ssh.1; to connect to a system running + &man.sshd.8;, specify the username and host to log + into: &prompt.root; ssh user@example.com Host key not found from the list of known hosts. @@ -2910,22 +2901,19 @@ Are you sure you want to continue connec Host 'example.com' added to the list of known hosts. user@example.com's password: ******* - The login will continue just as it would have if a - session was created using rlogin or - telnet. SSH utilizes a key fingerprint - system for verifying the authenticity of the server when the - client connects. The user is prompted to enter - yes only when connecting for the first - time. Future attempts to login are all verified against the - saved fingerprint key. The SSH client will alert you if the + SSH utilizes a key fingerprint + system to verify the authenticity of the server when the + client connects. The user is prompted to type + yes when connecting for the first + time. Future attempts to login are verified against the + saved fingerprint key and the &man.ssh.1; client will display + an alert if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in - ~/.ssh/known_hosts, or - ~/.ssh/known_hosts2 for SSH v2 - fingerprints. + ~/.ssh/known_hosts. - By default, recent versions of the - OpenSSH servers only accept SSH + By default, recent versions of &man.sshd.8; only accept + SSH v2 connections. The client will use version 2 if possible and will fall back to version 1. The client can also be forced to use one or the other by passing it the @@ -2943,11 +2931,11 @@ user@example.com's password: secure copy - scp + &man.scp.1; - The &man.scp.1; command works similarly to &man.rcp.1;; - it copies a file to or from a remote machine, except in a + Use &man.scp.1; to + copy a file to or from a remote machine in a secure fashion. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT @@ -2961,10 +2949,12 @@ COPYRIGHT 100% |************* here. The arguments passed to &man.scp.1; are similar to - &man.cp.1;, with the file or files in the first argument, + &man.cp.1;, with the file or files to copy 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 + fetched over the network, through an SSH, + connection, one or more of the + file arguments takes the form . @@ -2978,24 +2968,20 @@ COPYRIGHT 100% |************* The system-wide configuration files for both the OpenSSH daemon and client reside - within the /etc/ssh - directory. + in /etc/ssh. ssh_config configures the client settings, while sshd_config configures - the daemon. - - Additionally, the - (/usr/sbin/sshd by default), and - rc.conf - options can provide more levels of configuration. + the daemon. Each file has its own manual page which describes + the available configuration options. - <application>ssh-keygen</application> + &man.ssh-keygen.1; Instead of using passwords, &man.ssh-keygen.1; can - be used to generate DSA or RSA keys to authenticate a + be used to generate DSA or + RSA keys to authenticate a user: &prompt.user; ssh-keygen -t dsa @@ -3014,7 +3000,7 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 in ~/.ssh/id_dsa or ~/.ssh/id_rsa, whereas the public key is stored in ~/.ssh/id_dsa.pub or - ~/.ssh/id_rsa.pub, respectively for + ~/.ssh/id_rsa.pub, respectively for the DSA and RSA key types. The public key must be placed in the ~/.ssh/authorized_keys file of the @@ -3022,43 +3008,42 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 DSA keys in order for the setup to work. - This will allow connection to the remote machine based - upon SSH keys instead of passwords. + This setup allows connections to the remote machine based + upon SSH keys instead of passwords. If a passphrase is used in &man.ssh-keygen.1;, the user - will be prompted for a password each time in order to use + will be prompted for the passphrase each time in order to use the private key. &man.ssh-agent.1; can alleviate the strain of repeatedly entering long passphrases, and is explored in - the section - below. + . The various options and files can be different according to the OpenSSH - version you have on your system; to avoid problems you - should consult the &man.ssh-keygen.1; manual page. + version. To avoid problems, + consult &man.ssh-keygen.1;. - <application>ssh-agent</application> and <application>ssh-add</application> + &man.ssh-agent.1; and &man.ssh-add.1; - The &man.ssh-agent.1; and &man.ssh-add.1; utilities - provide methods for SSH keys to - be loaded into memory for use, without needing to type the - passphrase each time. - - The &man.ssh-agent.1; utility will handle the - authentication using the private key(s) that are loaded into - it. &man.ssh-agent.1; should be used to launch another + To load SSH + keys into memory for use, without needing to type the + passphrase each time, use &man.ssh-agent.1; and + &man.ssh-add.1;. + + Authentication is handled by &man.ssh-agent.1;, using the + private key(s) that are loaded into + it. Then, &man.ssh-agent.1; should be used to launch another application. At the most basic level, it could spawn a - shell or at a more advanced level, a window manager. + shell or a window manager. - To use &man.ssh-agent.1; in a shell, first it will need - to be spawned with a shell as an argument. Secondly, the - identity needs to be added by running &man.ssh-add.1; and + To use &man.ssh-agent.1; in a shell, start it + with a shell as an argument. Next, add the identity + by running &man.ssh-add.1; and providing it the passphrase for the private key. Once these - steps have been completed the user will be able to + steps have been completed, the user will be able to &man.ssh.1; to any host that has the corresponding public key installed. For example: @@ -3068,24 +3053,28 @@ Enter passphrase for /home/user/.ssh/id_ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; - To use &man.ssh-agent.1; in X11, a call to - &man.ssh-agent.1; will need to be placed in - ~/.xinitrc. This will provide the - &man.ssh-agent.1; services to all programs launched in X11. + To use &man.ssh-agent.1; in + &xorg;, a call to + &man.ssh-agent.1; needs to be placed in + ~/.xinitrc. This provides the + &man.ssh-agent.1; services to all programs launched in + &xorg;. *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***