1、什么是SSH ？
传统的网络服务程序，如FTP、Pop和Telnet在传输机制和实现原理上是没有考虑安全机制的，在网络上用明文传送数据、用户帐号和用户口令，这些网络服务程序的简单安全验证方式也有其弱点，那就是很容易受到"中间人"（man-in-the-middle）这种***方式的***.
SSH是英文Secure Shell的简写形式。通过使用SSH，你可以把所有传输的数据进行加密，这样"中间人"这种***方式就不可能实现了，而且也能够防止DNS欺骗和IP欺骗。使用SSH，还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。SSH有很多功能，它既可以代替Telnet，又可以为FTP、Pop、甚至为PPP提供一个安全的"通道"。
最初的SSH是由芬兰的一家公司开发的。但是因为受版权和加密算法的限制，现在多使用OpenSSH。OpenSSH是SSH的替代软件包，而且是免费的。
最后，SSH在运行方式上也很有特色。不像其他的TCP/IP应用，SSH被设计为工作于自己的基础之上，而不是利用包装（wrappers）或通过Internet守护进程inetd。但是许多人想通过TCP包装来运行SSH守护进程。虽然你可以通过tcpd（从inetd上运行启动）来运行SSH进程，但这完全没有必要。
2、SSH协议的内容(协议框架)
SSH协议是建立在应用层和传输层基础上的安全协议，它主要由以下三部分组成，共同实现SSH的安全保密机制。
传输层协议，它提供诸如认证、信任和完整性检验等安全措施，此外它还可以任意地提供数据压缩功能。通常情况下，这些传输层协议都建立在面向连接的TCP数据流之上。
用户认证协议层，用来实现服务器的跟客户端用户之间的身份认证，它运行在传输层协议之上。
连接协议层，分配多个加密通道至一些逻辑通道上，它运行在用户认证层协议之上。
当安全的传输层连接建立之后，客户端将发送一个服务请求。当用户认证层连接建立之后将发送第二个服务请求。这就允许新定义的协议可以和以前的协议共存。连接协议提供可用作多种目的通道，为设置安全交互Shell会话和传输任意的TCP/IP端口和X11连接提供标准方法。
3、SSH的安全验证
从客户端来看，SSH提供两种级别的安全验证。
第一种级别（基于口令的安全验证），只要你知道自己的帐号和口令，就可以登录到远程主机，并且所有传输的数据都会被加密。但是，这种验证方式不能保证你正在连接的服务器就是你想连接的服务器。可能会有别的服务器在冒充真正的服务器，也就是受到"中间人"这种***方式的***。
第二种级别（基于密匙的安全验证），需要依靠密匙，也就是你必须为自己创建一对密匙，并把公有密匙放在需要访问的服务器上。如果你要连接到SSH服务器上，客户端软件就会向服务器发出请求，请求用你的公有密匙进行安全验证。服务器收到请求之后，先在你在该服务器的用户根目录下寻找你的公有密匙，然后把它和你发送过来的公有密匙进行比较。如果两个密匙一致，服务器就用公有密匙加密"质询"（challenge）并把它发送给客户端。客户端软件收到"质询"之后就可以用你的私人密匙解密再把它发送给服务器。
与第一种级别相比，第二种级别不需要在网络上传送用户口令。
4、SSH的应用
首先，SSH最常见的应用就是，用它来取代传统的Telnet、FTP等网络应用程序，通过SSH登录到远方机器执行你想进行的工作与命令。在不安全的网路通讯环境中，它提供了很强的验证（authentication）机制与非常安全的通讯环境。实际上，SSH开发者的原意是设计它来取代原UNIX系统上的rcp、rlogin、rsh等指令程序的；但经过适当包装后，发现它在功能上完全可以取代传统的Telnet、FTP等应用程序。
传统 BSD 风格的 r 系列指令（如 rcp，rsh，rlogin）往往都被视为不安全的，很容易就被各种网络***手段所破解，几乎所有找得到有关UNIX安全的书或文件，都会一而再、再而三地警告系统管理者，留心r系列指令的设定，甚至要求系统管理者将r系列指令通通关闭。
而用来替代r系列指令的SSH，则在安全方面做了极大的强化，不但对通讯内容可以进行极为安全的加密保护，同时也强化了对身份验证的安全机制，它应用了在密码学（Cryptography）中已发展出来的数种安全加密机制，如 Symmetric Key Cryptography，Asymmetric Key Cryptography， One-way Hash Function，Random-number Generation等，来加强对于身份验证与通讯内容的安全保护。有IDEA，three-key triple DES，DES，RC4-128，TSS，Blowfish 等数种多种安全加密算法可供选择，加密的key则是通过 RSA 进行交换的。资料的加密可以对抗IP spoofing，RSA这种非对称性的加密机制则可用来对抗DNS spoofing与IP routing spoofing，同时RSA也可以进行对主机身份的验证。
其次，通过使用用SSH可以在本地主机和远程服务器之间设置"加密通道"，并且这样设置的"加密通道"可以跟常见的Pop应用程序、X应用程序、Linuxconf应用程序相结合，提供安全保障。 SSH的"加密通道"是通过"端口转发"来实现的。你可以在本地端口（没有用到的）和在远程服务器上运行的某个服务的端口之间建立"加密通道"。然后只要连接到本地端口。所有对本地端口的请求都被SSH加密并且转发到远程服务器的端口。当然只有远程服务器上运行SSH服务器软件的时候"加密通道"才能工作。
5、主机密钥机制
对于SSH这样以提供安全通讯为目标的协议，其中必不可少的就是一套完备的密钥机制。由于SSH协议是面向互联网网络中主机之间的互访与信息交换，所以主机密钥成为基本的密钥机制。也就是说，SSH协议要求每一个使用本协议的主机都必须至少有一个自己的主机密钥对，服务方通过对客户方主机密钥的认证之后，才能允许其连接请求。一个主机可以使用多个密钥，针对不同的密钥算法而拥有不同的密钥，但是至少有一种是必备的，即通过DSS算法产生的密钥。SSH协议关于主机密钥认证的管理方案有两种，如下图所示： 
每一个主机都必须有自己的主机密钥，密钥可以有多对，每一对主机密钥对包括公开密钥和私有密钥。在实际应用过程中怎样使用这些密钥，并依赖它们来实现安全特性呢？如上图所示，SSH协议框架中提出了两种方案。
在第一种方案中，主机将自己的公用密钥分发给相关的客户机，客户机在访问主机时则使用该主机的公开密钥来加密数据，主机则使用自己的私有密钥来解密数据，从而实现主机密钥认证，确定客户机的可靠身份。在图（a）中可以看到，用户从主机A上发起操作，去访问，主机B和主机C，此时，A成为客户机，它必须事先配置主机B和主机C的公开密钥，在访问的时候根据主机名来查找相应的公开密钥。对于被访问主机（也就是服务器端）来说则只要保证安全地存储自己的私有密钥就可以了。
在第二种方案中，存在一个密钥认证中心，所有系统中提供服务的主机都将自己的公开密钥提交给认证中心，而任何作为客户机的主机则只要保存一份认证中心的公开密钥就可以了。在这种模式下，客户机在访问服务器主机之前，还必须向密钥认证中心请求认证，认证之后才能够正确地连接到目的主机上。
很显然，第一种方式比较容易实现，但是客户机关于密钥的维护却是个麻烦事，因为每次变更都必须在客户机上有所体现；第二种方式比较完美地解决管理维护问题，然而这样的模式对认证中心的要求很高，在互联网络上要实现这样的集中认证，单单是权威机构的确定就是个大麻烦，有谁能够什么都能说了算呢？但是从长远的发展来看，在企业应用和商业应用领域，采用中心认证的方案是必要的。
另外，SSH协议框架中还允许对主机密钥的一个折中处理，那就是首次访问免认证。首次访问免认证是指，在某客户机第一次访问主机时，主机不检查主机密钥，而向该客户都发放一个公开密钥的拷贝，这样在以后的访问中则必须使用该密钥，否则会被认为非法而拒绝其访问。
6、字符集和数据类型
SSH协议为了很好地支持全世界范围的扩展应用，在字符集和信息本地化方面作了灵活的处理。首先，SSH协议规定，其内部算法标识、协议名字等必须采用US-ASCII字符集，因为这些信息将被协议本身直接处理，而且不会用来作为用户的显示信息。其次，SSH协议指定了通常情况下的统一字符集为ISO 10646标准下的UTF-8格式，详细请参考RFC-2279。另外，对于信息本地化的应用，协议规定了必须使用一个专门的域来记录语言标记（Language Tag）。对于大多数用来显示给用户的信息，使用什么样的字符集主要取决于用户的终端系统，也就是终端程序及其操作系统环境，因而对此SSH协议框架中没有作硬性规定，而由具体实现协议的程序来自由掌握。
除了在字符、编码方面的灵活操作外，SSH协议框架中还对数据类型作了规定，提供了七种方便实用的种类，包括字节类型、布尔类型、无符号的32位整数类型、无符号的64位整数类型、字符串类型、多精度整数类型以及名字表类型。
7、命名规则及消息编码
SSH协议在使用到特定的哈希算法，加密算法，完整性算法，压缩算法，以及密钥交换算法和其他协议时都利用名字来区分，所以SSH协议框架中很重要的一个部分就是命名规则的限定。无论是SSH协议框架中所必备的算法或者协议，还是今后具体应用实现SSH协议时增加的算法或者协议，都必须遵循一个统一的命名规则。
SSH协议框架对命名规则有一个基本原则：所有算法标识符必须是不超过64个字符的非空、可打印US-ASCII字符串；名字必须是大小写敏感的。
具体的算法命名有两种格式：
（1）不包含@符号的名字都是为IETF标准（RFC文档）保留的。比如，“3des-cbc”，“sha-1”，“hmac-sha1”，“zlib”（注意：引号不是名字的一部分)。在没有事先注册之前，这种格式的名字是不能使用的。当然IETF的所有注册的名字中也不能包含@符号或者逗号。
（2）任何人都可以使用“name@domainname”的格式命名自定义的算法，比如“[email protected]”。在@符号之前部分的具体格式没有限定，不过这部分中必须使用除@符号和逗号之外的US-ASCII字符。在@符号之后的部分则必须是一个完全合法的Internet域名（参考[RFC-1034]），个人域名和组织域名均可。至于局部名字空间的管理则是由各个域自行负责的。
SSH协议框架中另一个主要的标准化规则就是消息编码，基本规定在表1中详述： 
8、SSH协议的可扩展能力
SSH协议框架中设计了大量可扩展的冗余能力，比如用户自定义算法、客户自定义密钥规则、高层扩展功能性应用协议等，在本文中将不一一赘述。值得一提的是，这些扩展大多遵循IANA（Internet Assigned Numbers Authority）的有关规定，特别是在重要的部分，象命名规则和消息编码方面。关于IANA的标准及组织情况请访问该组织的官方网站：http://www.iana.org。
9.SSH通信简述
整个通讯过程中，经过下面几个阶段协商实现认证连接。
第一阶段:(协商版本)
由客户端向服务器发出 TCP 连接请求。TCP 连接建立后，客户端进入等待，服务器向客户端发送第一个报文，宣告自己的版本号，包括协议版本号和软件版本号。协议版本号由主版本号和次版本号两部分组成。它和软件版本号一起构成形如："SSH-<主协议版本号>.<次协议版本号>-<软件版本号>\n"的字符串。其中软件版本号字符串的最大长度为40个字节，仅供调试使用。客户端接到报文后，回送一个报文，内容也是版本号。客户端响应报文里的协议版本号这样来决定：当与客户端相比服务器的版本号较低时，如果客户端有特定的代码来模拟，则它发送较低的版本号；如果它不能，则发送自己的版本号。当与客户端相比服务器的版本号较高时，客户端发送自己的较低的版本号。按约定，如果协议改变后与以前的相兼容，主协议版本号不变；如果不相兼容，则主主协议版本号升高。
服务器接到客户端送来的协议版本号后，把它与自己的进行比较，决定能否与客户端一起工作。如果不能，则断开TCP 连接；如果能，则按照二进制数据包协议发送第一个二进制数据包，双方以较低的协议版本来一起工作。到此为止，这两个报文只是简单的字符串，你我等凡人直接可读。
第二阶段: (协商加密和认证方法,交换会话密钥)
协商解决版本问题后，双方就开始采用二进制数据包进行通讯。由服务器向客户端发送第一个包，内容为自己的 RSA主机密钥(host key)的公钥部分、RSA服务密钥(server key)的公钥部分、支持的加密方法、支持的认证方法、次协议版本标志、以及一个 64 位的随机数(cookie)。这个包没有加密，是明文发送的。客户端接收包后，依据这两把密钥和被称为cookie的 64 位随机数计算出会话号(session id)和用于加密的会话密钥(session key)。随后客户端回送一个包给服务器，内容为选用的加密方法、cookie的拷贝、客户端次协议版本标志、以及用服务器的主机密钥的公钥部分和服务密钥的公钥部分进行加密的用于服务器计算会话密钥的32 字节随机字串。除这个用于服务器计算会话密钥的 32字节随机字串外，这个包的其他内容都没有加密。之后，双方的通讯就是加密的了，服务器向客户端发第二个包（双方通讯中的第一个加密的包）证实客户端的包已收到。
第三阶段: (身份认证)
双方随后进入认证阶段。可以选用的认证的方法有：
(1) ~/.rhosts 或 /etc/hosts.equiv 认证（缺省配置时不容许使用它）;
(2) 用 RSA 改进的 ~/.rhosts 或 /etc/hosts.equiv 认证；
(3) RSA 认证；
(4) 口令认证。
如果是使用 ~/.rhosts 或 /etc/hosts.equiv 进行认证，客户端使用的端口号必须小于1024。
认证的第一步(确定用户是否存在)是客户端向服务器发 SSH_CMSG_USER 包声明用户名，服务器检查该用户是否存在，确定是否需要进行认证。如果用户存在，并且不需要认证，服务器回送一个SSH_SMSG_SUCCESS 包，认证完成。否则，服务器会送一个 SSH_SMSG_FAILURE 包，表示或是用户不存在，或是需要进行认证。注意，如果用户不存在，服务器仍然保持读取从客户端发来的任何包。除了对类型为 SSH_MSG_DISCONNECT、SSH_MSG_IGNORE 以及 SSH_MSG_DEBUG 的包外，对任何类型的包都以 SSH_SMSG_FAILURE 包。用这种方式，客户端无法确定用户究竟是否存在。
如果用户存在但需要进行认证，进入认证的第二步(确定认证方式)。客户端接到服务器发来的 SSH_SMSG_FAILURE 包后，不停地向服务器发包申请用各种不同的方法进行认证，直到时限已到服务器关闭连接为止。时限一般设定为 5 分钟。对任何一个申请，如果服务器接受，就以 SSH_SMSG_SUCCESS 包回应；如果不接受，或者是无法识别，则以 SSH_SMSG_FAILURE 包回应。
第四阶段: 会话请求
认证完成后，客户端向服务器提交会话请求。服务器则进行等待，处理客户端的请求。在这个阶段，无论什么请求只要成功处理了，服务器都向客户端回应 SSH_SMSG_SUCCESS包；否则回应 SSH_SMSG_FAILURE 包，这表示或者是服务器处理请求失败，或者是不能识别请求。会话请求分为这样几类：申请对数据传送进行压缩、申请伪终端、启动 X11、TCP/IP 端口转发、启动认证代理、运行 shell、执行命令。到此为止，前面所有的报文都要求 IP 的服务类型(TOS)使用选项 IPTOS_THROUGHPUT。
第五阶段: 交互会话
会话申请成功后，连接进入交互会话模式。在这个模式下，数据在两个方向上双向传送。此时，要求 IP 的服务类型(TOS)使用 IPTOS_LOWDELAY 选项。当服务器告知客户端自己的退出状态时，交互会话模式结束。
（注意：进入交互会话模式后，加密被关闭。在客户端向服务器发送新的会话密钥后，加密重新开始。用什么方法加密由客户端决定。）
10.安装并测试OpenSSH
可以从网络上下载并安装OpenSSH（有关OpenSSH的安装和配置请参考：http://www.linuxaid.com.cn/engineer/brimmer/html/OpenSSH.htm）。
安装完OpenSSH之后，用下面命令测试一下：
ssh -l [your accountname on the remote host] [address of the remote host]
如果OpenSSH工作正常，你会看到下面的提示信息：
The authenticity of host [hostname] can't be established.
Key fingerprint is 1024 5f:a0:0b:65:d3:82:df:ab:44:62:6d:98:9c:fe:e9:52.
Are you sure you want to continue connecting (yes/no)?
OpenSSH告诉你它不知道这台主机，但是你不用担心这个问题，因为你是第一次登录这台主机。键入“yes”。这将把这台主机的“识别标记”加到“~/.ssh/know_hosts”文件中。第二次访问这台主机的时候就不会再显示这条提示信息了。
然后，SSH提示你输入远程主机上你的帐号的口令。输入完口令之后，就建立了SSH连接，这之后就可以象使用telnet那样使用SSH了。
SSH的密匙
生成你自己的密匙对
生成并分发你自己的密匙有两个好处：
1) 可以防止“中间人”这种***方式
2) 可以只用一个口令就登录到所有你想登录的服务器上
用下面的命令可以生成密匙：
ssh-keygen
如果远程主机使用的是SSH 2.x就要用这个命令：
ssh-keygen –d
在同一台主机上同时有SSH1和SSH2的密匙是没有问题的，因为密匙是存成不同的文件的。
ssh-keygen命令运行之后会显示下面的信息：
Generating RSA keys: ............................ooooooO......ooooooO
Key generation complete.
Enter file in which to save the key (/home/[user]/.ssh/identity):
[按下ENTER就行了]
Created directory '/home/[user]/.ssh'.
Enter passphrase (empty for no passphrase):
[输入的口令不会显示在屏幕上]
Enter same passphrase again:
[重新输入一遍口令，如果忘记了口令就只能重新生成一次密匙了]
Your identification has been saved in /home/[user]/.ssh/identity.
[这是你的私人密匙]
Your public key has been saved in /home/[user]/.ssh/identity.pub.
The key fingerprint is: 2a:dc:71:2f:27:84:a2:e4:a1:1e:a9:63:e2:fa:a5:89 [user]@[local machine]
“ssh-keygen –d”做的是几乎同样的事，但是把一对密匙存为（默认情况下）“/home/[user]/.ssh/id_dsa”（私人密匙）和“/home/[user]/.ssh/id_dsa.pub”（公用密匙）。
现在你有一对密匙了：公用密匙要分发到所有你想用ssh登录的远程主机上去；私人密匙要好好地保管防止别人知道你的私人密匙。用“ls –l ~/.ssh/identity”或“ls –l ~/.ssh/id_dsa”所显示的文件的访问权限必须是“-rw-------”。
如果你怀疑自己的密匙已经被别人知道了，不要迟疑马上生成一对新的密匙。当然，你还要重新分发一次公用密匙。
分发公用密匙
在每一个你需要用SSH连接的远程服务器上，你要在自己的家目录下创建一个“.ssh”的子目录，把你的公用密匙“identity.pub” 拷贝到这个目录下并把它重命名为“authorized_keys”。然后执行：
chmod 644 .ssh/authorized_keys
这一步是必不可少的。如果除了你之外别人对“authorized_keys”文件也有写的权限，SSH就不会工作。
如果你想从不同的计算机登录到远程主机，“authorized_keys”文件也可以有多个公用密匙。在这种情况下，必须在新的计算机上重新生成一对密匙，然后把生成的“identify.pub”文件拷贝并粘贴到远程主机的“authorized_keys”文件里。当然在新的计算机上你必须有一个帐号，而且密匙是用口令保护的。有一点很重要，就是当你取消了这个帐号之后，别忘了把这一对密匙删掉。
9.配置SSH客户端
OpenSSH有三种配置方式：命令行参数、用户配置文件和系统级的配置文件（“/etc/ssh/ssh_config”）。命令行参数优先于配置文件，用户配置文件优先于系统配置文件。所有的命令行的参数都能在配置文件中设置。因为在安装的时候没有默认的用户配置文件，所以要把“/etc/ssh/ssh_config”拷贝并重新命名为“~/.ssh/config”。
标准的配置文件大概是这样的：
[lots of explanations and possible options listed]
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
还有很多选项的设置可以用“man ssh”查看“CONFIGURATION FILES”这一章。
配置文件是按顺序读取的。先设置的选项先生效。
假定你在www.foobar.com上有一个名为“bilbo”的帐号。而且你要把“ssh-agent”和“ssh-add”结合起来使用并且使用数据压缩来加快传输速度。因为主机名太长了，你懒得输入这么长的名字，用“fbc”作为“www.foobar.com”的简称。你的配置文件可以是这样的：
Host *fbc
HostName www.foobar.com
User bilbo
ForwardAgent yes
Compression yes
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
你输入“ssh fbc”之后，SSH会自动地从配置文件中找到主机的全名，用你的用户名登录并且用“ssh-agent”管理的密匙进行安全验证。这样很方便吧！
用SSH连接到其它远程计算机用的还是“paranoid（偏执）”默认设置。如果有些选项没有在配置文件或命令行中设置，那么还是使用默认的“paranoid”设置。
在我们上面举的那个例子中，对于到www.foobar.com的SSH连接：“ForwardAgent”和“Compression”被设置为“Yes”；其它的设置选项（如果没有用命令行参数）“ForwardX11”和“FallBackToRsh”都被设置成“No”。
其它还有一些需要仔细看一看的设置选项是：
l CheckHostIP yes
这个选项用来进行IP地址的检查以防止DNS欺骗。
l CompressionLevel
压缩的级别从“1”（最快）到“9”（压缩率最高）。默认值为“6”。
l ForwardX11 yes
为了在本地运行远程的X程序必须设置这个选项。
l LogLevel DEBUG
当SSH出现问题的时候，这选项就很有用了。默认值为“INFO”。