ssh登录的认证方式

ssh登录的认证方式有：Password、RSA、DSA、ECC、Password-RSA、Password-DSA、Password-ECC和ALL。

1、Password认证

Password认证是一种基于“用户名＋口令”的认证方式。通过AAA为每个SSH用户配置相应的密码，在通过SSH登录时，输入正确的用户名和密码就可以实现登录。

2、RSA认证

RSA认证是一种基于客户端私钥的认证方式。RSA是一种公开密钥加密体系，基于非对称加密算法。RSA密钥也是由公钥和私钥两部分组成，在配置时需要将客户端生成的RSA密钥中的公钥部分拷贝输入至服务器中，服务器用此公钥对数据进行加密。

3、DSA认证

DSA认证是一种类似于RSA的认证方式，DSA认证采用数字签名算法进行加密。

4、ECC认证

ECC认证是一种椭圆曲线算法，与RSA相比，在相同安全性能下密钥长度短、计算量小、处理速度快、存储空间小、带宽要求低。

5、Password-RSA认证

SSH服务器对登录的用户同时进行密码认证和RSA认证，只有当两者同时满足情况下，才能认证通过。

6、Password-DSA认证

SSH服务器对登录的用户同时进行密码认证和DSA认证，只有当两者同时满足情况下，才能认证通过。

7、Password-ECC认证

SSH服务器对登录的用户同时进行密码认证和ECC认证，只有当两者同时满足情况下，才能认证通过。

8、ALL认证

SSH服务器对登录的用户进行公钥认证或密码认证，只要满足其中任何一个，就能认证通过。

SSH结构层次

1、表示层

表示层主要涉及Struts的功能，在这一层，首先通过JSP页面实现交互界面，负责传送用户请求和接收响应，然后Struts根据配置文件将接收到的用户请求委派给相应的Action处理。

2、业务逻辑层

业务层主要涉及Spring的功能，在这一层，管理服务组件负责向Struts配置好的对应Action提供业务模型，该组件的对象数据处理组件完成业务逻辑，并提供事务处理等容器组件以提升系统性能和保证数据的完整性。

3、数据持久层

持久层主要涉及Hibernate的功能，Hibernate实现了数据持久化功能，使得程序员可以通过面向对象地编程思维来 *** 作数据库。在这一层中，依赖于Hibernate的对象化映射和数据库交互，处理Spring中的DAO组件请求的数据，并返回处理结果。

ssh登陆通常指的是由Master到任意一个Slave的无验证的单向登陆，意思就是只能从Master登陆到Slave是不需要密码的，但是如果你想从
Slave无验证登陆到Master，或者你想在Slave与Slave之间进行无验证登陆，这些都是不可行的，除非进行了密钥对的双向验证，才可以
双向登陆。
首先使用root用户登陆，在network中修改机器名，并在hosts文件中添加映射信息，然后执行保存退出，Slave机按同样方法配置。
然后在Master，Slave机上分别用root用户建一个hadoop用户，并设置密码，注意用户名，密码保持一致。
登入hadoop用户，执行以下命令，生成密钥对，并把公钥文件写入授权文件中，并赋值权限，
ssh-keygen –t rsa –P ''
cat ~/ssh/id_rsapub >> ~/ssh/authorized_keys
chmod 600 ~/ssh/authorized_keys
最后切换root用户，配置sshd，取消被注释的公钥字段，
RSAAuthentication yes # 启用 RSA 认证
PubkeyAuthentication yes # 启用公钥私钥配对认证方式
AuthorizedKeysFile ssh/authorized_keys # 公钥文件路径（和上面生成的文件同）
并保存设置，然后重启sshd，即可测试本机的SSH。
把
Master的公钥文件通过scp拷贝到已经创建好的Slave节点的hadoop用户上，需要注意的是，在这个用户上不一定有ssh文件夹，如果没有
的话，也没关系，创建一个ssh文件夹，并赋予700的管理权限，最后将公钥追加到授权文件中，并赋予600的权限，这两步比较重要，切记！
拷贝完成之后，去Slave机上进行公钥追加授权文件，并赋值权限，然后切换root用户，进行sshd配置，并重启ssh服务。
然后，回到Master机的hadoop用户上，进行测试。
此时，已经不需要密码验证了。当然现在只是单向登陆从Master到Slave的可以，如果从Slave到Master不行，想要双向登陆，必须得两台机器互相认证彼此的公钥文件。下面在Slave节点下的hadoop用户里，生成自己的公钥文件，并用scp拷贝到Master上，然后将公钥追加的授权文件中，以此实现双向认证。
Slave机上的hadoop用户生成密钥对，拷贝公钥到Master机上的hadoop用户上，然后与上面相同的方式追加到授权文件authorized_keys里面。然后就大功告成了。

