由SecureCRT引发的思考和学习

jopen 8年前

前言

由于业务需要，最近在云上新购买了一批centos7.0的服务器,用脚本批量添加了用户（脚本请见我之前的博客/秘钥认证用户自动控制:http://my.oschina.net/pwd/blog/388254）,加完秘钥之后发现,但是secureCRT 抛出了一下异常。

解决过程：

1.初步怀疑秘钥有问题,通过命令行去探测是否可以连接,-> ssh -i 秘钥文件 用户名@主机 ，发现能正常连接，确认秘钥是OK的。

2.可能出在secureCRT配置问题，具体操作不详解了,主要是涉及客户端一些可视化的设置,捣鼓完以后没好。

3.根据以上报错联想，可能是这个secureCrt 不支持以上的加密算法，上面已经明确的提示了，于是验证了xshell和putty，以及高版本的SecureCRT是可以连接.

常见终端客户端的介绍请戳链接: http://www.cnblogs.com/276815076/p/4409591.html 

由于低版本 SecreCRT 不支持 AES-128-CBC 这个 Cipher，而 Linux 下用 ssh-keygen 生成的公钥默认采用这个 Cipher 的，于是对应的私钥可能会加载不了,所以登陆不上。


思考和学习

参考: http://blog.csdn.net/macrossdzh/article/details/5691924

一、什么是SSH

SSH是英文Secure Shell的简写形式。通过使用SSH，你可以把所有传输的数据进行加密，这样"中间人"这种攻击方式就不可能实现了，而且也能够防止DNS欺骗和IP欺骗。使用SSH，还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。SSH有很多功能，它既可以代替Telnet，又可以为FTP、Pop、甚至为PPP提供一个安全的"通道"。

ssh工作原理简易介绍:

ssh

  • 服务器建立公钥： 每一次启动 sshd 服务时，该服务会主动去找 /etc/ssh/ssh_host* 的文件，若系统刚刚安装完成时，由于没有这些公钥，因此 sshd 会主动去计算出这些需要的公钥，同时也会计算出服务器自己需要的私钥

  • 客户端主动联机请求： 若客户端想要联机到 ssh 服务器，则需要使用适当的客户端程序来联机，包括 ssh, putty 等客户端程序连接

  • 服务器传送公钥给客户端： 接收到客户端的要求后，服务器便将第一个步骤取得的公钥传送给客户端使用 (此时应是明码传送，反正公钥本来就是给大家使用的)

  • 客户端记录并比对服务器的公钥数据及随机计算自己的公私钥： 若客户端第一次连接到此服务器，则会将服务器的公钥记录到客户端的用户家目录内的 ~/.ssh/known_hosts 。若是已经记录过该服务器的公钥，则客户端会去比对此次接收到的与之前的记录是否有差异。若接受此公钥， 则开始计算客户端自己的公私钥

  • 回传客户端的公钥到服务器端： 用户将自己的公钥传送给服务器。此时服务器：具有服务器的私钥与客户端的公钥，而客户端则是： 具有服务器的公钥以及客户端自己的私钥，你会看到，在此次联机的服务器与客户端的密钥系统 (公钥+私钥) 并不一样，所以才称为非对称加密系统

  • 开始双向加解密： (1)服务器到客户端：服务器传送数据时，拿用户的公钥加密后送出。客户端接收后，用自己的私钥解密 (2)客户端到服务器：客户端传送数据时，拿服务器的公钥加密后送出。服务器接收后，用服务器的私钥解密，这样就能保证通信安全

二、SSH 基本框架

SSH协议框架中最主要的部分是三个协议：

* 传输层协议（The Transport Layer Protocol）提供服务器认证，数据机密性，信息完整性 等的支持；（TCP/IP的传输层-第3层）

* 用户认证协议（The User Authentication Protocol） 则为服务器提供客户端的身份鉴别； （TCP/IP的应用层-第4层）

* 连接协议（The Connection Protocol） 将加密的信息隧道复用成若干个逻辑通道，提供给更高层的应用协议使用； 各种高层应用协议可以相对地独立于SSH基本体系之外，并依靠这个基本框架，通过连接协议使用SSH的安全机制。  （TCP/IP的应用层-第4层）

同时SSH协议框架中还为许多高层的网络安全应用协议提供扩展的支持。它们之间的层次关系可以用如下图来表示：

三、主机密钥机制

