安全Shell（SSH）加密技术

安全Shell（SSH）加密技术

17.1 安全SSH的工作原理

17.1.1 SSH的应用范围

1．基本概念

·对称密钥：加密和解密使用相同的密钥，它主要用于对数据的加密。常见的有DES，三重DES，IDEA等。

举 例:

相同

图17-1 对称密钥示例

问题：如何发送密钥？（在下一次传输中发送，或通过电话。）SSH中也用到了对称密钥，留意它的传送方式。

·私钥/公钥：加密时用公钥，解密时用私钥。其中公钥和私钥是基于某种算法生成的一对密钥。也可用于加密数据。反之，加密时用私钥，解密时用公钥，则可用作认证过程。其中，公钥要公布出去，私钥要保密。常见的算法有RSA、DSA等。

举 例：

图17-2 私钥/公钥示列

SSH中就用到了私钥/公钥认证过程，留意它的实现方式。

 IP欺骗：IP被别人盗用来和目的主机进行通信。其中包括实际的IP地址被盗用（局域网内）和IP包被伪装（广域网内）

 Dos(Deny of Service,拒绝服务)：通过不断地向目的主机请求服务，使目的主机忙于应答，从而达到阻塞目的主机网络,甚至使它崩溃。

2．传统网络服务的漏洞

•telnet/ftp:基于明文传输的协议，存在的危险有包被侦听，密码被截获，进而威协到主机的安全。

举例：通过sniffit侦听，得到用户名和密码；再以该用户名和密码登录主机，获取Password文件；最后用字典程序如John破译root密码。

 r命令：基于远程授权用户的一系列命令。它的提出是为 提高telnet的安全性，它通过主机名和IP地址进行认证。

危险：通过认证的用户可以不用密码进入你的系统。

举例：通过IP欺骗绕过认证（hosts.equiv,.rhosts）

3．SSH的应用范围

 SSH的特点：SSH在端到端建立起一条安全会话的通道，包括使用公有密钥加密法进行用户和主机认证，和使用对称密钥进行数据加密。

适用范围

防止包欺骗，IP/主机欺骗，密码截获，侦听，

举例：通过sniffit进行侦听，查看侦听到的文件。

·不适用的范围:侦听对特定端口的攻击，Dos攻击等。

17.1.2 SSH的认证和加密方式

1．SSH的体系结构

连接层

用户认证层

传输层

图17-3 SSH的体系结构

传输层:完成加密算法的协商,保证传输数据的致密性和完整性,在传送对称密钥的同时完成客户端对服务器端的认证。

用户认证层：位于传输层之上，它在传输层保证数据致密性和完整性的情况下完成服务器方对用户方的认证。

连接层：位于传输层和用户认证层之上，它负责连接通道的分配和管理。如端口转发时虚通道的分配。

2．SSH的工作模型(Client/Server)

·建立连接

图17-4 SSH进程处理连接的过程

·协商

• 服务器端认证用户

图17-5 服务器端认证用户

认证的过程如上图所示：客户端用自己的私钥将一段明文加密，并将自己的公钥附在密文后面传给服务器 端，服务器端用公钥解密，如果成功，再将公钥送往公钥数据库或认证中心进行身份认证。

·客户端对服务器端进行认证和对称密钥传送过程如下：

(1)客户端随机生成校验字节

(2)将校验字节发送给服务器（可加密）

(3)服务器依据一定算法从校验字节中抽取对称密钥

(4)服务器将校验字节用私钥加密附在公钥上传回客户端

(5)客户端解密后认证校验字是否为原始发送的校验字

6)从校验字中抽取会话密钥。

·用对称密钥（会话密钥）加密传输数据

·断开连接

3．SSH的数据完整性

·SSH包格式

校

验字节=摘要函数（数据，顺序号，会话密钥）

如果发送方和接收方校验字节相同，说明数据未被改动。

图17-6 SSH包格式

17.1.3 SSH的密钥管理

SSH中使用的密钥主要有两种：主机密钥和用户密钥。其中它们各自又分别包含一对公钥/私钥。

主机密钥包含在如下文件中：

/etc/ssh2/hostkey 私钥

/etc/ssh2/hostkey.pub 公钥 （SSH2）

/etc/ssh2/random_seed 随机种子

/etc/ssh_host_key

/etc/ssh_host_key.pub (SSH1)

/etc/ssh_random_seed

注意：私钥的权限

和用户密钥有关的文件：

~/.ssh2/id_dsa1024_a 用户私钥

~/.ssh2/id_dsa1024_a.pub 用户公钥 （SSH2）

~/.ssh2/random_seed

~/.ssh/identity

~/.ssh/identity.pub （SSH1）

~/.ssh/random_seed

和密钥管理有关的文件包括：

~/.ssh2/hostkeys 包括该用户信任的主机公钥；

~/.ssh2/authorization 包括该用户信任的用户公钥； (SSH2)

~/.ssh2/identification 包括该用户使用的用户私钥；

• 密钥的生成

• 公钥的发布

当连接一台新的信任主机时,公钥会自动在两台机器间交换;或通过ssh-keyscan来扫描可用的公钥;

举例: ssh-keygen的使用

17.2 SSH的安装和使用

17.2.1 SSH的安装

1．版本的选择

SSH1和SSH2基于不同的协议。SSH1基于SSH.1.2.26 协议；SSH2基于SSH2.0.0协议，因此二者并不兼容。所以在选择版本时，要注意，你所连接或想要连接你的系统有什么版本你就应当选什么版本。

2．系统需求

系统需求：400-500KB 空间，gcc在2.7.2.3版本以上，每创建一个SSH进程就消耗200K内存。

获取站点：ftp://ftp.cs.hut.fi/pub/ssh或http://www.cs.hut.fi/pub/ssh

2.安装演示

17.2.2 服务器端SSHD的使用和配置

一、安全Shell守护程序的使用

现在你对安全shell守护程序是如何工作已经有了一定理解，了解守护程序的选项是件同样重要的事情。和大多数UNIX网络守护程序一样，你可以设置调试模式，改变密钥文件的位置，设置详尽性级别。你也可以改变密钥的大小及守护程序侦听的端口号。

这些选项是：

-b bits #可以指定服务器密钥的比特数。隐含值为768bit，然而可以使它变得更大或更小，这取决于你是否从inetd启动守护或是否需要更强的安全性。

-d #调试模式。这和sshd1一样。安全shell守护被启动，但它并没有在后台运行也没有产生任何子进程。调试级别越高，你接受到的信息也越多。调试输出结果存放于系统的日志文件，而警报机制则将被关闭。该模式仅能被用于服务器的调试，而不是为了增加日志文件的长度。

-f config-file #与sshd1一样，你可以指定一个特定的配置文件。隐含值为/etc/ssh2/sshd-lonfig，但如果你不是以超级用户的权限来运行安全shell，你就需要在其他地方定义这个文件。

-g login_grale_time #与sshd1一样，它设置安全shell守护中的“警报”机制。它给客户程序一个确定的时间，每到相应的时间间隔，客户将和服务器确认一次。隐含的时间为600秒（10分钟）。如果客户程序不确认，服务器进程将断开socket连接。你可以将它设置为0，这意味着对确认时间没有限制。如果你将安全守护设为调试模式，该选项将自动地设为零。

-h host_key_file #与sshd1一样，它指定用于私有主机密钥的文件。如果你不是以超级用户的身份运行安全shell守护，你就必须使用该选项。正常情况下，私有的主机密钥文件是不可读的（超级用户除外）。但如果你以普通的用户身份运行安全shell守护，情况就不一样了。同样，如果你使用了替换文件，确信其权限已被设为400。

-i #你可以指定是否从inetd运行安全shell。与SSH1类似，你可以选择是否需要用TCP外包来运行安全shell守护程序或从inetd运行它。从inetd运行安全shell会带来一些问题，因为安全shell守护需要产生服务器客户，然后响应客户，而这将会产生潜在的问题。当服务器密钥重新产生时，客户程序为了得到一个正常长度或更为强壮的服务器密钥而不得不等待过长的时间。然而，你也可以使用一个小一点的服务器密钥以提高性能，不过要记住：密钥越小，系统越容易受到攻击。

-o option #你可以指定用在配置文件中的选项，但命令行中的选项不能在这儿被指定。

-p port #与sshd1类似。你可以指定服务器侦听socket的端口。隐含值为端口22，它为安全shell所保留。记住这也是在/etc/services中定义的端口号，除非你已经改变了它。如果端口22已经被其他的应用程序使用或以非超级用户身份启动安全shell你可能希望定义一个替代的端口。

-q #指定哑模式，这意味着系统日志接受不到任何信息。这同样与sshd1类似。通常情况下被发送的内容为连接的起始，用户的认证及连接的终止。除非你的系统日志总是很快就被填满，你最好不要打开这种模式。因为这样你可以检查是否有人非法地进入系统。

-v #将安全shell守护置于详尽模式。这和将选项-d2给sshd效果是一样的。这同样意味着你不可能真正使sshd2的详尽模式运行，因为没有产生任何子进程。

注：sshd2中没有-k key_generation_time选项。服务器密钥每小时重新产生一次。

（1）在同一台主机上运行SSH1和SSH2守护程序

出于兼容性的考虑，你可能想让系统与SSH1兼容。要做到这一点，你需要具备SSH1的最新版本（目前为1.2.27）以及SSH2的一份拷贝。必须同时运行两种守护程序从而能接受和发送这两种版本的安全shell客户的连接请求。如果没有这样做，你就不能发送或接受安全shell客户的连接请求。

至于真正的兼容性，SSH1与SSH2之间并不存在。然而，你可以同时使用SSH1的最新版本与SSH2。如果连接请求来自SSH1客户，SSH2守护将会把连接转寄到SSH1守护。但你不能连接SSH1客户与SSH2服务器，反之亦然。

同样，如果你发现一个声称包长度有误的信息，检查一下，看看是否运行了一个SSH1的早期版本，要是这样，你就需要升级了。

（2）一些例子

这些选项并没有隐含地设置。安全shell守护的隐含设置是使用768-bit的服务器密钥，它每小时重新产生一次，认证超时限度则为10分钟，在端口22上侦听连接，在/etc/ssh2目录下寻找配置文件等。隐含情况下，安全shell守护以如下方式运行：

# sshd

下面的例子与第三章类似。你可以发现，在使用方法上它们仅有很小的差别。

你也可以将这些选项赋上隐含值，这和隐含地执行命令有同样的效果。

# sshd –b 768 –f /etc/ssh2/sshd_config –g 600 –h /etc/ssh2/ssh_host_key –p 22

你可以将安全shell的端口设置成高于1024：

# sshd –p 2022

为不同的端口建不同的配置文件？没问题

# sshd –p 2022 –f /etc/sshd_config_weird_port

如果想通过inetd运行安全shell，你也可以做到这一点，不过别忘了将服务器密钥缩小一点。记住，你并不希望自己的密钥非常脆弱。同样，你也可能希望不是从命令行来完成该命令，而是在一个程序脚本上实现这一点：

# sshd –i –b 512

注：你应当编辑文件/etc/inetd.conf，然后从中运行sshd。

