标签：style code http color 使用 width
1。 ssh 协议2.ssh确认自己版本够新可以和sshd交互后，ssh和sshd就开始交换双方能支持的加密算法之类的信息
3.sshd就首先生成session key, 把其中的sshd_key_pub发给ssh, 并且随机生成一个id,也发给ssh
4.ssh自己也生成session key,然后和id异或得到临时的tmp_session_key，然后用sshd_key_pub加密发给sshd5.sshd用自己的sshd_key解密得到tmp_session_key，然后和id异或之后就得到了ssh生成的session key所以到这步ssh和sshd之间就建立起了一个加密过的通道
信任关系鉴权
1.client用已经建立起来的加密通道,用session key加密自己的id_rsa.pub发给server 【加密通道过程】
2.server端用session key解开获取到id_rsa.pub，在authorized_keys里头找匹配的key,如果找到了就生成校验码verify_code，用id_rsa.pub加密，再用session key再次加密，然后才发给client
3.client用session key解开之后，用自己的id_rsa解密内容，得到verify_code,然后用session key加密verify_code再发给server
4.server用session key解开后跟自己发出去的verify_code校验，如果一致就鉴权通过 【为什么要进行二次鉴权？
应该是防止，人家模拟发包刚好=某个【session key加密自己的id_rsa.pub】从而建立欺骗的信任。| 项目 | ssh信任关系鉴权 | redius计费协议 | oauth2.0认证和授权 | https 认证过程 | lvs防止tcp长连接攻击 |
| 大致过程 | 1.cs建立加密通道 2.c发普通鉴权信息给s 3.s鉴权后发给c临时令牌 | 1.通过AAA认证过程建立信任通道2.客户端发出随机的临时令牌 request-auth3.服务器端通过ResponseAuth = MD5(Code+ID+Length+RequestAuth+ Attributes+Secret)；返回响应4.客户端通过临时令牌和自身的secret确认的确是非伪装的服务器回应。 | 1.用户访问美丽说，点击用微博账号登录2.美丽说通过appkey获得微博的一个临时授权令牌3.美丽说用临时授权令牌和用户账号密码请求微博提供用户的账号基础信息4.微博鉴权成功后返回账号基本信息 | 1.浏览器发送自己支持的认证方式2.服务器返回证书，里面包含了网站地址，加密公钥3.浏览器接收证书，并生成一串随机数的密码【临时令牌】，并用证书中提供的公钥加密，发给服务器4.服务器使用私钥取出临时令牌，并使用公钥+临时令牌与浏览器交互信息注：https的公钥只能加密，私钥只能解密，固安全性高 | 1.sync flood 通过SYN攻击，攻击者可以建立与受害者计算机的最初连接，受害者计算机等待连接的完成。攻击者利用TCP中的“三次握手”来建立可信的连接。当最初连接打开时，它会消耗受害者计算机上的资源，直到它用尽连接或产生其他问题。2.防御，1）当客户端发出sync，服务器返回 特殊的sync+ack,但不等待2）该特殊的sync是个用时间计算的临时令牌，10分钟内有效3）当客户端返回 sync+ack，只需看看 sync-1是否是有效的临时令牌，如果是则连接，不是不管。 |
| 核心 | 临时令牌 | 临时令牌 | 临时令牌 | 临时令牌，公钥，私钥 | 与时间相关的临时令牌 |
标签：style code http color 使用 width
原文地址：http://blog.csdn.net/zzz_781111/article/details/32728583
