SSH协议简介.doc

SSH协议简介 目 录 目 录1 一、前言2 二、UNIX及Linux中常用的SSH2 三、SSH中用户认证方式2 1.概述2 2.认证过程3 2.1.认证请求3 2.2.认证请求的应答4 2.3.认证的完成4 2.4.其他4 3.用户认证方式5 3.1.公开密钥认证方法5 3.2.口令认证方法6 3.3.基于主机的认证方法8 四、SSH1与SSH2的主要区别概述9 1.SSH19 2.SSH29 1. 前言 SSH的英文全称为Secure Shell，是IETF（Internet Engineering Task Force）的Network Working Group所制定的一族协议，其目的是要在非安全网络上提供安全的远程登录和其他安全网络服务。 SSH（Secure Shell）是以远程联机服务方式操作服务器时的较为安全的解决方案。它最初由芬兰的一家公司开发，但由于受版权和加密算法的限制，很多人转而使用免费的替代软件OpenSSH。 用户通过SSH可以把所有传输的数据进行加密，使中间人的攻击方式不可能实现，而且也能够防止DNS和IP欺骗。它还有一个额外的好处是传输的数据是经过压缩的，可以加快传输的速度。SSH作用广泛，既可以代替Telnet，又可以为FTP、POP，甚至为PPP提供一个安全的通道。SSH协议在预设的状态中，提供两个服务器功能：一个是类似Telnet的远程联机使用Shell服务器，即俗称SSH功能；另一个是类似FTP服务的SFTP-Server功能，可提供更安全的FTP服务。 如需要SSH的详细信息请参考（SSH Communications Security Corporation的网站）和（开放源码的OpenSSH组织的网站）。本文将要介绍的是SSH协议体系中的用户认证机制和基本认证方法。 1. UNIX及Linux中常用的SSH 在UNIX/Linux系统中，为了实现主机与客户端之间的数据安全传输，通常采用SSH协议进行连接。 在ScoUNIX5.07及以上版本中，系统安装时默认已安装sshd，即SSH的服务端程序，这些默认安装的版本支持SSH1和SSH2. 在较新的众多的Linux版本中，也都已经支持SSH，其中较多使用OpenSSH且大都支持SSH1和SSH2. 1. SSH中用户认证方式 1. 概述 在SSH协议中，用户认证是由服务器方来主导进行的。服务器先向客户机说明有哪些认证方法可以使用，之后的认证过程中，客户机则可以根据情况选择一种或几种认证方法来继续认证操作。服务器对多种认证方法的支持给客户机带来很大的灵活性，使用户得到最大可能的便利，同时也增强了协议的实用性。 在SSH协议体系中，所有认证方法都是通过名字来标识的。有一个特殊的认证方法名为none，是系统保留的。如果客户机试图通过none方法来连接服务器，服务器在通常情况下就将自己所支持的所有认证方法清单作为应答发还给该客户机。一个极端的情况：当某个客户机已经被免除任何认证时，服务器收到它的一个none请求时就会无条件接受。 SSH协议对服务器的用户认证过程有一个超时限制，一般建议为10分钟，也就是说如果10分钟内还没有完成认证，服务器就断开连接。同样，客户机认证如果失败可以重试，但是重试的次数也是有限制的，协议建议为20次。 1. 认证过程 典型的认证过程如下图1所示： 1. 认证请求 SSH协议中认证请求的消息格式如下： byte SSH_MSG_USERAUTH_REQUEST string 用户名 (采用ISO-10646 UTF-8 编码 RFC2279) string 服务名 (采用 US-ASCII字符集) string 认证方法名 (采用US-ASCII字符集) 包的其余部分根据具体认证方法而变化。 在一次服务会话的认证过程中，用户名和服务名这两个域的内容是不会变化的，服务器一旦发现它们有所变化，则必须将此次会话中的认证状态复原，如果状态不能复原，那么服务器就断开连接以防欺诈。服务名指定了用户所请求的服务，如果该服务不可用，则服务器必须断开连接。用户名则指明了用户的身份，如果服务器上没有该用户名，可以给客户端应答一些伪造的认证方法名，以混淆客户机的视听，避免泄漏本机的帐号信息。 比如，当客户机使用用户名tom来请求认证，而服务器上没有tom这个帐号，服务器如果直接拒绝访问，那么客户端程序就可以知道原来服务器上没有tom这个帐号。所以服务器采取一个策略，它并不直接拒绝请求，而是告诉客户机要使用a、b、c等认证方法继续认证，其实a、b、c这三种方法都是服务器为了混淆视听而伪造的认证方法。客户机接下来就会按照要求去使用这些伪造的认证方法a、b、c去请求认证，这些认证理所当然地会被拒绝。这么一来，客户机程序就比较难以判断是否是因为用户名错误而引起的认证失败，从而在一定程度上保护了服务器上的用户帐号信息。 客户机可以连续给服务器发送若干认证请求，如果其中某种认证方法不被服务器支持，那么服务器就直接拒绝相应的请求。如果服务器正在处理某个认证请求时又收到同一客户的一个新的认证请求，那么旧的请求被放弃，服务器以新请求开始重新认证。 1. 认证请求的应答 如果服务器拒绝了一个认证请求，它必须给出下面格式的应答信息： byte SSH_MSG_USERAUTH_FAILURE string 一个可用的认证方法列表 boolean 是否成功的标志 在拒绝请求的应答消息中，除了必须把成功标志的布尔量设置成假以外，还给出一串以逗号分隔的认证方法的名字。这个消息告诉客户机：你的前一个请求被拒绝了，请使用所给出的认证方法名字继续尝试请求。 当服务器接受认证请求，必须给出如下应答： byte SSH_MSG_USERAUTH_SUCCESS 因为SSH协议允许服务器主导认证过程，并支持采用多种认证方法，所以服务器只是在整个认证过程全部完成后才会发送认证成功的消息。比如，某一次认证过程中服务器需要进行a、b、c三种方法的认证，其典型过程如下： （1） 客户机发送了一个none认证请求； （2） 服务器接收到none请求后应答给客户机一个请求失败消息，并附带了a、b、c三种认证方法名字； （3） 客户机收到应答后使用a方法再次请求； （4） 服务器通过了a方法的认证后再次应答一个请求失败的消息，并附带了两种认证方法，即b和c； （5） 客户机收到应答后继续使用b方法发送请求； （6） 服务器通过了b方法的认证后应答一个请求失败的消息，并附带了c这个认证方法名； （7） 客户机收到应答后使用c方法再次请求认证； （8） 服务器通过了c方法的认证后，应答一个认证成功的消息，从而结束了整个认证过程。 需要说明的是，在一次会话中，一旦服务器向客户机发出认证成功的应答之后就会忽略此后的本会话中所有的认证请求消息。如果服务器在认证成功之前收到客户机的一些非认证消息，则等到认证成功之后，这些消息才会被传递给相应的服务进行处理，相当于有了一个缓冲。 1. 认证的完成 认证过程的完成是以一个认证成功的应答消息来标记的，服务器在发送SSH_MSG_USERAUTH_SUCCESS消息之后，就开始提供客户机所请求的服务了。 1. 其他 SSH协议支持在认证过程中显示标语，标语消息的格式如下： byte SSH_MSG_USERAUTH_BANNER string 消息内容(ISO-10646 UTF-8编码) string 语言标记 (定义在RFC1766中) 客户机在默认情况下应当把这个消息的内容显示在屏幕上。在处理这些信息的显示时，需要采取一定的过滤措施来避免那些通过发送终端控制字符来进行网络攻击的行为，以保证安全。 SSH认证协议中的主要消息就是本节所描述的四类，消息编码如下： SSH_MSG_USERAUTH_REQUEST 50 SSH_MSG_USERAUTH_FAILURE 51 SSH_MSG_USERAUTH_SUCCESS 52 SSH_MSG_USERAUTH_BANNER 53 1. 用户认证方式 1. 公开密钥认证方法 在这种方法中，拥有一个私有密钥就解决了认证问题。这种方法使用用户的私有密钥产生一个签名并发送给服务器，服务器则必须验证这个密钥是该用户身份的有效证明，同时还必须验证签名的有效性。如果两者都验证通过，服务器就接受这个认证请求，否则就拒绝。即使通过了公开密钥认证，服务器也还是可以要求进一步做其他认证的。 私有密钥经常是以加密的形式存储在客户机上，在产生签名之前，用户必须提供一个密码。即使私有密钥没有加密，签名的操作也会需要占用一些宝贵的计算资源。为了避免不必要的处理和多余的用户交互，下面的消息提供了一个功能，可以用来查询是否认证使用这个密钥会被接受。 byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string publickey boolean FALSE string 公开密钥算法名字 string public key blob 公开密钥算法是在传输层协议文档中进行定义的SSH-TRANS。消息中的public key blob应该包含具体的证明内容，实际就是用户的公开密钥。服务器收到这个消息，就按照算法名字来检查是否可用，如果不可用就予以拒绝，也就是给予客户机一个SSH_MSG_USERAUTH_FAILURE应答。如果该算法可用，服务器就发送一个下述的应答消息： byte SSH_MSG_USERAUTH_PK_OK string 请求消息中指明的公开密钥算法 string 请求消息的public key blob 在收到这个消息后，客户机再发送一个用私有密钥产生的签名。当然客户机也可以直接发送签名而不事先去验证密钥是否能够被服务器接受，也就是说没有上面的一问一答两个消息。发送签名的消息其包格式如下： byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string publickey boolean TRUE string 公开密钥算法名字 string 用来进行认证的公开密钥 string 签名信息 签名信息的内容其实也就是用相应的私有密钥加密过的数据，数据格式如下： string 会话标识 byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string publickey boolean TRUE string 公开密钥算法名字 string 用来进行认证的公开密钥 当服务器收到这个消息的时候，它必须首先检查所提供的密钥是否可以用来进行认证，如果是，它还必须检查是否签名是正确的。如果两项均通过验证，这个认证方法就成功了。 典型的公开密钥认证方法过程可以示意如图2： 1. 口令认证方法 SSH协议的任何实现版本中都必须支持口令认证方法。在口令认证方法中，服务器可以根据需要要求用户修改自己的口令。 byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string password boolean FALSE string 纯文本格式的口令（ISO-10646 UTF-8编码） 上面是一个用户认证的消息，它指明了认证方法是password，即口令方法。唯一的布尔域指明是否修改用户口令，布尔值为假时，消息中只包含用户原来的口令。在认证消息中，口令是采用ISO-10646 UTF-8编码的，客户端和服务器端均可以根据需要将编码格式转换到各自环境下所需要的格式。 还有，就是在产生这样一个认证消息包的时候，口令数据是不做加密处理的，因为SSH协议中的保密机制是由传输层来承担的。 通常情况，服务器对上面这个消息给出一个成功或者失败的应答。然而服务器也可以给出一个SSH_MSG_USERAUTH_PASSWD_CHANGEREQ消息来作为应答。 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string 提示信息（ISO-10646 UTF-8编码） string 语言标记（具体定义见RFC1766） 这个应答消息就是要求用户修改自己的口令。此时，客户端软件应当要求用户输入一个新的口令，然后再向服务器发送一个新的请求消息，格式如下： byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string password boolean TRUE string 纯文本格式的旧口令（ISO-10646 UTF-8编码） string 纯文本格式的新口令（ISO-10646 UTF-8编码） 客户机也可以在认证一开始就发送这个消息，也就是说无论服务器是否要求用户修改口令，客户端都要求用户修改自己的口令。这样，口令认证方法的过程可以总结如下图3： 1. 基于主机的认证方法 基于主机的认证方法是SSH协议中一个可选的方法，允许在有些实现版本中不支持它。这种方法就是根据用户所在的主机和远程主机的用户名来进行认证，虽然这种认证方法在安全要求很高的场合并不适用，但是它确实在很多环境下非常方便。如果协议支持了这种认证方法，那就应当特别注意，要保证一个普通的用户无法得到私有的主机密钥。 在这种认证方法中，客户机使用自己的私有主机密钥产生一个签名，发送给服务器，服务器则用这个主机的公开密钥来进行验证。一旦客户主机的身份被确定，认证过程就根据服务器和客户机上的用户名字和客户端的主机名字来进行。基于主机的认证请求消息格式如下： byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string hostbased string 主机密钥的公开密钥算法 string 客户主机的公开主机密钥和证书 string 客户端主机名字（FQDN; US-ASCII） string 远程客户机上的用户名（ISO-10646 UTF-8） string 签名信息 请求消息中的签名信息是用私有主机密钥加密过的数据，其内容如下： string 会话标识 byte SSH_MSG_USERAUTH_REQUEST string 用户名 string 服务名 string hostbased string 主机密钥的公开密钥算法 s