对于SSH这样以提供安全通讯为目标的协议，其中必不可少的就是一套完备的密钥机制。由于SSH协议是面向互联网网络中主机之间的互访与信息交换，所以主机密钥成为基本的密钥机制。也就是说，SSH协议要求每一个使用本协议的主机都必须至少有一个自己的主机密钥对，服务方通过对客户方主机密钥的认证之后，才能允许其连接请求。一个主机可以使用多个密钥，针对不同的密钥算法而拥有不同的密钥，但是至少有一种是必备的，即通过 DSS算法产生的密钥。关于DSS算法，请参考[FIPS-186]。

SSH协议关于主机密钥认证的管理方案有两种，如下图所示：

每一个主机都必须有自己的主机密钥，密钥可以有多对，每一对主机密钥对包括公开密钥和私有密钥。在实际应用过程中怎样使用这些密钥，并依赖它们来实现安全特性呢？如上图所示，SSH协议框架中提出了两种方案。

在第一种方案中，主机将自己的公用密钥分发给相关的客户机，客户机在访问主机时则使用该主机的公开密钥来加密数据，主机则使用自己的私有密钥来解密数据，从而实现主机密钥认证，确定客户机的可靠身份。在图2（a）中可以看到，用户从主机A上发起操作，去访问，主机B和主机C，此时，A成为客户机，它必须事先配置主机B和主机C的公开密钥，在访问的时候根据主机名来查找相应的公开密钥。对于被访问主机（也就是服务器端）来说则只要保证安全地存储自己的私有密钥就可以了。

在 第二种方案中，存在一个密钥认证中心，所有系统中提供服务的主机都将自己的公开密钥提交给认证中心，而任何作为客户机的主机则只要保存一份认证中心的公开 密钥就可以了。在这种模式下，客户机在访问服务器主机之前，还必须向密钥认证中心请求认证，认证之后才能够正确地连接到目的主机上。

很 显然，第一种方式比较容易实现，但是客户机关于密钥的维护却是个麻烦事，因为每次变更都必须在客户机上有所体现；第二种方式比较完美地解决管理维护问题， 然而这样的模式对认证中心的要求很高，在互联网络上要实现这样的集中认证，单单是权威机构的确定就是个大麻烦，有谁能够什么都能说了算呢？但是从长远的发 展来看，在企业应用和商业应用领域，采用中心认证的方案是必要的。

另外，SSH协议框架中还允许对主机密钥的一个折中处理，那就是首次访问免认证。首次访问免认证是指，在某客户机第一次访问主机时，主机不检查主机密钥，而向该客户都发放一个公开密钥的拷贝，这样在以后的访问中则必须使用该密钥，否则会被认为非法而拒绝其访问。

四、SSH 的工作过程

在整个通讯过程中，为实现 SSH的安全连接，服务器端与客户端要经历如下五个阶段：

    * 版本号协商阶段，SSH目前包括 SSH1和SSH2两个版本， 双方通过版本协商确定使用的版本

    * 密钥和算法协商阶段，SSH支持多种加密算法， 双方根据本端和对端支持的算法，协商出最终使用的算法

    * 认证阶段，SSH客户端向服务器端发起认证请求， 服务器端对客户端进行认证

    * 会话请求阶段， 认证通过后，客户端向服务器端发送会话请求

    * 交互会话阶段 ，会话请求通过后，服务器端和客户端进行信息的交互

1 . 版本号协商阶段

   1. 服务器打开端口 22，等待客户端连接。

   2. 客户端向服务器端发起 TCP初始连接请求，TCP连接建立后，服务器向客户端发送第一个报文，包括版本标志字符串，格式为“SSH－<主协议版本号>.<次协议版本号>－<软件版本号>”，协议版本号由主版本号和次版本号组成，软件版本号主要是为调试使用。

   3. 客户端收到报文后，解析该数据包，如果服务器端的协议版本号比自己的低，且客户端能支持服务器端的低版本，就使用服务器端的低版本协议号，否则使用自己的协议版本号。

   4. 客户端回应服务器一个报文，包含了客户端决定使用的协议版本号。服务器比较客户端发来的版本号，决定是否能同客户端一起工作。

   5. 如果协商成功，则进入密钥和算法协商阶段，否则服务器端断开 TCP连接。

Note： 版本号协商阶段报文都是采用明文方式传输的。

