【Linux】《how linux work》第十章 网络应用和服务（1）

Chapter 10. Network Applications and Services（网络应用和服务）

This chapter explores basic network applications—the clients and servers running in user space that reside at the application layer. Because this layer is at the top of the stack, close to end users, you may find this material more accessible than the material in Chapter 9. Indeed, you interact with network client applications such as web browsers and email readers every day.

本章探讨基本的网络应用程序——在用户空间运行的客户端和服务器，这些客户端和服务器位于应用层。

因为这一层位于堆栈的顶部，靠近最终用户，所以您可能会发现这部分材料比第9章中的材料更易理解。

事实上，您每天都会与诸如网络浏览器和电子邮件阅读器之类的网络客户端应用程序进行交互。

To do their work, network clients connect to corresponding network servers. Unix network servers come in many forms. A server program can listen to a port on its own or through a secondary server. In addition, servers have no common configuration database and a wide variety of features. Most servers have a configuration file to control their behavior (though with no common format), and most use the operating system’s syslog service for message logging. We’ll look at some common servers as well as some tools that will help you understand and debug server operation.

为了完成其工作，网络客户端连接到相应的网络服务器。Unix网络服务器有许多形式。服务器程序可以通过自身或通过辅助服务器监听端口。

此外，服务器没有通用的配置数据库，具有各种各样的功能。

大多数服务器都有一个配置文件来控制其行为（尽管没有通用格式），并且大多数使用操作系统的syslog服务进行消息记录。

我们将研究一些常见的服务器以及一些工具，这些工具将帮助您理解和调试服务器的运行。

Network clients use the operating system’s transport layer protocols and interfaces, so understanding the basics of the TCP and UDP transport layers is important. Let’s start looking at network applications by experimenting with a network client that uses TCP.

网络客户端使用操作系统的传输层协议和接口，因此了解TCP和UDP传输层的基础知识非常重要。

让我们通过尝试使用TCP的网络客户端来开始研究网络应用程序。

10.1 The Basics of Services

TCP services are among the easiest to understand because they are built upon simple, uninterrupted two-way data streams. Perhaps the best way to see how they work is to talk directly to a web server on TCP port 80 to get an idea of how data moves across the connection. For example, run the following command to connect to a web server:

TCP服务是最容易理解的服务之一，因为它们建立在简单、不间断的双向数据流之上。

也许最好的方法是直接与 TCP 端口 80 上的 Web 服务器进行通信，以了解它们是如何工作的。

例如，运行以下命令连接到 Web 服务器：

$ telnet www.wikipedia.org 80

You should get a response like this:

你应该会得到如下响应：

Trying some address... 
Connected to www.wikipedia.org. 
Escape character is '^]'. 

Now enter

现在输入

GET / HTTP/1.0

Press ENTER twice. The server should send a bunch of HTML text as a response and then terminate the connection.

按两次 ENTER 键。服务器应该会发送一堆 HTML 文本作为响应，然后终止连接。

This exercise tells us that

这个练习告诉我们：

o the remote host has a web server process listening on TCP port 80; and

o telnet was the client that initiated the connection.

• 远程主机上有一个监听 TCP 端口 80 的 Web 服务器进程；以及
• telnet 是启动连接的客户端。

NOTE telnet is a program originally meant to enable logins to remote hosts. Although the non Kerberos telnet remote login server is completely insecure (as you will learn later), the telnet client can be useful for debugging remote services. telnet does not work with UDP or any transport layer other than TCP. If you’re looking for a general-purpose network client, consider netcat, described in 10.5.3 netcat.注意：telnet 是一个最初用于启用登录到远程主机的程序。尽管非 Kerberos telnet 远程登录服务器是完全不安全的（稍后你将了解），但 telnet 客户端可用于调试远程服务。telnet 不支持 UDP 或除 TCP 外的任何传输层。如果你正在寻找通用网络客户端，请考虑 netcat，详情请参见 10.5.3 netcat。10.1.1 A Closer Look