（3）从启动脚本中初始化安全shell

运行安全shell的大多数的系统管理员希望它总是处于运行状态，并且也不希望每次都要启动它，就能使其运行。解决这个问题的一个简单的办法就是将其置于一个启动程序脚本中。这和第三章“安全shell守护程序—sshd”中描述过的SSH1启动过程十分类似。表17-1显示了不同的操作系统中启动安全shell守护的位置。

表17-1 启动安全shell程序脚本位置

操作系统	启动程序脚本
Slackware Linux	/etc/rc.d
Red Hat Linux	/etc/rc*.d
Solaris	/sbin/rc*.d
HP-UX	/sbin/rc*.d
Irix	/etc/rc*.d
AIX	/etc
DEC UNIX	/sbin/rc*.d

在Linux系统安装过程中，程序脚本也自动地被安装了进来。如果发现你需要编辑程序脚本并希望能增加对安全shell的启动，你可以将下列的程序脚本添加进来。

我的Unix系统是Slackware Linux系统，网络初始化程序脚本为/etc/rc.d/inet2，在这个脚本中，你将发现安全shell已经被启动了。如果你希望做到这一点，可以编辑启动程序脚本以正确的路径将安全shell守护增加进去，并设置你所需要的选项。

注：如果你在第3章已经看到了启动SSH1守护的程序脚本，就会发现它们是同一个程序脚本。这是因为即使你同时安装了sshd1和sshd2，符号连接总是指向最新的版本。

（4）记录你的连接

安全shell守护程序在隐含的情况下，记录初始的连接请求，认证及连接终止。既然代码是自由的，你会被欢迎来编辑并记录更多的信息。这来自Slackware Linux的日志文件/var/adm/message。当连接被建立以后，你的日志文件看上去像下面的内容：

你也可以打开详尽日志或使用哑选项关闭记录。

你同样可以用-D PARANOID选项使用TCP外包程序来记录每一个socket。这有可能会复制安全shell守护程序的一些工作，也可以通过配置，使其能提供更为详尽的信息。

记住你的记录存放位置与操作系统有关。Linux将信息存放于系统日志中，一般位于/var/adm/syslog，HP-UX或AIX则有可能将信息存放于完全不同的地方。查阅你的操作系统使用手册以寻找记录文件的位置。

（5）配置安全Shell

安全shell有一个你可以定义选项的配置文件。有一些选项是不能在命令行中被设置的，但可以在配置文件中设置它们以使其工作。与大多数配置文件和shell程序脚本一样，空行和以“#”开头的行不会被系统读入。安全shell的隐含配置文件是/etc/sshd2/sshd_config。

下面列出了你可以在sshd_config配置文件中为安全shell设置的选项。在/etc/sshd2/sshd_config文件中，定义这些选项的格式如下：

OptionType Argument

如果你有多个参数，用空白行隔开它们。这种格式对下面列出的选项都通用。

1. 允许的用户名与主机名

可以通过安全shell2过滤用户名与主机名。这没有提供与SSH1一样多的过滤选项，但有一些还是很有用的，例如忽视rhosts文件和允许或禁止超级用户登录的权力。

• IgnoreRhosts #这是一个与sshd1同样的配置选项。它定义了.rhosts和.shosts是否被允许用来认证。该选项对系统端的文件/etc/hosts.equiv和/etc/shosts.equiv没有影响。选项的隐含值是“no”。如果你想使用的话，用.shosts来代替.rhosts从而提高安全性能。

使用方法：

IgnoreRhosts yes

• PermitRootLogin 你可以定义超级用户是否可以通过ssh2登录进来。隐含值是“yes”，但你可以将其关闭。记住这对超级用户经过FTP telnet或其他方式登录进来并没有影响。

使用方法：

PermitRootLogin nopwd

2. 认证选项

安全shell提供了不同的认证方法：口令、.rhosts和公共密钥。你既可以使用其中一种，也可以使用它们的组合以通过安全shell进入帐户。记住，rhost认证是最脆弱的认证系统，而和公共密钥的组合则会成为最强有力的认证形式。SSH2没有为TIS或dkerberos认证提供选项，至少在本书出版时尚未出现。

PasswordGuesses #该选项指定用户正确地键入口令前最多登录企图，以进行口令认证。这个数字必须是一个整数，设置值越高，其他人窃取口令的可能性也就越大，如果你仅允许口令认证的话。

使用方法：

Password Guesses 4

• PasswordAuthentication #可以通过该选项决定是否利用口令以经过安全shell进入帐户。它和sshd1配置选项一样。隐含值为“yes”，口令被用来保护公共密钥而不是帐户自身。你可能选择关闭口令认证，但是最好在使用PubKeyAuthentication时使用。

使用方法：

PasswordAuthentication yes

• PermitEmptyPasswords #这个选项决定你是否想使用口令来帮助认证。它和sshd1的配置选项一样。可以允许空口令，然而，我们建议你最好不要这样做。如果某人进入你的主机，最起码还需要提供口令以进入系统。隐含值为“yes”。通常情况下应将它们设为“no”。

使用方法：

PermitEmptyPasswords no

• RHostsAuthentication #该选项设置基于.rhosts或/etc/hosts.equiv的权限。它与sshd1配置文件中的选项RhostsAuthentication选项一致。这并不需要口令或公共密钥，但它使你的系统对伯克利服务攻击和其他迫使你必须使用安全shell的安全漏洞开放。隐含值是“no”，最好就保留这个值。如果你想使用Rhosts认证，就让它和RHostsPubKey -Authentication中的公共密钥认证结合起来使用。

使用方法：

RHostsAuthentication no

• RHostsPubKeyAuthentication #在安全shell2的最新版本中并没有安装这个选项。它设置基于.rhosts或/etc/hosts.equiv的公共密钥认证，与sshd1的配置文件RhostsRSA Authentication配置选项一致。认证不需要口令，但要求在远程端有DSA或RSA密钥认证。它同样使你的系统暴露于伯克利服务攻击，但公共密钥认证使危险性被最大限度地降低了。如果你让该选项取值“yes”（这也是隐含值），你就有必要为主机设置更为严格的登录要求。再说一句，如果你希望保持系统的安全，关闭任何类型的rhosts认证。

使用方法：

RHostsPubKeyAuthentication no

• PubKeyAuthentication #可以使用任意多种类型的认证，或正如所见，也可以单独使用一种类型的认证。比如说你就可以仅允许公共密钥认证工作。这和sshd1的RSAAuthentication选项一致。它并不需要rhosts或口令来协助认证。隐含值为“yes”，你最好将选项保持在该状态。

使用方法：

PubKeyAuthentication yes

3．服务器选项

这些选项用来定义安全shell守护的功能，包括TCP转寄，对特殊地址与端口的侦听，发送存活信息及服务器密钥的设置等。

• Ciphers #可以指定准备用来加密的算法。目前系统支持的算法有DES，3DES，Blowfish, Twofish, IDEA和Arcfour。不可以为该选项指定其他的值：any,anystd和anycipher, 在你调试和测试时，将选项置为none。

使用方法：

Ciphers anycipher

• Ssh1Compatibility #这个选项用来确定是否与SSH1守护相兼容。如果客户仅仅支持SSH1，这个选项将执行SSH1守护。这在还有SSH1客户连接到你的服务器时当然很好！记住，要使这个选项工作，必须同时安装SSH1和SSH2选项可取值“yes”和“no”，取决于你是否需要后台的兼容性。

使用方法：

Ssh1Compatibility yes

• Sshd1Path #如果你准备与SSH1兼容，就需要指定SSH1路径，尤其是当你将sshd1安装在一个非公共目录下时。

使用方法：

Sshd1Path /usr/local/security/sbin/sshd1

• ForwardAgent #这个选项确定你是否能将安全shell认证代理（ssh-agent2）转寄到远程主机上。你既可以打开又可以关闭这个选项。

使用方法：

ForwardAgent yes

• KeepAlive #安全shell守护能通过设置来决定是否发生存活（Keepalive）信息。存活信息能让远程的服务器知道连接是否已经中断，并在确定连接中断的情况下杀掉活动进程。这和sshd1的配置文件中选项一致。当然，如果程序只是暂时地挂起，它会发出如下的令人沮丧的信息：

Connection down：disconnecting

这当然是令人厌烦的信息。但如果你不发送存活信息，会留下一些能够消耗掉资源的幽灵一般的程序。如果你要关闭存活信息发送选项，必须同时修改服务器端与客户端的配置文件。

使用方法：

KeepAlive yes

• ListenAddress #如果你正在运行一个多地址主机，可以指定你希望服务器侦听的地址。这和sshd1配置文件中的选项一致。如果你没有多个主IP接口的话，隐含值是你的主IP接口。

使用方法：

ListenAddress 1.2.3.4

• Port #可以通过该选项指定一个安全shell守护侦听的端口，隐含值为22。但在端口22已经被使用的情况下你可能会指定一个其他的端口。这和sshd1的配置选项一致，与-p选项也一样。

使用方法：

Port 21

• StrictModes #可以使服务器在建立登录连接之前检查用户主目录的文件模式和属主。这与sshd1所拥有的选项一致，这是一个很好的选项，因为用户可能会意外地将目录与文件的选项置为可写。如果的确是这样，一定要将它们改正过来。隐含设置为“yes”。

使用方法：

StrictModes yes

• ForwardX11 #这个选项确定是否允许X转寄通过安全shell守护。这和sshd1的X11Forwarding选项一致。与其它的TCP传输一样，这个选项在用户指定转寄时会被覆盖掉。这取决于你是否允许X传输通过。然而，如果你打算让X传输能传送到远端，最好让它们转寄到安全shell。隐含设置为“yes”。

使用方法：

ForwardX11 yes

4.文件位置选项：

这些选项定义安全shell守护密钥文件的存放位置。这包括密钥文件，进程标识文件等。

4. • AuthorizationFile #这个选项指定用户授权文件的名字。隐含值为~/.ssh2/authorization,它提供了一个安全shell服务器识别用户的私有密钥列表。

使用方法：

HostKey $ HOME/.ssh2/ssh2_identity

4. • HostKeyFile #这个选项指定用来做私有主机密钥的文件，与sshd1的Host Key选项一致。如果你不是以超级用户的身份运行安全shell守护，你必须使用这个文件。正常情况下，除了对超级用户主机密钥文件是不可读的。隐含值为/etc/ssh2/hostkey。如果你使用了一个替代文件，一定要将其属性设为400，这与-h选项一样。

使用方法：

Hostkey /usr/local/etc/ssh2_host_key

·PublicHostKeyFile 与HostKeyFile选项类似，该选项指定用来做公有主机密钥。

使用方法：

HostKey /usr/local/etc/ssh2_host_key.pub

4. • RandomSeedFile #该选项用来定义产生服务器密钥的随机生成文件。它和sshd1配置选项RandomSeed一致。隐含的文件位置为：/etc/ssh2/random_seed.

使用方法：

RandomSeed /usr/local/etc/ssh2_random_seed

5.帐户活动选项

这个选项定义经过安全shell登录到远程帐号时，影响帐号环境变量的那些设置。绝大部分设置发生于登录时使用的.profile或.cshrc之类的设置。但你也可以在安全shell守护配置文件中设置它们并使其发生作用。

