由SecureCRT引起的思考和学习

前言html

因为业务须要,最近在云上新购买了一批centos7.0的服务器,用脚本批量添加了用户(脚本请见我以前的博客/秘钥认证用户自动控制:http://my.oschina.net/pwd/blog/388254),加完秘钥以后发现,可是secureCRT 抛出了一下异常。算法

解决过程shell

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

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

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/5691924dom

1、什么是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)客户端到服务器:客户端传送数据时,拿服务器的公钥加密后送出。服务器接收后,用服务器的私钥解密,这样就能保证通讯安全

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协议框架中还为许多高层的网络安全应用协议提供扩展的支持。它们之间的层次关系能够用以下图来表示:

3、主机密钥机制

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

SSH协议关于主机密钥认证的管理方案有两种,以下图所示:

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

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

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

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

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

4、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. 客户端将接收到的结果解密后显示到终端上.

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

6、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 会让联机达成速度比较快

相关文章
相关标签/搜索