ssh单点登入解决方案
2019-06-24 本文已影响0人
无聊的上帝op
需求:
服务器的访问权限,实现无密码登入.
存在痛点:
- 运维人员入离职,无法及时,准确,可管理的添加删除服务器访问权限.
- 访问过程中无法认证服务器身份,客户端身份.
- 服务器端的authorized_keys清理不及时和管理不到位.导致访问权限管理失败.
应用场景图:
image.png
双向认证流程:
- APPServices保存Long-term Key
- Client 向Kerberso请求 APPService1 ssh权限
- 为了保证 Short-term Key 只能被 client1 和 server1 安全使用， Kerberos 找到 client1 和 server1 对应的 Long-term Key，假设就是它们密码对应生成的哈希值 hash-c 和 hash-s。然后 Kerberos 会将SKc&s= E hash-c( SKc&s) 的加密结果发送给 client，将 Session Ticket = E hash-s( SKc&s+部分 client 的信息) 的加密结果同样发送给 client
- client 解密hash-c 作为密钥加密的数据包，获得SKc&s。client 将自己的部分信息和 Timestamp 利用 SKc&s 执行加密，即 Authenticator = E SKc&s(部分client的信息+ Timestamp)。把 Authenticator 和 AD那里得到的 Session Ticket 都转发给 server1
- server1 利用 hash-s 解开Session Ticke 得到SKc&s，表达式就是：SKc&s+部分 client 的信息= D hash-s( Session Ticke )。再有 D SKc&s ( Authenticator ) 得到来自 client1 的信息和 Timestamp
- server1 在比较来自 Session Ticke 和 Authenticator 都包含的 client1 信息是否一致之前，会先检查 Timestamp 的时间和当前系统时间做比较，如果两者的时间相差超过设定阈值就认为数据包失效，不再进行比较 client1 的信息而直接拒绝认证，防止重放攻击。为此，server1 中会维护一张时间表，里面记录许多 client 最近一次的认证时间，如果 Timestamp 时间晚于最近认证的时间，server1 才会继续后续验证，所以域环境下的Time Synchronization 也会干预认证结果
- ( optional ) 如果 client1 需要确认通信的 server 是否就是我想要访问的 server1，那么就需要在向 server1 发送的登录凭证里设置 Flag 字段信息。当 server 1 看到有 Flag 字段信息时，就会把来自 client1 的Timestamp 信息用 SKc&s 做加密并把结果发送给 client1 ，client1 解密之后如果 Timestamp 和本机记录一样，则认为 server1 就是我想访问的 server 。因为要拿到 Timestamp 信息需要解开 Authenticator 数据包，解开Authenticator 需要 SKc&s，而获得 SKc&s 要么拥有hash-c，要么拥有hash-s。
密码学知识:
- Long-term Key（亦称Master Key）指的是由密码或者密码直接派生的值，由于 Long-term Key 可能长期不被修改，一旦被截获可以有很长时间进行破解，因此 Long-term Key 不适用于网络传输。密码的哈希值属于Long-term Key。
- Short-term Key（亦称Session Key）是为了解决 Long-term Key 不适用于网络传输的问题，所以 Short-term Key 常常是通信双方进行协商之后得出的密钥，一般 Short-term Key 的生效时间都很短，甚至结束通信后就失效。
参考文档:
https://blog.csdn.net/wulantian/article/details/42418231
Kerberos简单配置攻略 - ArcGIS知乎 - 新一代ArcGIS问答社区 - Esri中国