5. • LoginGraceTime #该选项设置安全shell守护中的“警报”机制，与sshd1的配置选项效果相同。它给安全客户规定一个特定的时间，每经过该单位时间，安全客户将与服务器认证一次。隐含时间为600秒。如果安全客户不进行认证，服务进程将断开与socket的连接。可以将这个选项设为零，这将意味着对认证时间没有限制。如果你将安全shell置于调试模式，该选项将被自动地置为零，可以发现，它的效果与-g选项类似。

使用方法：

LoginGraceTime 660

5. • PrintMotd #该选项决定用户帐号是否打印出存放于/etc/inetd中的系统每日信息。这与sshd1中的同名选项类似，仅应用于以交互方式登录时（不是以scp与ssh后随命令的方式）。选项的隐含值为“yes”。它可以在用户的环境初始化文件中设置。

使用方法：

PrintMotd no

6．登录选项

这些选项能够影响被送往日志文件的信息。既可以增加这些登录信息，但这会损害用户的隐私权，当然你也可以关闭它们，其结果是仅有极少的错误信息会被记录。

5. • Quiet Mode #该选项设置哑模式，这意味着将不会有任何信息被送往系统日志文件。它与sshd1的同名选项类似。通常情况下被发送的内容是：连接起始标志，用户的认证和连接终止标志。除非你的日志文件总是很快就被填满，否则最好不要打开这个选项。定期审查登录的踪迹是一个好习惯，这样可以查看是否有人非法进入到你的系统。该选项与“-q”选项类似，隐含值为“no”。

使用方法：

QuietMode no

5. • Verbose Mode #在该模式下，sshd2将会打印出第2层的调试信息。记住在打开该模式的情况下sshd2守护程序将不会复制产生子进程。该选项与“-v”选项类似。

使用方法：

VerboseMode no

二、安全文件传输服务器-sftp-server

尽管体现了安全shell 2的一些新的特征，安全文件传输服务器并没有被很好地用文档加以说明。安全文件传输服务器由安全shell 2守护来运行，后者侦听端口22。从某种意义上说，它的工作机理和scp非常相像。它使用非安全应用程序（rcp或ftp）的代码，连接也通过端口22被转寄。因为更像一个客户程序。而非服务器程序，安全FTP将会在“安全shell 2客户—ssh2, scp2和sftp2”中加以描述。

17.2.3 客户程序SSH.SCP的使用和配置

一、安全shell客户程序的使用

1．ssh2的使用

安全shell客户程序，ssh2和scp2在命令选项上说明不同的语法规则。ssh2客户程序具有更多的选项，这是因为具有比单纯拷贝文件更多的功能。并由于scp2使用ssh2作为运输工具，ssh2客户程序也需要为scp提供一些功能。

为了所有这些意图和目标，ssh2具有很简单的语法：

$ ssh2 [选项] 主机名 [命令]

注意：不必键入ssh2或scp2来运行任何一个安全shell2客户程序。在安装了ssh2应用程序之后，ssh和scp的符号连接会分别连接到ssh2和scp2。如果安装有ssh1和ssh2客户程序。你将需要运行ssh1和scp1来运行ssh1客户程序。

（1）命令行选项

ssh2的命令行选项比ssh1命令行选项更丰富。你将发现ssh2有一些更多可供使用的功能，这包括允许认证代理，不允许压缩，设置调试等级和允许X转寄。

注意：ssh2不存在-k Kerberos标签和-y远程端选项。

-a #该选项让你能够关闭对认证代理的转寄。这一点和ssh1客户相同。它阻止了加载到内存中的口令（passphrase）被用于安全Shell客户的发行。如果需要，你可以在每个主机的配置文件里指定该功能而不是在全局定义这种功能。

+a #该选项允许认证代理进行转寄，这是缺省选项。

-c cipher #这和在ssh中定义的选项相同，这是因为它被直接传送给ssh。这也和scp1使用的选项相同。你可以选择你想要的对称钥匙密码来加密网络传输。这不影响使用DSA或RSA公共密钥的认证。所选择的密码有IDEA，DES，3DES，Blowfish和Twofish。你也可以选择“none”，但该选择关闭加密从而使安全Shell客户变得不安全。该“none”选项可以只用来调试和测试所要的目标，而不在实际中使用。最好的选择是使用3DES，IDEA或Blowfish。Blowfish和Twofish是ssh2支持的最快的算法。为了获得最高的安全性，使用IDEA。如果IDEA不同时被两台安全shell服务器支持，则使用3DES。

+C #压缩通过安全shell客户发送的所有数据，这包括输入、输出、错误信息和转寄的数据。这和ssh的-c选项相同。不要把它们混淆。这使用gzip算法，并且压缩级别可以通过配置文件的CompressionLevel选项定义。这种压缩对速度慢的网络很有效，例如modem，但在速度已经很快的网络上帮助不大。使用配置文件也可以允许为基于单个主机配置该选项。

-C #该选项关闭压缩。请注意这和ssh1的选项作用是相反的。这也是ssh2的缺省选项。

-d debug_level #这打印出所要的第几级的调试信息。数字越大，所得到的信息越多。该数字从0到99。记住-v选项打印出第三级的调试信息。

-e escape_character #这定义转义字符。缺符为“n”。但可以设置为任何字符成控制字符。这也和ssh的选项相同。

你也可以定义为“none”，这使用会话透明，但你可能想在连接悬挂起来时让它作为缺省值。为了能使用转义字符。键入转义字符，随后键入字点号，这就终止连接。如果你键入转义字符，随后键入control+z，则把连接暂时挂起。

-f #把ssh连接发送到后台。这和ssh1的选项相同。在认证完成并且TCP/IP转寄建立之后发生。在远程主机上启动X程序是不简单的。用户被提示输入口令（假设认证代理没有运行），接着连接被发送到后台。

-F configuration_file # 该选项指定使用哪个用户配置文件。缺省的配置文件为~/.ssh2/ssh2_config。然而，你可以拥有自己的缺省配置文件和其它的配置文件。首先读入可选的文件，然后再加入缺省文件选项。

-h #打印帮助命令摘要，然后退出。这不运行ssh2客户程序。

-i identity_file #该选项定义DSA私人密钥，或认证所要读取的身份文件，这和ssh2里的相同选项功能相似。缺省文件为$HOME/.ssh2/id_dsa1024_a。可以为不同主机定义多个文件。如果你的确定义了不同文件，可能想为每台主机分别命名这些文件（例如，id_dsa1024_a.thishost,id_dsa1024a.thathost）。

-l login_name #该选项指定你在远程主机上登录的用户名。这个选项和ssh1的相同。缺省的用户名和本地主机的用户名相同，也可以在配置文件中按每台主机定义。这是很有用的选项，因为今天有些人通过不同的帐号使用着不同主机。

-L port:host:hostport #该选项把指定port上的任意到本地主机的连接转寄到远程主机的hostport上。这和ssh1中的选项相同，socket监听在本地主机上端口和何时建立到该端口的连接（例如，POP端口110），连接被转寄到安全通道，然后建立在hostport上的远程主机的连接。端口转寄也可能以通过配置文件按每个主机定义。对于特权端口，只有超级用户可以转寄。

-n #该选项和-f 选项的工作类似；然而，如果你需要键入口令时它将不起作用。这是ssh1具有的相同选项。标准输入被/dev/null重定向，在安全shell客户程序被发到后台时必须使用该选项。这通常用于脚本以及发送正在在远程主机上运行的X传输。和认证代理一起时使用该选项是很好的。

-o option #该选项用于当没有定义命令行选项时，在配置文件中传送选项。这和ssh1中的选项相同。这包括StrictHostKeyCheckingUseRsh，在命令行中没有这些选项。这些选项和其它选项在后面的章节中阐述。该选项的格式和配置文件中的格式相同。

-p port #可以指定客户连接到服务器的哪个端口，这和ssh1的选项相同。缺省端口22，是为安全shell保留的端口。记住除非另外指定在文件/etc/services中定义的端口是给服务器的。这可以在配置文件中以每台主机的方式指定端口。

-p #指定使用大于1023的端口，这是一个非特权端口。这和ssh1的选项相同。你不能使用它来进行远程主机(rhost)认证（无论是和公共密钥一起或它自身）。然而，这对通过不具有该选项配置的防火墙进行的连接很有用。

-q #这是一个静态方式，指它不显示任何信息。这和ssh1使用的选项一样，通常适合于警告和诊断信息。如果使用该选项，在运行碰到认证或连接问题时，你将关闭该选项。

-R port:host:hostport #这将从指定端口上的远程主机连接转寄到本地主机上的主机端口。这和ssh1的选项相同。这和L选项的工作相反。socket监听远程主机的端口，无论何时连到该端口的连接一旦建立，它将被转寄到本地主机和该主机端口。端口的转寄可以在配置中为每个主机单独指定。如果你使用了特权端口，只有在以超级用户在远程主机上登录时才进行转寄。

-S #这为安全shell客户指定不需要会话通道。这用在端口转寄请求和在tty不需要被设置使用（非交互模式）时。

-t #该选项使安全shell客户工作在交互模式下。这和ssh1中使用的选项相同，它强制产生虚拟tty，即使给出了命令。这可以用在于远程主机上执行基于屏幕的程序。

-V #该选项打印客户机版本并退出。它和ssh1中选项的作用相同。

-v #冗余模式。使ssh产生打印关于程序运行的调试信息。这在调试连接，认证和配置时是很有用。这相当于在调试模式下以2级运行。它和ssh1中的选项完成相同的事情。

-x #不允许X传输的转寄。这和ssh1中使用的选项相同。由于已知X是不安全的，对过份追求安全的站点可能要使用该选项，该选项可以通过配置文件为每台主机单独指定。

+x 如果你想允许X传输被转寄，使用该选项。这恰好是ssh2的缺省选项。

（2）一些例子

如同SSH1，该选项不是由缺省设置的，缺省设置安全shell以运行前台和启动终端。而且，传输不是缺省方式压缩的。当要压缩数据时，进程可能使传输变慢，并且浪费CPU时间，从而使你不能增加任何带宽。X传输被自动转寄，但是你不能关闭它。

如果你想使用选项以得到像缺省选项相同结果，可以键入命令行：

$ ssh2 +a –C -e ~ -l $USER -p 22 +x host.com

因此，用安全shell登录到远程帐户，你可以使用以下命令：

$ ssh2 host.com

这允许你用不同的用户名登录。例如，如果我现在的本地主机有用户名“anne”，我在远程主机上具有的帐号为“ahc”。注意，这是你用ssh1作的相同事。要以“ahc”登录。我使用以下命令：

$ ssh2 -l ahc host.com

由于我使用的是Modem线，我需要打开压缩开关。我也想使用IDEA密码：

$ ssh2 +C -c idea host.com

如果你想连接到远程主机并且在后台运行进程，你很容易就能实现。这经常用在和X联合编程或用在shell脚本中。记住这将提示要求输入认证。你也想关闭转义字符。

$ ssh2 -f -e host.com ×load