2. 密钥和算法协商阶段

   1. 服务器端和客户端分别发送算法协商报文给对端，报文中包含自己支持的公钥算法列表、加密算法列表、MAC（Message Authentication Code，消息验证码）算法列表、压缩算法列表等;

   2. 服务器端和客户端根据对端和本端支持的算法列表得出最终使用的算法。

   3. 服务器端和客户端利用 DH交换（Diffie-Hellman Exchange）算法、主机密钥对等参数，生成会话密钥和会话 ID。

      通过以上步骤，服务器端和客户端就取得了相同的会话密钥和会话ID。

          * 对于后续传输的数据，两端都会使用会话密钥进行加密和解密，保证了数据传送的安全

          * 在认证阶段，两端会使用会话 ID用于认证过程。

      Note：

             在协商阶段之前，服务器端已经生成 RSA或 DSA密钥对，他们主要用于参与会话密钥的生成。

3. 认证阶段

   1. 客户端向服务器端发送认证请求，认证请求中包含用户名、认证方法、与该认证方法相关的内容（如：password认证时，内容为密码）。

   2. 服务器端对客户端进行认证，如果认证失败，则向客户端发送认证失败消息，其中包含可以再次认证的方法列表。

   3. 客户端从认证方法列表中选取一种认证方法再次进行认证。

   4. 该过程反复进行， 直到认证成功或者认证次数达到上限， 服务器关闭连接为止。

SSH提供两种认证方式：

   1. password认证：客户端向服务器发出 password认证请求，将用户名和密码加密后发送给服务器；服务器将该信息解密后得到用户名和密码的明文，与设备上保存的用户名和密码进行比较，并返回认证成功或失败的消息。

   2. publickey 认证：采用数字签名的方法来认证客户端。目前，设备上可以利用RSA和 DSA两种公共密钥算法实现数字签名。客户端发送包含用户名、公共密钥和公共密钥算法的 publickey 认证请求给服务器端。服务器对公钥进行合法性检查，如果不合法，则直接发送失败消息；否则，服务器利用数字签名对客户端进行认证，并返回认证成功或失败的消息

SSH2.0还提供了 password-publickey 认证和 any 认证:

   1. password-publickey 认证：指定该用户的认证方式为 password 和 publickey认证同时满足。客户端版本为 SSH1的用户只要通过其中一种认证即可登录；客户端版本为 SSH2的用户必须两种认证都通过才能登录。

   2. any认证：指定该用户的认证方式可以是 password，也可以是 publickey。

4.会话请求阶段

   1. 服务器等待客户端的请求；

   2. 认证通过后，客户端向服务器发送会话请求；

   3. 服务器处理客户端的请求。请求被成功处理后， 服务器会向客户端回应 SSH_SMSG_SUCCESS包，SSH进入交互会话阶段；否则回应 SSH_SMSG_FAILURE包，表示服务器处理请求失败或者不能识别请求。

5.交互会话阶段

在这个模式下，数据被双向传送：

   1. 客户端将要执行的命令加密后传给服务器;

   2. 服务器接收到报文，解密后执行该命令,将执行的结果加密发还给客户端;

   3. 客户端将接收到的结果解密后显示到终端上.

五、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服务器软件的时候"加密通道"才能工作。

六、SSH Q&A

    Q1: SSH的版本和区别。

    SSH2避免了RSA的专利问题，并修补了CRC的缺陷。SSH2用数字签名算法（DSA）和Diffie-Hellman（DH）算法代替RSA来完成对称密钥的交换，用HMAC来代替CRC。同时SSH2增加了AES和Twofish等对称加密算法。

    A1: SSH(Secure SHell)到目前为止有两个不兼容的版本——SSH1和SSH2。SSH1又分为1.3和1.5两个版本。SSH1采用DES、3DES、 Blowfish和RC4等对称加密算法保护数据安全传输，而对称加密算法的密钥是通过非对称加密算法（RSA）来完成交换的。SSH1使用循环冗余校验码（CRC）来保证数据的完整性，但是后来发现这种方法有缺陷。

    更多内容请参考The SSHv1 Protocol & The SSHv2 Protocol

     Q2: 什么是HMAC？

    A2: HMAC(Hash Message Authentication Code) ，散列消息鉴别码，基于密钥的Hash算法的认证协议。消息鉴别码实现鉴别的原理是，用公开函数和密钥产生一个固定长度的值作为认证标识，用这个标识鉴别消息的完整性。使用一个密钥生成一个固定大小的小数据块，即MAC，并将其加入到消息中，然后传输。接收方利用与发送方共享的密钥进行鉴别认证等。

    Q3: 什么是X11 forwarding？

    A3: sh的X11 forwarding特性可以使X client和X server安全地通讯。使用X11 forwarding后，从X client到X Server方向的数据先被送至ssh server，ssh server利用和ssh client的安全通道转发给ssh client，再由ssh client转发给X server，从X server到X client的数据流同理。这里ssh server和ssh client充当了X client和X server间数据的转发器，由于ssh server和X client、ssh client和X server一般在同一台机器上，它们之间是一种安全的进程间通讯，而ssh server和ssh client间的通讯也是安全的，所以X client和X server间的通讯就是安全的。

    Q4: 什么是TTY？

    A4: 终端是一种字符型设备，它有多种类型，通常使用tty来简称各种类型的终端设备。tty是 Teletype的缩写。Teletype是最早出现的一种终端设备，很象电传打字机，是由Teletype公司生产的。设备名放在特殊文件目录/dev/下。

    Q5: 简单描述下SSH运行的过程？

    A5:简要过程如下：

        * Client端向Server端发起SSH连接请求。

        * Server端向Client端发起版本协商。

        * 协商结束后Server端发送Host Key公钥 Server Key公钥，随机数等信息。到这里所有通信是不加密的。

        * Client端返回确认信息，同时附带用公钥加密过的一个随机数，用于双方计算Session Key。

        * 进入认证阶段。从此以后所有通信均加密。

        * 认证成功后，进入交互阶段。