在 《使用wireshark分析ssh口令登录细节》 和 《ssh工具，开发者必须有所了解》 这两篇文章中，我们知道了SSH登录有两种登录验证方式，其中口令登录方式使用简单，但会遇到安全问题，比如遇到中间人攻击，就会泄漏服务器的root口令。所以从安全的角度来看，建议使用另外一种登录验证方式，这就是密钥对登录方式。

密钥对验证方式对于初学者来说并不是很友好，所以我分两篇文章把这个事情说清楚，本文主要从原理的角度讲解，让你了解这种方式运作的流程，下一篇从实战的角度手把手教你登录ssh服务器。

对于开发者来说，也请务必学会使用密钥对方式登录服务器，因为现在很多应用和服务推荐这种方式，比如Github就可以使用密钥对方式连接，AWS默认就禁止口令登录。

网上有很多文章介绍ssh口令登录，但客观的说，很多文章讲错了。

很多人大概是这样理解的，客户端生成一个公开密码学算法的密钥对（注意不是ssh服务器端的密钥对），然后将公钥放到ssh服务器上的 authorized_keys 文件中（潜台词就是你有ssh权限才能 *** 作）。

然后ssh如何登录呢在连接过程中，会将客户端密钥对的公钥发送给ssh服务器，服务器在 authorized_keys 文件中匹配到这个公钥，就认为登录成功了，其实这个理解是有问题的。

核心的两个问题：

知道了这个结论后，我们看看详细的登录验证过程，在 《使用wireshark分析ssh口令登录细节》 中说过，ssh登录分为两个阶段，不管是哪一种登录验证，第一阶段的过程都是相同的，区别在于第二阶段。

有的同学说，这次你为啥不用wireshark分析了？因为第二阶段的消息传递都是加密保护的，并不能解密出具体的消息格式，这一点和TLS协议非常不同，TLS协议有多种方式可以解密出明文，而SSH协议是不支持的，所以wireshark只能显示密文。

基于这一点，本文就不用wireshark分析了，简单谈一谈ssh密钥对登录的流程，要经过多个消息交互。

第二阶段具体的流程如下：

1：ssh客户端生成一个 key ID（这个ID是基于密钥对的公钥算出来的，具体格式未知），再一次说明，这个密钥对不是服务器的，使用会话密钥加密后发送给服务器端。

2：服务器端从 authorized_keys 文件中匹配 key ID，如果匹配，此时还不能证明这个ssh客户端是真正的客户端密钥对的主人。

3：服务器端生成一个随机数，然后用客户端的公钥加密后发送给客户端。

4：客户端使用自己的私钥解密出服务器端的随机数，注意，如果某个攻击者仅仅有客户端的公钥，它是无法解密出的，因为攻击者没有对应的私钥。

5：为了向服务器端证明它能解密出这个随机数，客户端将解密出的随机数用会话密钥加密，将得到的值进行MD5运算。然后将这个值发送给服务器，以便响应（4）阶段的消息。

6：服务器端对原始随机数也使用会话密钥加密，再进行MD5计算，如果得出的值和（5）阶段客户端发送的一致，代表双方的登录校验通过。

服务器端使用服务器密钥对公钥指纹像客户端证明它就是真正的服务器端；而客户端使用它自己的密钥对向服务器证明它就是真实的客户端。

由于在验证过程中，客户端密钥对的公钥不会传输，所以即使遇到中间人攻击，攻击者也不会获取到公钥（不考虑客户端机器本身遇到攻击了）。

如果客户端的公钥曾经泄漏过，攻击者也不能成功登录ssh服务器，原因是攻击者没有私钥，无法解密出随机数，从而不能完成验证。

当然如果客户端密钥对公钥和私钥全部泄漏了，那就当我什么也没说，所以定期更换密钥对还是有好处的。

基于以上两点，我认为ssh密钥对登录是安全的，也是推荐的。

---