如果你想把输出发送到/dev/null并且在后台运行进程，使用与-f选项相关的-n选项。这并不提示输出口令，因此要保证你和.shosts或验证代理一起使用该选项。你再次可能要关闭转义字符。

$ ssh2 –n –e host.com xclock &

如果你想从端口22连接到不同端口上的远程服务器，使用-p选项。

$ ssh2 -p 2023 host.com

2．scp2的使用

和ssh1 scp客户相类似，scp2的语法比ssh2的语法要稍微复杂一些。如下所示：

$ scp2 user@source:/directory/file user@destination:/directory/file

scp2的好处是你可以拷贝到远程主机或拷贝到本地主机。因此，依赖于所要发送的文件的位置（或者是远程或本地主机），需要指定用户名、主机名、目录和文件。这听起来可能较复杂并且好象要记住很多东西，但是如果正确地去做，你将顺利地实现scp2。

我使用scp2从在家中的linux主机上拷贝文件或把文件拷贝到linux主机上；从我的ISP帐号上拷贝文件或把文件拷贝到我的ISP帐号。

（1）命令行选项

如果你需要在设置密码、定义身份文件、保留文件属性、设置端口、允许压缩、设置批处理方式以定义ssh2选项（因为scp2用ssh2作的传输载体）之间切换，有一些在scp1中没有出现的新选项。

注意选项-a，-A，-B，-C，-i，-l，-o，-q和-Q在scp这种实现中不再存在。

-l #使scp2运行scp1。这个（是1(一)而不是l(L)。这就与ssh1服务器好兼容，因此如果你打算运行该选项，可以和这个选项一起使用-t和-f选项，更多的关于scp1的信息请参见第四章“安全客户程序SSH和SCP”。

-c cipher #这和在ssh2中定义的选项相同，是因为它是被直接发送到ssh2的。这也和scp1使用的选项相同。可以选择你要用的对称钥匙密码来加密网络传输。这不影响使用DSA或RSA公共密钥的认证。你所要选择的密码有IDEA，DES，3DES，Blowfish，Arcfour和Twofish。你也可以选择“none”，但是这不允许任何的加密从而使得安全Shell客户变得不安全。该“none”选择应该只用于调试和测试目的，而不用于实际的应用中，最好的选择是使用3DES，IDEA或Blowfish。Blowfish和Twofish在支持ssh2的算法中最快的。为了获得最好的安全特性，使用IDEA。如果不被对方的安全Shell服务器支持，使用3DES。

-d #这是一种明智的检查，以确定拷贝目是目录。如果拷贝目的不是一个目录（也就是说例如它是一个文件0。scp2将给出错误信息，然后退出。

-D debug_level_spel #该选项指定你接收的调试的数量。它和ssh2使用选项相同。

-h #打印命令使用的总结，然后退出。它不运行scp2程序。

-n #预览scp2所做的事，但是它不能拷贝任何文件，这是一种在进行正式拷贝之前确定你把正确文件拷贝到正确位置的很好方法。

-p #保留从源主机拷贝过来文件的属性。这包括文件的更改时间，读取时间和从原始文件过来的模式。该选项直接从rcp移植过来并和scp1中使用的选项相同。如果你工作在文件备份并想保证文件的完整性，你会发现该选项很有用。

-p port #可以指定客户机连接到哪个端口上的服务器。这与scp1的命令行选项相同。缺省端口为端口22，该端口是为安全Shell保留的端口。记住除非另外指定该端口用于服务器的定义在/etc/services文件中。这是和ssh2不同的，因为rcp使用-p来保留文件属性。

-r #递归拷贝全部目录和其中的文件。这将拷贝目录中的所有文件和子目录。这和scp1使用的选项相同，该选项直到版本2.0.13才被支持。

-S path_ro_ssh2 #该选项指定到ssh2的路径。这和scp1中用到的选项相类似。如果你把ssh安装在一个非标准目录中时，就要使用该选项。

-u #该选项使用scp2更象使用安全的mv功能。在把源文件（和目录）拷贝到目的后，该选项将删除这些原文件（和目录）而不是保留住它们。要小心使用该选项。

-v #冗余模式。产生scp2打印有关scp2进程的调试信息。它打印出第2级上的调试信息。这在调试连接，验证和配置问题时很有用。这和scp1中使用的选项相类似。

（2）一些例子

以下选项不是缺省配置的。Scp的缺省设置是在后台运行并且显示统计信息。另外，缺省情况下传输也不被压缩，是因为这会减慢传输速度和仅仅是浪费CPU周期。缺省时也不设置批处理模式以及使用22号端口。我们假设本地主机帐号名为“anne”，远程主机帐号名为“ahc”。

则从我的本地主机把一个文件拷贝到我的远程主机的命令为：

$ scp2 filename ahc@host:/home/ahc/

为了从远程主机把一个文件拷贝到本地主机上的当前目录，用了同样的命令。然而，它看起来有些不同：

$ scp2 ahc@host:/home/ahc/filename

如果你要看统计数据，就象下面的样子：

$ scp2 ahc@host:/home/ahc/filename

SHOW OUTPUT

如果你想不实际运行拷贝文件而看到scp2将要做些什么，用：

$ scp2 –n ahc@host:/home/ahc/filename

如果你想把文件拷贝到tools目录中并要确定tools是一个IDEA密码加密的目录：

$ scp2 –d –c idea ahc@host:/home/ahc/filename tools

你可以拷贝2000号端口上的整个目录结构（例如备份一个Web站点）。

$ scp2 –r –p 2000 ahc@host:/home/ahc/ tools

如果你想把文件拷贝到tools目录中并将该文件由远程主机删除：

$ scp2 -u ahc@host:/home/ahc/filename tools

3．sftp2的使用

和scp2客户相似，sftp2有一些怪的语法：

$ sftp2 hostname [port number] [username]

可以和运行安全Shell2服务器守护程序的任何主机一起使用该客户，这是一件好事。FTP连接不存在“单独”的守护程序；所有的工作都是从客户程序完成的，该客户是FTP型的客户。这并不是使用FTP自身，而是一种类似的客户程序。注意它的语法和FTP自身的语法极其相似，但是有一些你可以指定的与FTP不同的sftp2的命令行选项。

（1）命令行选项

如果需要在设置密码，定义端口和设置ssh2路径之间切换，这些选项将会有用。它也有两个调试选项，但只有在运行到出现问题时才会用到它们。由于sftp2是安全Shell的一个新的应用程序，所以现在并没有很多的选项。

-c cipher #这是和ssh中定义的选项相同的选项，是因为它直接被传送到ssh。此外，这和scp1使用的选项相同。你可以选择想用哪种对称钥匙密码来加密网络传输，不影响使用DSA或RSA公共密钥的认证。可选择的密码有IDEA，DES，3DES，Blowfish，Arcfour和Twofish。你也可以选择“none”，但是这将不允许任何加密从而导致安全Shell客户不安全。该“none”选项应该用于调试和测试目的，而不用于实际使用。DES和Arcfour是已知的两种不安全的密码，因此不要使用它们。你最好是使用3DES，IDEA或Blowfish。Blowfish和Twofish是支持ssh2最快的算法。为要获得最佳的安全特性，使用IDEA。如果IDEA不被双方的安全Shell服务器支持，则使用3DES。

-d debug_level_spec #该选项定义你接收的调试信息的数量。它和ssh2使用的选项相同。注意scp2使用-D，而sftp2使用-d。

-p port #可以指定客户连接到哪个端口上的服务器。缺省为22号端口，该端口是为安全Shell保留的。记住除非另外指定用于服务器的该端口定义在文件/etc/services中。这可以在配置文件中接每台主机单独指定端口。注意该选项和ssh2中端口选择相同。

-S path_to_ssh2 #该选项指定到ssh2的路径。该选项和使用在scp2中的选项相同。如果你把ssh安装在一个非标准目录中时要使用该选项。

-v #冗余模式。这类似所为安全Shell2的客户，它导致sftp2打印关于过程的调试信息。它打印出调试级为2的信息这对调试连接、认证和配置问题时有帮助，和用在scp1中的相同选项类似。

（2）一些实例

以下选项不设置成缺省值。Sftp2的缺省设置是端口22上运行。如果你要设置类似压缩和密码等和ssh2很有关系的选项，而不是与sftp2客户机相关的选项，你应该如同本章后面所述在配置文件中设置它们。

因此，带有选项的缺省命令如下所示：

$ sftp2 -p 22 hostname.com

要发送一个文件应使用安全shell的2000端口，并使用带用户名ahc的Blowfish密码：

$ sftp2 –p 2000 –c blowfish hostname com ahc

4．配置安全shell客户程序

安全Shell具有你可以缺省方式定义选项的配置文件。它设置ssh，scp和sftp客户的选项。一些选项是不能由命令行选项定义的，但是可以配置额外的功能与安全Shell协同工作。和大多数的配置文件和Shell脚本相似，空行和以“#”开头的行不输入。安全Shell的缺省配置文件为/etc/ssh2/ssh2_config，它设置了ssh2和scp2两个客户程序的选项。

和客户程序一起，用户可以拥有它们自己在$HOME/.ssh2/ssh2_config文件中的指定设置。这个文件具有与/etc/ssh2/ssh2_config文件相同的格式。应用到客户程序的选项的顺序为：

(1) 命令行选项 (2) 用户配置文件 (3) 系统级配置文件

以下是可以在ssh2_config文件中为安全Shell设置的选项。在/etc/ssh2/ssh2_config文件中定义这些选项的格式是：

OptionType Argument （选项类型 参量）

如果你有多个参量，可以用空格分隔它们。该格式适用于下列所有选项。

（1）主机名选项

可以通过一些配置选项来定义影响你连接到的远程主机的一些选项。所有这些选项适用于IP地址以及网络主机名。和ssh1不同，是没有ssh2的HostName配置选项。通过通配符，你可以过滤一段地址或通过整个域过滤。

• Host #它定义哪些主机受配置文件中配置选项的影响。这是与用在ssh1中相同的选项。可以使用通配符（多字符“*”，单字符“？”，和在命令行中给出的主机名相同。

使用方法：Host tigerlair.com

• StrictHostKeyChecking #该选项是和在ssh1中实现相同的选项，但它现在不在SSH2 2.0.11版本中实现。它可以用来配置客户是否把主机密钥自动加到$HOME/.ssh2/know_hosts文件中还是提出主机密钥请求。如果你频繁地连接到不同主机（例如，假设你正从ISP使用一个shell帐号，并且你的连接获得动态分配的IP地址），这可能不是一个好主意。如果你正在设置运行于主机不会改变的开发环境上的安全Shell，你可能会把该选项设置为“no”。你的选择可以是“no”、“yes”和“ask”。“ask”选项当你想往known_hosts文件中添加一台主机时产生提示。

使用方法：

StrictHostKeyChecking ask

（2）认证

安全Shell提供不同的认证方法：口令字，远程主机（rhost），公共密钥和TIS认证机制。你可以仅使用一个或使用它们的任意组合来通过安全Shell访问帐号。然而，得留心，远程主机认证是最脆弱的，任何与公共密钥对的组合都将是最强的认证形式。