In the example above, you manually interacted with a web server on the network with telnet, using the Hypertext Transfer Protocol (HTTP) application layer protocol. Although you’d normally use a web browser to make this sort of connection, let’s take just one step up from telnet and use a command-line program that knows how to speak to the HTTP application layer. We’ll use the curl utility with a special option to record details about its communication:

在上面的示例中，您通过telnet手动与网络上的Web服务器进行了交互，使用了超文本传输协议（HTTP）应用层协议。

虽然通常您会使用Web浏览器来建立这种连接，但让我们从telnet再向上迈进一步，使用一个能够与HTTP应用层通信的命令行程序。

我们将使用curl实用程序，并加上一个特殊选项来记录其通信的详细信息：

$ curl --trace-ascii trace_file http://www.wikipedia.org/

NOTE Your distribution may not have the curl package preinstalled, but you should have no trouble installing it if necessary.注意：您的发行版可能没有预安装curl软件包，但如果需要安装它，您应该没有任何问题。

You’ll get a lot of HTML output. Ignore it (or redirect it to /dev/null) and instead look at the newly created file trace_file. Assuming that the connection was successful, the first part of the file should look something like the following, at the point where curl attempts to establish the TCP connection to the server:

您将获得大量HTML输出。请忽略它（或将其重定向到/dev/null），而是查看新创建的文件trace_file。

假设连接成功，文件的第一部分应该类似于以下内容，在curl尝试建立与服务器的TCP连接时：

