SSH与Kerberos原理、关系和区别

SSH和Kerberos是用来进行安全认证和安全通讯的，它们之间的关系是什么，区别是什么？

 

SSH是安全认证的安全通讯的方法，Kerberos是安全认证和安全通讯的一套架构体系。SSh采用简单的方法 client <--> Server 之间进行安全认证和安全通讯。 Kerberos的认证架构系统中包括KDC，Service Server和Service Client。简单地说，SSH用在clients和一台Server之间进行安全认证，而Kerberos用在clients和多台Service Servers之间进行安全认证。Kerberos的出现就是为了解决在一个系统中每台Server都独立认证的繁琐问题，而采用集中认证。

 

SSh的安全认证方法有4种：Host-Based authentication、Public-key authentication、Challenge-response authentication和Password authentication。我们通常使用Public-key authentication和Password authentication。

 

Public-key安全认证方法是user调用ssh-keygen命令产生public-keys和private-key pairs，user把private-key和public-key存储在本地 ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), 或者 ~/.ssh/id_rsa (protocol 2 RSA) ，把 public-key存储在本地 ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), 或者 ~/.ssh/id_rsa.pub (protocol 2 RSA)。接着user把public-key拷贝到远程要访问的Server的user的home目录下的~/.ssh/authorized_keys。

 

public/private-key pairs是如何进行安全认证的呢。public/private-key是非对称的加密/解密方法。即用public-key加密的信息，只能用private-key揭开；用private-key加密的信息，只能用public-key解开。这与传统的对称加密/解密方法是完全不同的。对称的加密/加密方法是用encrypted-key加密，只能用这个 encrypted-key解密，所以加密/解密双方必先约定一个encrypted-key。但是对称的加密/解密方法有更好的效率，所以一般使用非对称加密/解密方法认证和约定传输信息的对称加密/解密的encrypted-key，而使用对称加密/解密的方法开保证传输线程的安全。SSh/TLS正是使用了这样的方式。

 

public-key的安全认证过程：

                                  login(user-name)

           user（client）------------------------------------->  server

                     public-key(host-key,message, transfer encrypted-key)

          server  --------------------------------------------> user

                      encrypted-key(message)

          user  --------------------------------->  server

                       encrypted-key(ok)

          server -------------------------------->  user    // establish the connection

 

 

SSh的Password安全认证过程：

 

                                  login(user-name)

           user（client）------------------------------------->  server

 

                      password(host-key,message, transfer encrypted-key)

           server  --------------------------------------------> user

                        encrypted-key(message)

          user   --------------------------------->  server

                        encrypted-key(ok)

          server -------------------------------->  user    // establish the connection

 

从SSH的两种安全认证的方法看到，Public-Key和Passord的认证交互过程是基本一样的，区别就是Password认证user要把自己的password公开给server，而public-key认证user只需要把public-key公布给server，从而增加了更多的安全性。

 

上面的认证只涉及Server对User的安全认证，那User如何对Server进行安全认证呢。SSH中使用host-key来帮助User对Server进行认证。Server的host-key存储在User本地的~/.ssh/known_hosts中，如果Server的host-key发生变化，SSH则会通知User，这样可以避免假Server的欺骗和man-in-the-middle攻击。

 

Kerberos是如何进行安全认证的呢。

 

Kerberos的设计目标是在一个系统中，用户只需一次集中安全口令认证从而可以访问系统中的Service Servers。因此在认证系统中要有一个独立的Authentication Server(AS)。

 

AS如果让通过安全口令认证的用户访问系统中的Service Servers呢。在日常生活中，简单的做法是AS给通过口令认证的用户一个Service Server的ticket，用户拿着ticket去访问Service Server。为了防止伪ticket的危害，ticket必须要经过加密，所以AS和Service Server之间有约定的加密密钥，即AS知道Server key，记为K_server。

 

Service Servers有责任和义务保护用户的数据安全，即Service Servers必须要保证用户的数据不能被其他人获取和修改。所以Service Servers也要通过安全认证来保证试图访问的用户就是用户本人。现在没有了口令认证，如何保证呢。是否可以通过用户的身份信息来验证呢，即用户的name，location（ip-addr）；但是这些身份信息任何人都可以获取的，所以用户很容易被被他人仿冒。明的信息不可靠，那就用暗号吧！就像电影中描述的，秘密组织间使用暗号联络。Kerberos正是使用了“暗号”来确保Service Servers对用户的身份认证，“暗号”称为Session key，记为K_session。

用户通过口令安全认证后，向AS请求要访问Service Server A，AS验证用户是否有权限，若有，就分配“暗号号” K_session给用户和Server A。“暗号”K_session放在Server的ticket中，同时返回给用户。“暗号”K_session返回给用户是否会被窃取呢，不会的！因为AS和用户之间的通讯是经过加密的，安全的。

 

为了系统架构的更加清晰，Kerberos把用户口令认证的模块AS和分配Service Server ticket的模块分开，分配Service Server ticket的模块成为Ticket Granting Server，即TGS。AS验证用户口令安全后，把TGS的ticket发给用户，用户拿着TGS的ticket访问TGS，请求Service Servers的tickets。

 

 

Kerberos的认证流程：

                             user-name, ip-addr

      User  ------------------------------------------------------------------>  AS

 

              user_password(K_session_tgs),

              K_tgs(user-name, ip-addr, tgs-name, ticket_life, K_session_tgs)

      AS   ---------------------------------------------------------------------> User

 

              K_session_tgs(user-name,ip-addr),

              K_tgs(user-name, ip-addr, tgs-name, ticket_life, K_session_tgs)

      User ---------------------------------------------------------------------> TGS

 

              K_session_tgs(K_session_server),

              K_server(user-name, ip-addr, server-name, ticket_life, K_session_server)

      TGS --------------------------------------------------------------------------> User

 

              K_session_server(user-name,ip-addr),

              K_server(user-name, ip-addr, server-name, ticket_life, K_session_server)

      User --------------------------------------------------------------------------> Server

 

                                           ok--connection established

      Server ------------------------------------------------------------------------> User