补充:

sshd 配置文件详解

vim /etc/ssh/sshd_config

#1. SSH Server 全局设定，port ,协议 ……

  • # Port 22  #默认端口，也可以使用多个端口

  • Protocol 2 #协议版本号

  • # ListenAddress 0.0.0.0 #默认值是监听所有接口的 SSH 要求

  • # PidFile /var/run/sshd.pid #放置 SSHD 这个 PID 的文件

  • # LoginGraceTime 2m #2分钟之内不输入密码，自动断开

  • # Compression delayed  #使用压缩数据模式进行传输，登入后才将数据压缩 (delayed)

#2. 主要私有Key 存放文件

  • # HostKey /etc/ssh/ssh_host_key # SSH version 1 使用的私钥

  • # HostKey /etc/ssh/ssh_host_rsa_key # SSH version 2 使用的 RSA 私钥

  • # HostKey /etc/ssh/ssh_host_dsa_key # SSH version 2 使用的 DSA 私钥

#3. 关于登录文件的数据与daemon的名称

  • SyslogFacility AUTHPRIV #记录日志/var/log/secure

  • # LogLevel INFO #日志等级

#4. 安全设置

  • # PermitRootLogin yes #是否允许 root 登入

  • # StrictModes yes #是否让 sshd 去检查用户家目录或相关文件的权限数据

  • # PubkeyAuthentication yes #使用密钥登录系统

  • # AuthorizedKeysFile .ssh/authorized_keys #用户登录公钥存放位置

  • PasswordAuthentication yes #登录密码认证

  • # PermitEmptyPasswords no #否允许以空的密码登入

  • # RhostsAuthentication no #系统不使用 .rhosts认证

  • # IgnoreRhosts yes #是否取消使用 ~/.ssh/.rhosts 来做为认证

  • # RhostsRSAAuthentication no #专门给 version 1 用的，使用 rhosts 文件在 /etc/hosts.equiv

  • # HostbasedAuthentication no #上面的项目类似，不过是给 version 2 使用的

  • # IgnoreUserKnownHosts no #是否忽略家目录内的 ~/.ssh/known_hosts

  • ChallengeResponseAuthentication no #允许任何的密码认证

  • UsePAM yes #利用 PAM 管理使用者认证，可以记录与管理

#5. 登录后项目

  • # PrintMotd yes #登入后是否显示出一些信息

  • # PrintLastLog yes #显示上次登入的信息

  • # TCPKeepAlive yes #当达成联机后，服务器会一直传送 TCP 封包给客户端以判断对方式否一直存在联机

  • UsePrivilegeSeparation yes #是否权限较低的程序来提供用户操作

  • MaxStartups 10 #同时允许几个尚未登入的联机画面

  • DenyUsers * #设定受阻止的使用者名称

  • DenyUsers test  #阻止用户

  • DenyGroups test #阻止组

#6. SFTP 设定

  • Subsystem sftp /usr/lib/ssh/sftp-server

  • # UseDNS yes #为了要判断客户端来源是正常合法的，因此会使用 DNS 去反查客户端的主机名，不过在内网这项目设定为 no 会让联机达成速度比较快


来自： http://my.oschina.net/pwd/blog/599071