注意：Secure Shell2并不实现NumberOfPasswordPrompts,TISAuthentication和Kerberos选项。

·BatchMode：这是和用在ssh1中一样的配置，但是它现在对ssh2并没有执行，如果该项设置为有效，则它将关闭要求口令字的提示。如果你正使用安全Shell脚本或运行克龙或批处理作业，这是很好的。记住，它对具有正在进行认证代理而不是使用远程主机很有帮助。缺省选项是“no”，你可选择“yes”和“no”。

使用方法：

BatchMode no

·PasswordAuthentication：可以定义是否要运用口令字来通过安全Shell访问帐号。这和使用在ssh1的选项一样。缺省为“yes”，从更通常的意义上来说口令字所要做的是保护私人密钥，而不是帐号本身。可以选择关闭口令字认证，但是最好还是让口令字认证打开，这是因为它保护着你的私人密钥和公共密钥。这和安全Shell监控程序的passwordAuthentication相似。

使用方法：

PasswordAuthentication Yes

·PasswordPrompt：这指定口令字提示中是否包括远程主机名和用户名。该选项把ssh1 中的PasswordPromptHostname和PasswordPromptLogin的两个选项合并成一个选项。变量%U和%H分别代表用户名和主机名。这仅对用户所见有影响，而不影响程序的实际运行。

使用方法：

PasswordPrompt″%u password″

·RHostsAuthentication：该选项设置认证是仅基于.rhosts的还是基于/etc/hosts.equiv的。这不需要口令字或公共密钥对。这和使用在ssh1中的RhostAuthentication选项相同，并且它把你的系统暴露在Berkeley服务的攻击之下，那是如所周知的，这也是你首先要使用安全Shell的原因。如果你果真想使用远程主机认证，则与RHostsPubkeyAuthentication中的公共密钥认证捆绑在一起使用。这和设置RHostsAuthentication的安全Shell服务器守护程序相类似。然而，它并没有具有与服务器端配置对安全影响相当的重要性。

使用方法：

RHostsAuthentications no

·RHostsPubKeyAuthentication：该选项设置你的认证是基于带公共密钥对的.rhosts或/etc/hosts.equiv。这和ssh1的RhostsRSAAuthentication选项类似，并且能与ssh1兼容。遗憾的是，在发行的安全Shell 2.0.11版本中并没有实现它。这并不需要一个口令字，但它的确需要远程端具有一个公共密钥对进行认证。这把你的系统暴露在Berkeley服务的攻击之下，但是由于需要公共密钥对这种攻击威胁是最小的。如果你保持该选项为“yes”（缺省值）可能想设置一些更严格的主机登录请求。另外，如果你想支持更强的安全性，关闭任何类型的远程主机认证。这和安全Shell服务器守护程序配置选项RHostsPubkey Authentication类似。

使用方法：

RhostsPubKeyAuthentication no

·PubKeyAuthentication：可以使用多种认证类型；或者正如所见，也可以使用单一的类型，这和ssh1的RSAAuthentication选项类似，并且在使用上和ssh1可以兼容。如果你想定义只接受公共密钥的认证，你可以做到这一点。这不需要远程主机登录或口令字来帮助认证。缺省为“yes”，并且还是设为缺省值好。这和安全Shell服务器守护程序配置选项RhostsAuthentication类似。

使用方法：

PubKeyAuthentication yes

（3）客户端选项

这些选项说明了安全Shell客户如何运行的总括。这些一般性设置包括诸如远程主机上的用户名、连接尝试、代理命令（如果使用的话）、密码、转寄、转义字符和使用rsh等选项。

注意：CompressionLevel，ClearAllForwardings,ConnectionAttempts和ProxyCommand不再被安全Shell2的选项支持。

• DontReadStdin #使用该选项在安全Shell认证代理运行的情况下用户不需要口令(passphrase) ，该选项重定向输入到/dev/null，

使用方法：

DontReadStdin no

• Cipher #该选项是你可以选择连接的密码的选项。你可以使用IDEA，3DES，Blowfish，DES和Arcfour。这是ssh1中使用的相同选项。你也可以选择“none”，但是除非你正在进行调试，否则不要这样作。你最好是选择IDEA、3DES或选择Blowfish。因为IDEA所有的服务器都不支持，如果选择了IDEA而它不被支持，它将失败而自动使用3DES。

使用方法：

Cipher idea

• Compression #定义你是否使用压缩，这是ssh1中的相同选项。这是gzip应用程序使用的相同算法。你有两种显而易见的选择：“yes”或“no”。记住如果你想运行在一个高速网络上，请勿打开压缩选项，因为它实际上是在减慢运行而不是加速它们。

使用方法：

Compression yes

• EscapeChar #定义转义字符，它和ssh1选项一样。缺省转义字符是代字符（~）。这和你可以在命令行上使用的-e选项一样。它的参量应该是一个单一字符，用单一字符后随克拉字符（^）表示一个控制字符，或者“none”来指示不允许的转义字符（使得连接更为透明）。

使用方法：

EscapeChar ’z^

• FallBackToRsh #可以定义安全Shell客户以使得如果连接失败（通常是由于在远程或本地没有守护程序运行），它将尝试通过rsh来连接到远程客户。在运行rsh之前，你将得到不安全的警告。这是和在ssh1中使用相同的选项。如下所示：

tigerlair:/home/ahc:ssh www.trusting.host.com

Secure connection to www.trusting.host.com refused

reverting to insecure method.

Using rsh.WARNING:Connection will not be encrypted.

使用方法：

FallBackToRsh no

• ForcePTTYAllocation #该选项强制产生一个tty，即使是给出了命令，用于菜单命令界面等场合。作为2.0.11版本，现在还没有实现。

使用方法：

ForcePTTYAllocation No

• GoBackground #这强制使ssh2在认证之后作为后台进程（需要在后台运行时有用，但用户需要输入口令）。

使用方法：

GoBackground Yes

• KeepAlive #安全Shell守护程序可以设置成发送保持活动状态或不发送该信息。这和ssh1使用的格式一样。保持活动信息使得远程服务器知道连接是否已经终止；其结果是杀掉活动进程。然而，如果路由暂时失败，则将受挫并看到如下的信息：

Connection down; disconnecting

好了，这是很烦人的。但是如果你不发送保持活动的信息，你可能把它挂起保留幽灵进程并吃掉你服务器上的资源。缺省设置为“yes”，它意味着服务器发送保持活动的信息。如果你想不允许保持活动信息，将不得不允许服务器和客户配置文件。小心如果你决定这样作，仍可能是悬挂进程。这和安全Shell服务器守护程序配置设置keepAlive相类似。

使用方法：

KeepAlive yes

• User #是你在远程主机上指定用户名进行登录的地方。这和sshl的选项相同。如果你经常以不同用户名登录远程主机比登录到你的本地主机的次数还多，你就可能想定义该选项。

通过这种方法，你不必经常在命令行下键入-l选项。

使用方法：

User ahc

• UseRsh #该选项指定是否应该在这台主机上使用rsh。如果该主机不支持SSH协议，则rsh或rlogin被自动省略。因此，除了继承rsh的安全问题外，你可能不想使用这个特殊选项。

使用方法：

UseRsh no

（4）文件位置

这些选项定义安全 shell客户文件的放置地方。这包括系统和用户的用户身份文件和已知主机文件。

注意不再有GlobalKnownHostsFile和UserKnownHostsFile选项。

·AuthorizationFile #该选项指定用户认证文件名。缺省为 $HOME/.ssh2/authorization

使用方法：

AuthorizationFile~/.ssh2/newauth.file

• RandomSeedFile #该选项指定用户的随机种子文件在哪里以及用于产生用来创建公共密钥对的随机数。缺省为$HOME/.ssh2/random_seed。

使用方法：

RandomSeedFile~/.ssh2/newrandom.file

• IdentityFile #该选项指定用户DSA或RSA私人密钥放置的地方。缺省为$HOME/.ssh2/id_dsa1024_a。这和sshl的IdentiyFile选项相类似。也可以为所要连接到的每台主机定义一个身份文件。你可以用代字号(~)而不是$HOME来代表用户的根目录。

使用方法：

IdentityFile~/.ssh2/id_dsa1024_a.thishost

（5）端口

使用安全shell,可以用端口作很多事情。包括有：定义本地和远程转寄端口，安全shell客户连接的实际端口，以及是否使用了特权端口。GatewayPorts不再在ssh2中实现。

• LocalForward #这把任何到指定端口的本地主机的端口连接转寄到远程主机的连接端口，这是使用在sshl的相同选项。socket监听本地主机的端口，并且无论何时到这个端口(例如，假设的POP端口110)的连接被建立，连接就会转寄到主端口的远程主机上。对于特权端口，只有超级用户可以转寄它们。这和sshl客户机的-L选项相同。

使用方法：

LocalForward 1025:remotehost:110

• port #可以指定安全shell守护程序监听的端口。缺省端口为22；然而，为了应用上的目的或当端口22被使用时，你可能想定义其它端口。这和使用在shell中的-p选项相同，并且类似于安全Shell服务器守护程序配置文件的端口选项。

使用方法：

Port 21

• RemoteForward #这把从远程主机(在指定端口上)的任何连接转寄到本地主机的主机端口。这是和sshl中使用的相同选项。这以与-L选项相反的方式工作。socket监听远程主机的端口，并且无论何时到这个端口的连接被建立，连接就会转寄到本地主机和主机端口。如果使用特权端口，只有在远程主机上以超级用户登录才能转寄该端口的连接。这和sshl客户的-R选项相同。

使用方法:

RemoteForward 110:remotehost:1025

• UseNonPrivilegedPort #使用高于1023的端口，一个非特权端口。不能使用这个选项来进行远程主机认证(不管是和公共密钥认证捆绑或它自身)。然而，这对连接通过没有端口配置的防火墙很有用。尽管这在2.011版本中没有被实现，它和 sshl的UsePrivilegedPort选项相同。这和-P选项相同。

使用方法：

UsePrivilegedPort yes

（6）转寄选项

这些选项用来定义ssh2的转寄。它们包括：转寄认证代理到远程主机以及转寄X11信息量。

• ForwardAgent #这个选项可以配置转寄连接到远程主机上的认证代理。这是使用在sshl中的相同选项。在你不使用口令字和想使用安全shell来作诸如shell脚本等事情时将有所帮助。

使用方法：

ForwardAgent yes

• ForwardXll #该选项定义X转寄是否通过shell通道自动发送以及设置DISPLAY环境变量。这是和sshl中使用的相同选项。和其它TCP传输一样，这可以被用户定义的转寄者覆盖。由你来允许X信息量通过。然而，如果你打算让X信息量远程通过，你会希望通过安全shell转寄它。这和在安全shell守护程序上的XllForwarding选项相类似。

使用方法：

ForwardXll yes

（7）SSHl兼容性

这些选项指定SSH2和SSH1的兼容性。这包括：使用SS1的兼容代码，使SSH1的认证代理兼容，以及sshl的路径。