== Info: About to connect() to www.wikipedia.org port 80 (#0) 
== Info:   Trying 10.80.154.224... == Info: connected

Everything you’ve seen so far happens in the transport layer or below. However, if this connection succeeds, curl tries to send the request (the “header”); this is where the application layer starts:

到目前为止，你所看到的一切都发生在传输层或以下。

然而，如果此连接成功，curl 尝试发送请求（即“头部”）；这是应用层开始的地方。

=> Send header, 167 bytes (0xa7) 
0000: GET / HTTP/1.1 
0010: User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS 
0050: SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 
007f: Host: www.wikipedia.org 
0098: Accept: */* 
00a5: 

The first line here is curl debugging output telling you what it will do next. The remaining lines show what curl sends to the server. The text in bold is what goes to the server; the hexadecimal numbers at the beginning are just debugging offsets from curl to help you keep track of how much data was sent or received.

这里的第一行是curl调试输出，告诉您接下来将要执行的操作。

其余行显示了curl发送到服务器的内容。

粗体文本是发送到服务器的内容；开头的十六进制数字只是curl的调试偏移量，帮助您跟踪发送或接收了多少数据。

You can see that curl starts by issuing a GET command to the server (as you did with telnet), followed by some extra information for the server and an empty line. Next, the server sends a reply, first with its own header, shown here in bold:

您可以看到，curl首先向服务器发出一个GET命令（就像您在telnet中所做的那样），然后是一些额外的信息和一个空行。

接下来，服务器发送了一个回复，首先是自己的头部，如下所示：

<= Recv header, 17 bytes (0x11) 
0000: HTTP/1.1 200 OK 
<= Recv header, 16 bytes (0x10) 
0000: Server: Apache 
<= Recv header, 42 bytes (0x2a) 
0000: X-Powered-By: PHP/5.3.10-1ubuntu3.9+wmf1 --snip--

Much like the previous output, the <= lines are debugging output, and 0000: precedes the lines of output to tell you offsets.

与之前的输出类似，<= 行是调试输出，0000：在输出行之前告诉您偏移量。

The header in the server’s reply can be fairly long, but at some point the server transitions from transmitting headers to sending the actual requested document, like this:

服务器回复中的标题可能相当长，但在某个时刻，服务器从传输标题转变为发送实际请求的文档，就像这样：

<= Recv header, 55 bytes (0x37) 
0000: X-Cache: cp1055 hit (16), cp1054 frontend hit (22384) 
<= Recv header, 2 bytes (0x2) 
0000: 
<= Recv data, 877 bytes (0x36d) 
0000: 008000 
0008: <!DOCTYPE html>.<html lang="mul" dir="ltr">.<head>.<!-- Sysops: --snip-- 

This output also illustrates an important property of the application layer. Even though the debugging output says Recv header and Recv data, implying that those are two different kinds of messages from the server, there’s no difference in the way that curl talked to the operating system to retrieve the two kinds of messages, nor any difference in how the operating system handled them, nor any difference in the way that the network handled the packets underneath. The difference is entirely within the user-space curl application itself. curl knew that until this point it had been getting headers, but when it received a blank line (the 2 byte chunk in the middle) signifying the end of headers in HTTP, it knew to interpret anything that followed as the requested document.

这个输出还展示了应用层的一个重要特性。

尽管调试输出中显示“接收头部”和“接收数据”，暗示这两种消息来自服务器，但在 curl 与操作系统交互以获取这两种消息的方式、操作系统处理它们的方式以及网络在底层处理数据包的方式上并没有任何区别。

区别完全在于用户空间中的 curl 应用程序本身。

curl 知道直到这一点它一直在接收头部，但当它收到一个空行（中间的 2 字节块）表示 HTTP 头部结束时，它就知道要将接下来的任何内容解释为请求的文档。

The same is true of the server sending this data. When sending the reply, the server didn’t differentiate between header and document data sent to the operating system; the distinctions happen inside the user-space server program.

发送这些数据的服务器也是如此。

在发送回复时，服务器没有区分发送到操作系统的头部数据和文档数据；区别发生在用户空间服务器程序内部。

10.2 Network Servers

Most network servers are like other server daemons on your system such as cron, except that they interact with network ports. In fact, recall syslogd discussed in Chapter 7; it accepts UDP packets on port 514 when started with the -r option.

大多数网络服务器与系统中的其他服务器守护进程（如cron）类似，只是它们与网络端口进行交互。

事实上，回想一下第7章讨论过的syslogd；当使用-r选项启动时，它会在514端口接受UDP数据包。

These are some other common network servers that you might find running on your system:

以下是一些你可能在系统上发现正在运行的常见网络服务器：

o httpd, apache, apache2 Web servers

o sshd Secure shell daemon (see 10.3 Secure Shell (SSH))

o postfix, qmail, sendmail Mail servers

o cupsd Print server

o nfsd, mountd Network filesystem (file-sharing) daemons

o smbd, nmbd Windows file-sharing daemons (see Chapter 12)

o rpcbind Remote procedure call (RPC) portmap service daemon

• httpd、apache、apache2 网页服务器
• sshd 安全外壳守护进程（参见10.3 安全外壳（SSH））
• postfix、qmail、sendmail 邮件服务器
• cupsd 打印服务器
• nfsd、mountd 网络文件系统（文件共享）守护进程
• smbd、nmbd Windows 文件共享守护进程（参见第12章）
• rpcbind 远程过程调用（RPC）端口映射服务守护进程

One feature common to most network servers is that they usually operate as multiple processes. At least one process listens on a network port, and when a new incoming connection is received, the listening process uses fork() to create a new child process, which is then responsible for the new connection. The child, often called a worker process, terminates when the connection is closed. Meanwhile, the original listening process continues to listen on the network port. This process allows a server to easily handle many connections without much trouble.

大多数网络服务器的一个共同特点是它们通常作为多个进程运行。

至少有一个进程在监听网络端口，当接收到新的传入连接时，监听进程使用fork()创建一个新的子进程，然后该子进程负责处理新连接。

子进程通常被称为工作进程，在连接关闭时终止。与此同时，原始的监听进程继续监听网络端口。

这个过程使得服务器能够轻松处理许多连接而不会出现太多问题。

There are some exceptions to this model, however. Calling fork() adds a significant amount of system overhead. In comparison, high-performance TCP servers such as the Apache web server can create a number of worker processes upon startup so that they are already there to handle connections as needed. Servers that accept UDP packets simply receive data and react to it; they don’t have connections to listen for.

然而，也有一些例外情况。调用fork()会增加大量系统开销。

相比之下，高性能的TCP服务器（如Apache Web服务器）可以在启动时创建多个工作进程，以便在需要时立即处理连接。

接受UDP数据包的服务器只需接收数据并对其做出反应；它们不需要监听连接。

10.3 Secure Shell (SSH)

Every server works a bit differently. Let’s take a close look at one—the standalone SSH server. One of the most common network service applications is the secure shell (SSH), the de facto standard for remote access to a Unix machine. When configured, SSH allows secure shell logins, remote program execution, simple file sharing, and more—replacing the old, insecure telnet and rlogin remote-access systems with public-key cryptography for authentication and simpler ciphers for session data. Most ISPs and cloud providers require SSH for shell access to their services, and many Linux-based network appliances (such as NAS devices) allow access via SSH as well. OpenSSH (http://www.openssh.com/) is a popular free SSH implementation for Unix, and nearly all Linux distributions come with it preinstalled. The OpenSSH client is ssh, and the server is sshd. There are two main SSH protocol versions: 1 and 2. OpenSSH supports both, but version 1 is rarely used.

每个服务器的工作方式都有所不同。让我们仔细看看其中一个——独立的SSH服务器。

安全外壳（SSH）是最常见的网络服务应用程序之一，也是远程访问Unix机器的事实标准。

配置好后，SSH允许安全外壳登录、远程程序执行、简单文件共享等功能，利用公钥加密进行身份验证以及简单密码算法处理会话数据，取代了旧的不安全的telnet和rlogin远程访问系统。

大多数互联网服务提供商和云服务提供商要求使用SSH来访问其服务的shell，许多基于Linux的网络设备（如NAS设备）也允许通过SSH访问。

OpenSSH（http://www.openssh.com/）是Unix上流行的免费SSH实现，几乎所有Linux发行版都预装了它。

OpenSSH客户端是ssh，服务器是sshd。SSH有两个主要协议版本：1和2。

OpenSSH支持两者，但很少使用第1版。

Among its many useful capabilities and features, SSH does the following:

在其许多有用功能和特性中，SSH可以实现以下功能：

o Encrypts your password and all other session data, protecting you from snoopers.

o Tunnels other network connections, including those from X Window System clients. You’ll learn more about X in Chapter 14.

o Offers clients for nearly any operating system.

o Uses keys for host authentication.

• 加密密码和所有其他会话数据，保护您免受窥探。
• 隧道化其他网络连接，包括来自X Window系统客户端的连接。您将在第14章中更多地了解关于X的内容。
• 为几乎任何操作系统提供客户端。
• 使用密钥进行主机身份验证。

NOTE Tunneling is the process of packaging and transporting one network connection using another one. The advantages of using SSH to tunnel X Window System connections are that SSH sets up the display environment for you and encrypts the X data inside the tunnel.注意：隧道是使用另一个网络连接打包和传输一个网络连接的过程。使用SSH进行X Window系统连接隧道化的优势在于SSH为您设置显示环境并在隧道内加密X数据。

SSH does have its disadvantages. For one, in order to set up an SSH connection, you need the remote host’s public key, and you don’t necessarily get it in a secure way (though you can check it manually to make sure you’re not being spoofed). For an overview of how several methods of cryptography work, get your hands on the book Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd edition, by Bruce Schneier (Wiley, 1996). Two in-depth books on SSH are SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys by Michael W. Lucas (Tilted Windmill Press, 2012) and SSH, The Secure Shell, 2nd edition, by Daniel J. Barrett, Richard E. Silverman, and Robert G. Byrnes(O’Reilly, 2005).

SSH也有其缺点。首先，在建立SSH连接时，您需要远程主机的公钥，并且不一定以安全的方式获取（尽管您可以手动检查以确保没有被欺骗）。

要了解几种加密方法的概述，请阅读

• Bruce Schneier的《应用密码学：C语言协议、算法和源代码》第2版（Wiley，1996）。

关于SSH的两本深入书籍是

• Michael W. Lucas的《SSH技巧：OpenSSH、PuTTY、隧道和密钥》（Tilted Windmill Press，2012）
• Daniel J. Barrett、Richard E. Silverman和Robert G. Byrnes的《SSH，安全外壳》第2版（O'Reilly，2005）。10.3.1 The SSHD Server

Running sshd requires a configuration file and host keys. Most distributions keep configurations in the /etc/ssh configuration directory and try to configure everything properly for you if you install their sshd package. (The configuration filename sshd_config is easy to confuse with the client’s ssh_config setup file, so be careful.)

运行sshd需要一个配置文件和主机密钥。

大多数发行版将配置保存在/etc/ssh配置目录中，并在您安装他们的sshd软件包时尝试为您正确配置一切。

（配置文件名sshd_config很容易与客户端的ssh_config设置文件混淆，所以请小心。）

You shouldn’t need to change anything in sshd_config, but it never hurts to check. The file consists of keyword-value pairs, as shown in this fragment:

您不应该需要更改sshd_config中的任何内容，但检查一下也无妨。该文件由关键字-值对组成，如下所示：

Port 22 
#Protocol 2,1 
#ListenAddress 0.0.0.0 
#ListenAddress :: 
HostKey /etc/ssh/ssh_host_key 
HostKey /etc/ssh/ssh_host_rsa_key 
HostKey /etc/ssh/ssh_host_dsa_key

Lines beginning with # are comments, and many comments in your sshd_config might indicate default values. The sshd_config(5) manual page contains descriptions of all possible values, but these are the most important ones:

以#开头的行是注释，在你的sshd_config中的许多注释可能表示默认值。

sshd_config(5)手册页面包含所有可能值的描述，但以下是最重要的几个：

o HostKey file Uses file as a host key. (Host keys are described shortly.)

o LogLevel level Logs messages with syslog level level.

o PermitRootLogin value Permits the superuser to log in with SSH if value is set to yes. Set

value to no to prevent this.

o SyslogFacility name Logs messages with syslog facility name.

o X11Forwarding value Enables X Window System client tunneling if value is set to yes.

o XAuthLocation path Provides a path for xauth. X11 tunneling will not work without this path. If

xauth isn’t in /usr/bin, set path to the full pathname for xauth.

• HostKey文件 使用文件作为主机密钥。（主机密钥将很快描述。）
• LogLevel级别 记录具有syslog级别级别的消息。
• PermitRootLogin值 如果值设置为yes，则允许超级用户使用SSH登录。将值设置为no可阻止此操作。
• SyslogFacility名称 记录具有syslog设施名称的消息。
• X11Forwarding值 如果值设置为yes，则启用X Window系统客户端隧道。
• XAuthLocation路径 提供xauth的路径。如果未设置此路径，X11隧道将无法工作。如果xauth不在/usr/bin中，请将路径设置为xauth的完整路径名。Host Keys（主机密钥）

OpenSSH has three host key sets: one for protocol version 1 and two for protocol 2. Each set has a public key (with a .pub file extension) and a private key (with no extension). Do not let anyone see your private key, even on your own system, because if someone obtains it, you’re at risk from intruders.

OpenSSH有三组主机密钥：一组用于协议版本1，另外两组用于协议2。

每组都有一个公钥（扩展名为.pub文件）和一个私钥（没有扩展名）。

即使在您自己的系统上，也不要让任何人看到您的私钥，因为如果有人获取了它，您就会受到入侵者的威胁。

SSH version 1 has RSA keys only, and SSH version 2 has RSA and DSA keys. RSA and DSA are public key cryptography algorithms. The key filenames are given in Table 10-1.

SSH版本1仅使用RSA密钥，而SSH版本2使用RSA和DSA密钥。RSA和DSA是公钥加密算法。密钥文件名如下表所示。

Table 10-1. OpenSSH Key Files

表10-1. OpenSSH密钥文件

image.png

image.png

Normally you won’t need to build the keys because the OpenSSH installation program or your distribution’s installation script will do it for you, but you do need to know how to create keys if you plan to use programs like ssh-agent. To create SSH protocol version 2 keys, use the ssh-keygen program that comes with OpenSSH:

通常情况下，您不需要自己生成密钥，因为OpenSSH安装程序或您发行版的安装脚本会为您完成这些操作，但是如果您计划使用ssh-agent等程序，您需要了解如何创建密钥。

要创建SSH协议版本2的密钥，请使用随OpenSSH一起提供的ssh-keygen程序。

# ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key 
# ssh-keygen -t dsa -N '' -f /etc/ssh/ssh_host_dsa_key 

For the version 1 keys, use

对于版本 1 密钥，使用

# ssh-keygen -t rsa1 -N '' -f /etc/ssh/ssh_host_key

The SSH server and clients also use a key file called ssh_known_hosts, which contains public keys from other hosts. If you intend to use host-based authentication, the server’s ssh_known_hosts file must contain the public host keys of all trusted clients. Knowing about the key files is handy if you’re replacing a machine. When installing a new machine from scratch, you can import the key files from the old machine to ensure that users don’t get key mismatches when connecting to the new one.

SSH服务器和客户端还使用一个名为ssh_known_hosts的密钥文件，其中包含其他主机的公钥。

如果您打算使用基于主机的身份验证，服务器的ssh_known_hosts文件必须包含所有受信任客户端的公共主机密钥。

了解关于密钥文件的信息对于更换计算机很有用。

当从头开始安装新计算机时，您可以从旧计算机导入密钥文件，以确保用户在连接到新计算机时不会出现密钥不匹配的情况。

Starting the SSH Server（启动SSH服务器）

Although most distributions ship with SSH, they usually don’t start the sshd server by default. On Ubuntu and Debian, installing the SSH server package creates the keys, starts the server, and adds the startup to the bootup configuration. On Fedora, sshd is installed by default but turned off. To start sshd at boot, use chkconfig like this (this won’t start the server immediately; use service sshd start for that):

虽然大多数发行版都预装了SSH，但它们通常不会默认启动sshd服务器。在Ubuntu和Debian上，安装SSH服务器包会创建密钥、启动服务器，并将启动配置添加到启动项中。

在Fedora上，默认安装了sshd，但是处于关闭状态。

要在启动时启动sshd，请使用chkconfig命令（这不会立即启动服务器；要立即启动服务器，请使用service sshd start命令）。

# chkconfig sshd on 

Fedora normally creates any missing host key files upon the first sshd startup.

Fedora通常会在第一次启动sshd时创建任何缺失的主机密钥文件。

If you don’t have any init support installed yet, running sshd as root starts the server, and upon startup, sshd writes its PID to /var/run/sshd.pid.

如果您尚未安装任何init支持，以root身份运行sshd将启动服务器，并在启动时将其PID写入/var/run/sshd.pid。

You can also start sshd as a socket unit in systemd or with inetd, but it’s usually not a good idea to do so because the server occasionally needs to generate key files, a process that can take a long time.

您也可以将sshd作为systemd中的套接字单元或使用inetd启动，但通常不建议这样做，因为服务器有时需要生成密钥文件，这个过程可能需要很长时间。

10.3.2 The SSH Client（SSH客户端）

To log in to a remote host, run

要登录到远程主机，请运行：

$ ssh remote_username@host

You may omit remote_username@ if your local username is the same as on host. You can also run pipelines to and from an ssh command as shown in the following example, which copies a directory dir to another host:

如果您的本地用户名与主机上的相同，则可以省略remote_username@。

您还可以像以下示例中所示运行到ssh命令的管道，该示例将一个目录dir复制到另一台主机：

$ tar zcvf - dir | ssh remote_host tar zxvf - 

The global SSH client configuration file ssh_config should be in /etc/ssh with your sshd_config file. As with the server configuration file, the client configuration file has key-value pairs, but you shouldn’t need to change them.

全局SSH客户端配置文件ssh_config应该位于/etc/ssh目录下，与您的sshd_config文件一起。

与服务器配置文件一样，客户端配置文件也有键值对，但您不应该需要更改它们。

The most frequent problem with using SSH clients occurs when an SSH public key in your local ssh_known_hosts or .ssh/known_hosts file does not match the key on the remote host. Bad keys cause errors or warnings like this:

使用SSH客户端时最常见的问题是，本地ssh_known_hosts或.ssh/known_hosts文件中的SSH公钥与远程主机上的密钥不匹配。

错误的密钥会导致如下错误或警告：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
@    
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     
@ 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! 
Someone could be eavesdropping on you right now (man-in-the-middle 
attack)! 
It is also possible that the RSA host key has just been changed. 
The fingerprint for the RSA key sent by the remote host is 
38:c2:f6:0d:0d:49:d4:05:55:68:54:2a:2f:83:06:11. 
Please contact your system administrator. 
Add correct host key in /home/user/.ssh/known_hosts to get rid of this 
message. 
Offending key in /home/user/.ssh/known_hosts:12➊ 
RSA host key for host has changed and you have requested 
strict checking. 
Host key verification failed.

This usually just means that the remote host’s administrator changed the keys (this often happens when replacing hardware), but it never hurts to check with the administrator if you’re not sure. In any case, the preceding message tells you that the bad key is in line 12 of a user’s known_hosts file, as shown at ➊.

这通常只是表示远程主机的管理员更改了密钥（通常在更换硬件时会发生），但如果不确定，最好还是与管理员确认一下。

无论如何，前面的消息告诉您，有问题的密钥位于用户 known_hosts 文件的第12行，如图所示。

If you don’t suspect foul play, just remove the offending line or replace it with the correct public key.

如果您不怀疑有恶意操作，只需删除有问题的行或将其替换为正确的公钥。

SSH File Transfer Clients（SSH 文件传输客户端）

OpenSSH includes the file transfer programs scp and sftp, which are intended as replacements for the older, insecure programs rcp and ftp.

OpenSSH 包括文件传输程序 scp 和 sftp，这两个程序旨在取代较老、不安全的 rcp 和 ftp 程序。

You can use scp to transfer files to or from a remote machine to your machine or from one host to another. It works like the cp command. Here are a few examples:

您可以使用 scp 将文件从远程计算机传输到您的计算机，或者在两台主机之间传输文件。

它的工作方式类似于 cp 命令。以下是一些示例：

$ scp user@host:file . 
$ scp file user@host:dir 
$ scp user1@host1:file user2@host2:dir

The sftp program works like the command-line ftp client, using get and put commands. The remote host must have an sftp-server program installed, which you can expect if the remote host also uses OpenSSH.

sftp 程序类似于命令行 ftp 客户端，使用 get 和 put 命令。

远程主机必须安装 sftp-server 程序，如果远程主机也使用 OpenSSH，您可以期望这个程序已安装。

NOTE If you need more features and flexibility than the offerings of scp and sftp (for example, if you’re transferring large numbers of files often), have a look at rsync, described in Chapter 12.注意：如果您需要比 scp 和 sftp 更多功能和灵活性的功能（例如，经常传输大量文件），请查看第 12 章中描述的 rsync。

SSH Clients for Non-Unix Platforms（非Unix平台的SSH客户端）

There are SSH clients for all popular operating systems, as listed on the OpenSSH web page (http://www.openssh.com/). Which one should you choose? PuTTY is a good, basic Windows client that includes a secure file-copy program. MacSSH works well for Mac OS 9.x and lower. Mac OS X is based on Unix and includes OpenSSH.

所有流行操作系统都有SSH客户端，可以在OpenSSH网页（http://www.openssh.com/）上找到相关信息。

你应该选择哪一个呢？ PuTTY是一个不错的基础Windows客户端，包含一个安全的文件传输程序。

MacSSH适用于Mac OS 9.x及更低版本。

Mac OS X基于Unix，并包含OpenSSH。

10.4 The inetd and xinetd Daemons（inetd 和 xinetd 守护进程）

Implementing standalone servers for every service can be somewhat inefficient. Each server must be separately configured to handle port listening, access control, and port configuration. These actions are performed in the same way for most services; only when a server accepts a connection is there any difference in the way communication is handled.

为每个服务实现独立的服务器可能有些低效。每个服务器必须单独配置以处理端口监听、访问控制和端口配置。

对于大多数服务，这些操作都是以相同的方式执行的；只有当服务器接受连接时，通信处理方式才有所不同。

One traditional way to simplify the use of servers is with the inetd daemon, a kind of superserver designed to standardize network port access and interfaces between server programs and network ports. After you start inetd, it reads its configuration file and then listens on the network ports defined in that file. As new network connections come in, inetd attaches a newly started process to the connection.

简化服务器使用的一种传统方式是使用 inetd 守护进程，这是一种超级服务器，旨在标准化网络端口访问和服务器程序与网络端口之间的接口。

启动 inetd 后，它会读取其配置文件，然后监听该文件中定义的网络端口。随着新的网络连接到来，inetd 会将一个新启动的进程附加到连接上。

A newer version of inetd called xinetd offers easier configuration and better access control, but xinetd itself is being phased out in favor of systemd, which can provide the same functionality through socket units, as described in 6.4.7 systemd On-Demand and Resource-Parallelized Startup.

一个名为 xinetd 的更新版本提供了更简单的配置和更好的访问控制，但 xinetd 本身正在被 systemd 取代，后者可以通过套接字单元提供相同的功能，如 6.4.7 systemd 按需和资源并行化启动中所述。

Although inetd is no longer commonly used, its configuration shows everything necessary to set up a service. As it turns out, sshd can also be invoked by inetd rather than as a standalone server, as shown in this /etc/ inetd.conf configuration file:

尽管 inetd 不再常用，但其配置显示了设置服务所需的一切。

事实证明，sshd 也可以由 inetd 而不是作为独立服务器调用，如下所示在这个 /etc/ inetd.conf 配置文件中：

ident stream tcp  nowait root /usr/sbin/sshd sshd -i

The seven fields here are, from left to right:

o Service name. The service name from /etc/services (see 9.14.3 Port Numbers and /etc/services).

o Socket type. This is usually stream for TCP and dgram for UDP.

o Protocol. The transport protocol, usually tcp or udp.

o Datagram server behavior. For UDP, this is wait or nowait. Services using any other transport

protocol should use nowait.

o User. The username to run the service. Add .group to set a group.

o Executable. The program that inetd should connect to the service.

o Arguments. The arguments for the executable. The first argument should be the name of the program.

这里的七个字段依次是：

o 服务名称。来自 /etc/services 的服务名称（参见 9.14.3 端口号和 /etc/services）。

o 套接字类型。通常为 TCP 的流式（stream），UDP 的数据报式（dgram）。

o 协议。传输协议，通常为 tcp 或 udp。

o 数据报服务器行为。对于 UDP，为 wait 或 nowait。使用其他传输协议的服务应该使用 nowait。

o 用户。运行服务的用户名。添加 .group 以设置一个用户组。

o 可执行文件。inetd 应该连接到的程序。

o 参数。可执行文件的参数。第一个参数应该是程序的名称。

10.4.1 TCP Wrappers: tcpd, /etc/hosts.allow, and /etc/hosts.deny（TCP包装：tcpd、/etc/hosts.allow和/etc/hosts.deny）

Before lower-level firewalls became popular, many administrators used the TCP wrapper library and daemon for host control over network services. In these implementations, inetd runs the tcpd program, which first looks at the incoming connection as well as the access control lists in the /etc/hosts.allow and /etc/hosts.deny files. The tcpd program logs the connection, and if it decides that the incoming connection is okay, it hands it to the final service program. (Although you may find a system that still uses the TCP wrapper system, we won’t cover it in detail because it has largely fallen into disuse.)

在较低级别的防火墙变得流行之前，许多管理员使用TCP包装库和守护程序来控制网络服务的主机。

在这些实现中，inetd运行tcpd程序，该程序首先查看传入连接以及/etc/hosts.allow和/etc/hosts.deny文件中的访问控制列表。

tcpd程序记录连接，如果确定传入连接正常，则将其移交给最终的服务程序。

（尽管您可能会发现仍在使用TCP包装系统的系统，但我们不会详细介绍，因为它已经大部分被废弃。）