• Ssh1AgentCompatibility #该选项定义安全Shell 2认证代理是否应该和安全shell 1兼容。可以使用的选项是“none”,“ traditional”和“ssh2”。如果你正以在Sshl Compatibility中定义的SSH1兼容模式使用安全Shell2认证代理，你只能使用“ssh2”值。否则，"none”将不会转寄任何SSH1代理，“traditional”将象运行SSH1一样转寄。

使用方法：

SshlAgentCompatibility ssh2

• SshlCompatibility #如果你想同时支持SSH1和SSH2，就要把它设置成“yes”。如果你和只支持sshl的服务器连接，这将执行sshl客户程序。

使用方法：

SshlCompatibility yes

• SshlPath #这个选项指定sshl客户程序的位置。缺省为/usr/local/bin/sshl。这是一旦连接到只支持安全shell 1的的服务器守护程序就会运行的应用程序。

使用方法:

SshlPath /usr/local/security/bin/sshl

（8）冗余选项

这些模式决定你希望安全shell客户告诉你多少东西。有两种模式：VerboseMode，该模式给你很多信息，QuietMode,该模式只给很少的信息。

• VerboseMode #这个模式导致ssh2客户打印调试信息。这意味着除非你在查找故障或是测试，你不要以这种模式运行。这些信息对连接、认证和配置问题有用。

使用方法：

VerboseMode no

• QuietMode #该选项和VerboseMode相反。被打印出来的信息只是导致ssh2不能按原有的方式工作的致命错误。如果你确切知道发生了什么，你可以使用该模式。多数人保留该选项为“no”。

使用方法：

QuietMode no

17.3 SSH进阶

17.3.1 SSH的端口转发

一种比较流行的使用安全Shell的技巧是把它用于转发通信量。实际上，安全Shell具有内在的X转发功能是很普遍的。对于其它流行的应用，网络上的好手编写了为其通信提供端口的软件，其中包括POP和FTP。

有两种不同类型的转发：本地和远程。本地转发涉及到将本地系统启动的连接发送到另一个端口（例如，POP或DNS）的远程系统上, 并通过安全Shell端口22转发它，以保证连接的安全。图17-7显示了本地转发是如何工作的。

图17-7 本地转发连接是如何工作的

图17-8 远程转发连接是如何工作的

远程转发正好相反。接收到远程服务器另一个端口上启动的连接后，安全Shell把连接安全地转发回远程主机。图17-8显示了远程转发是如何工作的。

为了转发一个连接，你需要熟悉安全Shell客户程序的某些特定选项。对安全Shell 1，涉及到下面列出的压缩选项，userid选项和本地转发选项：

-C 压缩数据包，适用于邮件传输，包括POP3，SMTP和IMAP4。

-l 如果在远程系统上有不同的用户名，则改变之。

-g 规定远程主机是否可以连接到本地转发端口。

-c 加密选择。要确保与远程服务器相兼容。

-L 将本地端口映射到远程系统上的同端口。

对安全Shell 2，这些选项将在你转发连接时给以帮助。注意它们与安全Shell 1中的不同。

+C 压缩数据包，适用于邮件传输，包括POP3，SMTP和IMAP4。

-l 如果在远程系统上有不同的用户名，则改变之。

-c 加密选择。要确保与远程服务器相兼容。

-S 不需要分配tty的端口转发（面向非交互模式）。

-L 将本地端口映射到远程系统的同端口。

下表列出了一些常用服务和你可能想要转发的与这些服务有关的端口。这没有包括所有可能的服务。这个简化的表提供了一些例子，来说明能用安全Shell做些什么。

表17-2 一些常用的想通过安全Shell来提供保护的服务

服务 端口 做什么

Telnet 23 虚拟终端

NTP 37 网络时间服务

FTP 21 FTP连接控制

FTP data 20 FTP数据连接

SMTP 25 简单邮件传输协议

DNS 53 域名服务

HTTP 80 超文本传输协议

POP3 110 POP电子邮件检索

NNTP 119 Usenet服务

RPC 111 远程过程调用

IMAP4 143 IMAP电子邮件检索

从这可以看到, 无论你是否需要为其分配一个tty，你都可以使用任何类型的TCP连接。你甚至能用安全Shell代替安全套接字层（Secure Sockets Layer, SSL）用于HTTP连通性。这些都依赖于你想怎样去运行它们。

一、非交互式TCP连接的本地特发

下表显示了一些应用本地转发的例子，这些应用在使用非特权帐号时不需要会话连接（即，tty分配）。这些例子对于安全Shell 1和2都是适用的。

表17-3 本地端口转发的一些例子以及它们对安全Shell的非交互服务

服务 端口 例子

Telnet 23 $ ssh -L 1234:telnet.host.com:23 telnet.host.com

NTP 37 # ssh -L 37:ntp.host.com:37 ntp.host.com

SMTP 25 # ssh -L 25:smtp.host.com:25 smtp.host.com

DNS 53 # ssh -L 53:dns.host.com:53 dns.host.com

HTTP 80 # ssh -L 80:http.host.com:80 http.host.com

POP3 110 # ssh -L 1234:pop3.host.com:110 pop3.host.com

NNTP 119 # ssh -L 1234:nntp.host.com:119 nntp.host.com

RPC 111 # ssh -L 111:rpc.host.com:111 rpc.host.com

IMAP4 143 # ssh -L 1234:imap4.host.com:143 imap4.host.com

你还可以为同样的协议定义多个安全连接，甚至是在不同的机器上。比如说，你想要两个POP3服务器安全地连接到你的一台主机上；你可以如下进行：

# sshl -C -g -L 1234:poplsvr.host.com:110 -L

2222:pop2svr.host.com sshsvr.host.com

在这种情况下，不需要使用你正向其转发端口的同一个台主机；相反地，你可以使用一台本地转发有权访问的普通主机。这会在系统pop1svr和pop2svr上，为POP3连接创建两个安全会话，但安全Shell连接可以来自这两台主机能够访问的普通系统上。

如果你正在使用PPP连接，可以在连接后放一个sleep命令。这在允许你有效地使用连接的同时，使你可以保持连接的活动性。

二、交互式TCP连接的本地转发

对不需要会话连接的应用来说，本地转发是非常好的。于是，对DNS、SMTP、POP3、NTP、RPC、IMAP4和诸如此类的应用，你可以使用它，可以拥有连接而不会产生任何问题。但是，对交互式会话，你必须在这个过程中增加几步。这涉及到Telnet, FTP和TFTP。此外，还有其他的交互式网络服务，这仅仅依赖于你想要达到的目的。

表17-4显示了一些应用的本地转发的例子，这些应用在使用非特权帐号时需要有会话连接（即，tty分配）。这些例子对安全Shell 1和2都是适用的。

表17-4 本地端口转发的一些例子以及它们对安全Shell的交互式服务

服务 端口 例子

Telnet 23 $ ssh -L 1234:telnet.host.com:23 telnet.host.com

TFTP 69 # ssh -L 1234:tftp.host.com:69 tftp.host.com

FTP 20,21 # ssh -L 1234:ftp.host.com:21 ftp.host.com

例如，FTP缺省时使用20和21两个端口。20端口传送数据本身，它们不是注册信息。21端口是FTP控制连接，负责转发信息，包括命令、密码和用户名。端口21最有可能是你想要保护的端口。当然，如果你正在传送重要的文件，你会将两个端口都保护起来。

因此，对本地端口转发的交互式连接，需要增加额外的步骤。这样，为象Telnet之类的建立交互式连接，你需要采取以下几步：

1．创建到你的交互式应用程序的本地转发连接

2．打开一个新的会话（xterm, shell等等）

3．用FORWARDINGPORT创建到被转发的端口的连接

这样，对于Telnet，你的做法将如下：

local: /home/me -ssh -g -L 1234:telnet.host.com:23 telnet.host.com

password: ********

Welcome to the telnet server.

telnet:/home/me-

现在，你已通过本地转发连接到远程服务器了。然而，如果想要创建安全的Telnet连接，你要打开一个新窗口，通过被转发的本地端口（在这种情况下，是端口1234）注册到Telnet服务器上去。

local: /home/me- telnet telnet.host.com 1234

password: ********

Welcome to the telnet server.

telnet: /home/me-

现在，你通过一个安全本地端口转发连接上了，并正使用Telnet。可以用FTP做同样的事情。当你使用FTP时，你要记住你正在打开两个端口（20和21），而不是象在Telnet时的一个端口（仅仅端口23）。还有，当你用FTP会话传送文件时，通常更关心的是用户名和口令，而不是数据。为了说明方便，我们使用FTP控制端口作为例子：

local: /home/me- ssh -g -L 1234:ftp.host.com:23 ftp.host.com

password: ********

Welcome to the ftp server.

ftp:/home/me-

象在Telnet连接中一样，现在，你已通过本地转发连接到远程服务器上。然而，如果想要创建安全的FTP控制连接，要打开一个新窗口，通过被转发的本地端口（在这种情况下，是端口1234）注册到FTP服务器上去。

local: /home/me- ftp ftp.host.com 1234

Connected to ftp.

Name (ftp:me):

331 Password required for me.

Password:

230 User me logged in.

ftp>

三、远程端口转发

现在，你已经理解了本地端口转发，你需要进一步了解远程转发是做什么的。这是安全Shell中较少用到的选项。许多人需要通过本地转发来转发其他的协议，但使用-R选项的人就不多了。

为什么呢？因为它不象-L选项有很多用处，而且它也要冒险得多。虽然通过安全Shell转发任何类型不安全的信息流都要有一定的危险，但远程转发是危险性更大的。这其中涉及安全Shell进程接收来自远程客户程序上的被转发的端口。远程客户程序可以远程地通过任何端口转发一个连接。记住，如果是一个超级用户，则它们能够转发低于1024的特权端口。

这样，远程端口转发的语法看起来与本地端口转发时很相似。

# ssh -R FORWARDINGPORT:service.system.com:APPLICATIONPORT

service.system.com

于是，举例来说，如果你在远程主机上使用这条命令，你将通过端口1234上的安全Shell连接连到远程主机上的Web服务器（端口80）上。这是一个很好的通过防火墙进入连接到Web服务器的办法。或者，你可以用这种办法实现一个代理：

$ ssh -R 1234:web.system.com:80 web.system.com

为连接到防火墙里面的Web服务器上，可以在防火墙之外使用远程端口转发连接，这样的防火墙有一个通道接收1234端口上的信息流，并且安全地管理Web服务器。注意，这样的防火墙需要有一个支持HTTP（端口80）、安全Shell（端口22）和远程被转发的端口（1234）的规则集。

为将此作为一个代理，你可以在防火墙的内部启动连接。然后，你可以从防火墙的内部使用ssh –R命令，而不是象在上面例子中那样从防火墙的外部。这样，你就可以完成同样的事情。

这听起来很好，但也有它的问题。虽然你对会话进行了加密，并且使用 了公共密钥认证，但你仍需要记住你是被动盲目地从一台主机不了解的端口上接收连接。虽然可以对用于指定目的的网络数据包进行保护，但因为你允许不了解的、 可能会带来麻烦的网络数据包通过，所以你还要承担一定的风险。

注意：与使用远程端口转发不同，你总可以配置一个SOCKS使能的安全Shell进程和客户程序来生成一个代理。

17.3.2 SSH的密钥代理

安全Shell具有的良好的特性是允许用户把密钥存储在内存中——这就是安全Shell认证代理。这为用户提供了使用RSA密钥而不必随时键入口令字的能力。这对于不必在所有登录、X会话或运行脚本时都要键入口令字提供了便利是很有效的。

一、SSH1

安全shell认证登录是ssh-agent。它使认证代理运行——它不增加密钥。密钥是由ssh-add命令增加的，这将在本章后面讨论。然而，验证代理仅仅用于X终端会话或登录会话。

对任何从安全shell认证代理启动的子进程，代理连接将被任何这些进程继承，包括子进程和孙子进程。这提供了安全shell认证代理从父进程管理密钥的能力。

认证代理产生UNIX socket，该socket被存放在/tmp/ssh-username/agent-socket-porcessID中。socket名被存放在环境变量SSH_AUTH_SOCK中。安全shell所作的维护认证代理安全性的一件事是使得它只能被用户自身访问。然而，超级用户可以访问它，并且如果同一个用户启动另外的ssh-agent进程，这可能产生问题。

1．启动ssh-agent

启动ssh-agent是容易的。你所要作的只是键入命令。要启动安全shell认证代理：

$ssh-agent

这将自动把认证代理发送到后台。然而，你可以用shell运行安全shell认证代理：

$ssh-agent $SHELL

小技巧：可以告诉ssh-agent你想传输shell的类型。如果你想用一些csh类型的shell，

TCP建立一个连接,而UDP则仅仅发送一个数据包。其结果是,TCP连接要比UDP连接安全得多。某些应用程序，如NFS、NIS，都使用UDP,而基于连接的应用程序，如Telnet和ftp，则使用TCP。作为一个通常的规则是你不要让UDP包进入你的防火墙。

注:在配置入站安全shell通路时要非常小心。其中包括使用TCP外包程序,定义安全外壳登录以及关闭rhosts认证。

2．出站

在对防火墙的配置中,有两个规则用于出站流量。其中一个为客户程序所遵循，另一个则用来规范服务守护程序。当客户程序努力创建一个连接时，它就会在已知服务器端口上寻找某些东西(对安全shell而言,端口为22)。另一方面，服务器端程序则试图侦听1021或成更高端口上的连接。

即使你只有出站的流量，你仍需要为某些进入服务器的流量制定规则。没有这些规则，TCP就不能完成握手动作，不能交换诸如主机密钥、服务器密钥以及和用户标识之类的信息，也无法交换数据包本身。注意，你提供防火墙建立的任何类型的连接都不必是单向的，即使是看上去是这样的。

因此，在使用允许出站安全Shell通信流的安全策略时，你将用到下面表17-5中的规则集。

表17-5 出站安全Shell防火墙规则集

连接	源	源端口	目的地	目标端口
客户程序	内部地址	1021或更高	外部地址	22（外部服务器上）
服务器	外部地址	22	内部地址	1021或更高（来自客户）

3．入站

同样的规则适用于配置入站传输的防火墙。你需要两套规则集，一套用于客户程序，另一套用于服务器进程。与出站规则集一样，当客户试图建立连接时，它将在已知的服务器端口（对安全Shell，这个端口是22）上寻找所需。另一方面，服务器一直在监听1021或更高端口上的连接。两者唯一的不同点在于源地址和目标地址。入站的规则集与出站的规则集相反。

即使仅有出站的流量，你的客户程序仍然需要有入站传输规则集。没有这些规则，TCP不能完成握手动作，不能交换诸如主机密钥、服务器密钥和用户标识，以及数据包本身之类的信息。这种情况下，你将使防火墙允许一个完整的连接。

因此，在使用允许入站安全Shell通信流的安全策略时，你会使用到下面表17-6中的规则集。

表17-6 入站安全Shell防火墙规则集

连接	源	源端口	目的地	目标端口
客户程序	外部地址	1021或更高	内部地址	22（内部服务器上）
服务器	内部地址	22	外部地址	1021或更高（来自客户）

二、建立带SOCKS的安全Shell

即使你能够通过防火墙发送安全Shell，安全Shell实际上支持SOCKS, 它是一种电路级代理程序，你可以用它使应用变得对代理友好。最新的版本是SOCKS V5, 它允许位于防火墙后面的UNIX系统无需IP直接地址就可连接到不可信任的网络上。在低带宽的场合，SOCKS是流行的防火墙的替代品，因为它容易使用，并且通过SOCKS服务器的连接对用户是透明的。

SOCKS V5 和SOCKS V4之间的区别是增加了一种认证功能。这个功能使运行SOCKS服务器守护程序的系统的工作象一个代理一样。它提供了由内部网络到外部网络单点访问。

在启动并运行SOCKS守护程序后，你需将想要通过SOCKS服务器守护程序运行的应用程序SOCKS化。由于被广泛使用，发布的SOCKS产品中包括了SOCKS化的ftp, telnet, Archie, finger,whois, rping和rtraceroute等版本。

注意：SOCKS V5可以免费从http://www.socks.nec.com/ 得到。你需要确定所有需要的条件都被满足，其中包括合适的编译器，并记住SOCKS V5与SOCKS V4是兼容的。

为确保安全Shell支持SOCKS, 你需要像下面这样，在安全Shell安装时，将对SOCKS的支持编译到安全Shell的内核中：

# ./configure --with-socks5=/path/for/socks5/goes/here

# make

# make install

或者，如果你有SOCKS V4，并想要面向它编译安全Shell，你需要如下进行：

# ./configure --with-socks5=/path/for/socks4/goes/here

# make

# make install

或者，如果你有更早期版本的SOCKS，并想要面向它编译安全Shell，你需要如下进行：

# ./configure --with-socks=/path/for/socks/goes/here

# make

# make install

为SOCKS化每一个安全Shell客户程序（包括安全Shell2的sftp），你需要如下进行：

# runsocks ssh

# runsocks scp

# runsocks sftp

在有了一个SOCKS化的安全Shell版本后，你会必须作的只是用-c选项。对Bourne-ish shell，使用-s选项。

这将大量产生其它进程。如果你不想在内存中运行过量的其它进程，可以使用exec:

$ exec ssh-agent $SHELL

然后它将和你启动其它shell所作的一样。如果你想从登录会话开始随时这样做，可以把该命令放到你帐户的~/.login文件中或如果正在启动主机时，放到你的启动脚本中。要在你的.login文件中包含ssh-agent，所有你要添加到文件尾部的是：

echo“Running the Secure shell authentication agent…”

exec ssh-agent $SHELL

如果你想和X一起运行认证代理，按以下进行：

$ssh-agent startx &

这启动了运行在X上的认证代理（依赖于你的系统，可以使用其它的命令来启动X。该startx命令是Xfree86所特有的，它运行在Linux和FreeBSD上）。你也可以把这个命令放到~/.xinitrc文件以使得你不必总要键入该命令。

注意：记住运行ssh-agent将不会把你的密钥载入内存。你必须用ssh-add命令自己把密钥载入内存。

ssh-agent是为了帮助给用户提供不必处理口令字的方便而设计的。因此，这可以保持在本地计算机上。用于认证代理的口令不能在整个网络上传送，并且连接在整个远程安全shell登录上转发。这给用户提供了将身份保存在内存中而以安全的方式从一个网络到另一个网络漫游的能力。

1．在内存中用ssh-add管理密钥

当你已经用代理运行，需要把RSA密钥加到代理中。要把密钥加到ssh-agent，你需要运行ssh-add。这把私有RSA密钥加到ssh-agent中，并且允许它通过安全shell连接转发密钥。这意味着在密钥被加入和ssh-agent运行后，你只需要键入一次口令字来使它运行。

要加入你的身份密钥，你只需要做的是运行ssh-add:

shell13:/home/stripes-ssh-add

然后你将被提示输入口令：

Need passphrase for /home/stripes/.ssh/identity

(stripes@tigerlair.com).

Enter passphrase:

在你输入正确的口令后，你将看到你的身份文件已被加入安全shell认证代理中：

Identity added: /home/stripes/.ssh/identity(stripes@tigerlair.com)

在你运行不带有参数的ssh-add命令时，它以缺省方式载入你的~/.ssh/identity文件。在运行ssh-add时，它必然是ssh-agent的子进程。否则，将不会工作。

注意：记住在运行ssh-add之前你必须运行ssh-agent。

你可以用-p选项从标准输入或从管道读入口令。如果你要列出所有存储在认证代理中的你当前的身份，使用-I选项：

注意你可以把多重身份存储在ssh-agent中。

你也可以使用ssh-add把身份从安全shell代理中移去。要移去一个身份，使用后面跟着身份文件名的-d选项：

$ssh-add –d ~/.ssh/identity

要移去所有的身份，使用-D选项：

$ssh-add –D

这意味着你不必逐一登录到每台远程主机上以移去身份——你可以在本地完成该工作。

2．杀死ssh-agent进程

你可以很容易地移去ssh-agent。你可以在从X会话退出时杀死ssh-agent进程或通过杀死SSH_AGENT_PID来终止ssh-agent。

$ kill –9 $SSH_AGENT_PID

或你可以用简单的方法来作这件事：

$ ssh-agent –k

这很漂亮，因为它杀死了你的进程并且复原了UNIX Socket的环境变量SSH_AUTH_SOCKET和进程ID SSH_AGENT_PID。你应该在结束你的会话后做这个工作，它仅仅是从内存中移去RSA密钥。

三、SSH2

SSH2协议具有安全shell认证代理的非常相似的实现过程——称为ssh-agent2 (ssh-add2工作非常类似于它对应在SSH1中的ssh-add命令)。命令行选项和ssh-agent和ssh-add一样；然而，存在兼容性的问题。最重要的是，SSH2的自由软件版本将没有兼容的认证代理，这是因为它不支持RSA。另外，ssh-agent2设置的环境变量是SSH2_AUTH_SOCKET和SSH2_AGENT_PID，而不是SSH_AUTH_SOCKET和SSH_AGENT_PID。

17.3.3 SSH在防火墙中的应用

当使用TCP/IP应用程序时,你也可能希望搞清楚它们是如何与防火墙发生作用的。随着对防火墙需求的增强及安全shell的使用,本章将介绍把这两种技术结合起来后的种种奇妙之处。当然，本章也会介绍防火墙的定义、防火墙的不同类型以及防火墙的各种不同结构。

一、防火墙的定义

只要一谈到网络安全,通常情况下它就是"防火墙"的代名词。对那些网络专家们来说,防火墙只是网络安全的一小部分。那么，什么是防火墙呢?一个防火墙是一个可信任网络与不可信任网络之间的阻隔，用来保护内部网络不受到Internet的侵害。它定义了什么是可信任传输，什么是不可信任的传输。现在的问题是,防火墙的销售商们说防火墙可以允许任何类型的信息传输，却没有提供网络可能遭受攻击的警告。

注:在大多数的防火墙示图中，不可信任的网络通常就是Internet。随着防火墙的结构日益复杂,系统管理员们必须设计他们的网站并用防火墙来划分内部网。

其结果是,许多防火墙会允许你发送你想发送的任何信息流:这包括NFS，伯克利服务，X以及进入安全shell的任何信息。如果愿意,你可以将上述这些不能保证安全的信息转发通过安全shell，于是就不必担心系统会遭受攻击。

许多来自自由软件站点的监测器和信息黑客在Internet上同样会起作用。尽管你已经使用了防火墙将你的网络与不可信任的网络分隔开来,你还是必须清醒地意识到在使用Telnet时还是有人会读到你的文本或截获有用的信息。因为信息流是未经加密的,你的系统对那些防火墙所不能阻止的攻击依然是开放的。

表17-7显示了防火墙不能防止的典型攻击。

表17-7 防火墙不能防范的攻击

攻击	原因
密码监测	清晰的文本信息会被攻击者读取
恶意的内部用户	设计时就没考虑他们会滥用网络服务
病毒	通过一个受信任的端口进入系统
开放端口被淹没（拒绝服务Dos）	设计时就没考虑会发生这样的滥用

1. 防火墙的类型

防火墙通常有三种类型：包过滤器,从本质上说它是一台路由器；应用程序网关,通常是带一个路由表的代理服务器；状态检查器,这是应用程序网关与包过滤器的混合。

（1）包过滤器

包过滤是一台用来过滤网络发送或接受传输的路由器。这台路由器可以(也可以不)使用路由协议,例如RIP,IGRP，OSPF或EIGRP，它们的作用都是用来判断哪些信息可以从网络发出或进入该网络。一般情况下,它们只做几件事:检查IP地址和端口，以及确定数据包是否以正确的方式通过网络。然后再决定是发送还是接受数据包。

对照OSI模型,路由器起着第三层的防火墙角色——检查IP地址和端口。能通过配置而起作用的其他检查是：源路由，协议类型及已建立的连接。即使传输不是由正确的应用程序发送出来,只要包与允许的IP地址与端口相匹配，也不会产生任何问题。图17-9显示了一个包过滤器是如何在可信任网络与不可信任网络之间工作的。

图17-9 包过滤防火墙

路由器通常扮演好" 穷人"的防火墙的角色但正如所描述的，它们仅仅工作在IP层。其结果是它不具备扩展性，因而也不能提供最大限度的安全性。因为包过滤器并不检查应用程序的类型,这样做的结果使速度加快了，但是也使你不能得到数据包正规的和没有恶意的保证。

（2）应用程序网关

一个应用程序网关,或是代理服务器,用来检查应用程序的类型,然后才将数据发送往非信任网络或者允许网络接受来自外部的数据包。这种设计使网络具备了相当的安全性,因为数据包本身必须通过检查以确定它是否属于该应用程序。因而,可信的应用程序虽然是安全的，但在代理服务器中依然受到一定的限制。所幸的是,某些应用程序网关允许安全shell传输通过,因为它们被看作是公共的网络应用程序。

对照OSI模型，应用程序网关处在第7层，尽管它也执行对第3层和第4层的检查工作。因为有这么多的检查,应用程序网关会显得比包过滤器慢许多。作为一个典型，图17-10显示了应用程序网关是如何对待可信与不可信网络的。

图17-10 应用程序网关防火墙

应用程序网关有它的优点，它能屏蔽一个应用程序，屏蔽范围从数据链接层到应用层——但如果你是在一个子网上,你可能会对过多的屏蔽感到厌烦。记住,应用程序网关可能会在应用支持上受到一定的限制,尤其是在你使用了秘密的程序时,应用网关可能被QOS（Quality of Service,服务质量）、TOS（Time of Service服务时间）或DOS（Denial of Service,拒绝服务）攻击所摧毁。

比较而言，应用程序网关也比包过滤器要昂贵得多(除非使用自由软件)，因其价格因素应该慎重考虑。使用应用程序网关，用户却能得到许多额外的性能，而这些性能是包过滤器所并不具备的。

（3）状态检查器

既然包过滤器和应用程序代理都有它们相应的缺点,状态检查器应运而生,它是应用程序网关和包过滤器的混合（Hybrid）。在这种情况下应用程序网关被修改成与包过滤器一样透明,但提供了与应用程序网关同样的安全性。于是,状态检查器便同时具有了与包过滤器相同的性能及应用程序网关的安全性。

除了FW-l外，Cisco公司的PIX盒的最新版本也是状态检查器。同样,硬件防火墙也有它们自身的方便。Cisco公司的PIX与NOKIA IP400系列都提供了比任何基于unix或NT的防火墙更强的安全性，NT的要求有为作前为导服务的操作系统。其论点是你不必担心操作系统自身有何安全问题，你仅需关注防火墙产品自身。

状态检查器工作于QSI模型所有七层，从最底层的物理层到应用层，也正因为必须进行如此多的检查，状态检查器防火墙要比包过滤器慢，但还是比应用程序网关快。对数据包的分析工作是在核心层而非应用层，这也是速度得以提高的原因所在。

状态检查器是包过滤器与应用程序网关的最佳折衷，但它也有自身的缺点。与包过滤器类似，你可以将其定义成允许任何数据通过，包括一些原本就不安全的程序，如NFS和伯克利服务的数据。

注：尽管那些卖主声称可以允许任何数据通过你的防火墙，你还是必须清醒地意识到这样做可能带来的危险。

2．防火墙的标准配置

防火墙可以设计成具有不同的体系结构。因为本书的重点是安全shell而不是防火墙,这里只介绍一些关于防火墙结构梗概。如果你想了解有关防火墙更为详尽的内容,请参阅McGraw-Hill 的"Firewalls Complete"一书。

（1）过滤性防火墙

在仅有一个防火墙或路由器的情况,你拥有一个过滤性防火墙结构。这使你在连接到非信任网络时会发生单点故障。当连接很重要时，你可能希望有冗余的防火墙。这种结构使你只拥有一个"检查器"，该检查器在数据包通过时决定该数据已是否有权力进入可信网络。图17-11显示了过滤性防火墙如何提供可信网络安全性的。

（2）被屏蔽的子网

如果你有心为一个非可信网络提供服务，可以通过建立一个DMZ（非军事区，即在路由器和堡垒主机之间的网络段）网络段。当你连接到非可信网络时会发生单点故障，但你可以在不牺牲可信网络的情况下为非可信主机提供服务。数据包首先接触到过滤性路由器,然后是DMZ，再后是防火墙，最后你才能到达可信网络。在数据包到达防火墙之前至少要经过两层"检查站"，然后才由防火墙决定是否允许数据包进入可信网络。图17-12显示了被屏蔽子网的防火墙是如何提供可信网络额外安全保护层的。

图17-11 过滤性防火墙

图17-12 被屏蔽子网防火墙

正如所见，过滤性路由器是用来保护DMZ和可信网络的,你可以根据需要在DMZ上放置足够多的堡垒主机（Bastion Host,指对网络安全至关重要的防火墙主机）。DMZ为可信网络提供了额外的安全性，从而为可能被攻击的主机提供服务。这也使系统管理员在可信网络遭破坏之前有足够的时间去发现威胁并终止服务。

这种设计可用以保护可信网络，同时不为非可信网络通过DMZ提供任何服务。DMZ是一个为可能被攻击也易于恢复的"堡垒"主机提供服务的可信网络的安全层。"堡垒"主机是那些为你的网络外部提供特定服务的计算机(诸如DNS、WWW、FTP、SMTP等)。因为不必要的系统服务可以关闭,攻击者才无从接管你的主机并获得防火墙的配置信息。

（3）多宿主防火墙

在被屏蔽的子网中,你可以利用多宿主防火墙通过DMZ上的堡垒主机提供服务。这使你在不需要第二层防火墙或过滤性路由器的情况下就拥有了DMZ。然而，与过滤性的防火墙配置类似，你现在只有一个"检查站"用来让所有内部的和DMZ的流通过。如果你在DMZ,非可信网络和可信网络之间有大量信息流需要传输，这会使你的网络过于紧张。图17-13显示了一个多宿主防火墙是如何为可信网络提供安全的。

图17-13 多宿主防火墙

你可以看到DMZ是如何保护可信主机的，仍然不为非可信网络提供任何服务。这是因为许多入站信息流通常在到达内部网络之前先通过DMZ堡垒主机。这也使网络数据包增加了额外的跳数（hop），你会发现这种配置也会使一些并不受欢迎的信息进入你的网络。

（4）其他防火墙结构

你可以设计多种其他的防火墙结构，在包含有Internet通路和Extranet（外部网）的网络中，你可以设置若干DMZ，你还可以用路由器把内部网络和DMZ分段。这样，可信网络和其他网络及DME就分段处理了。图17-14显示了一个可以通到Internet的Extranet和将可信网络分成两段的内部过滤路由器。

图17-14 多宿主Extranet和公共DMZ防火墙

还有多种上述方案的组合。然而，你的防火墙越复杂，你就得花更多的精力去维护系统的安全性。同样,"检查站"越多，你就越需要仔细地配置传输的通过规则。

二、防火墙与安全外壳

如果你的防火墙还没有为安全shell提供服务选项,你就会考虑它。安全shell的工作机理与其他的TCP/IP服务如Telnet,NTP,POP等稍有不同。本节探讨一些你需要为安全shell设置的基本配置，以及需要为SOCKS（一种应用代理）做的一些工作。

1．基本配置

正如所知,SSH守护(包括SSH1和SSH2)监听端口22，除非你以其他方式进行了配置。如果你想接受安全shell连接的话,你就必须将这个端口对入站流量开放。

对客户端来说,你需要打开客户连接的端口。在通常情况下，大多数应用程序的客户端使用高于1023的端口，这些端口是非特权端口。这意味着典型的客户连接到一个正在监听1024或更高端口的服务器。安全shell则以一种有趣的方式工作——它连接到1021或更高的端口。当然，也可以改变安全shell——尤其是当你具有unix客户代码时——将其连接到1024或更高端口。

你可以看到信息的流向和手动地通过包过滤器来配置安全shell或在应用程序网关或状态检查器上设立一个通用规则集是多么有趣的事情。这可能是你在配置包过滤器或应用程序网关时所要做的事情。它意味着你正在使用的防火墙并没有任何已定型的到达SSH的通路。正如所见，这也很容易变得很乱。

2．防火墙配置

为了进行基本的防火墙配置，需要考虑如何将你的网络连接到Internet上。如果你已在使用Telnet到Internet,你可能会考虑用安全shell来代替,这将使你的数据读取及你的信息被劫持的危险大大降低。你也可以创建一个使用安全shell在两个防火墙之间进行连接的伪虚拟私有网络(VPN)。

现在，你正在使用的防火墙为安全shell提供了规则集，你不必手动地来设置。如果你正在使用一个包过滤器或者要手动输入规则集的防火墙,你就应该耐心地阅读防火墙手册或文档，以清楚地了解安全shell的配置方式。记住，安全shell是一个基于TCP而不是UDP（User Datagram Protocol,用户数据报协议）的应用程序。把那些客户程序放在一个与原有安全Shell不同的目录中。例如，原有安全Shell通常放在/usr/local/bin目录中，但你可能想将SOCKS化的应用程序放到另外一个目录中，如/usr/local/socksify/bin。