如何在SecureCRT上使用公钥登陆Linux服务器

1、在linux执行

ssh-keygen -t rsa

2、在~/ssh/会生成两个文件,id_isa和id_rsapub

将这两个文件传到安装有SecureCRT的电脑上。

3、复制id_rsapub为authorized_keys

cd ~/ssh

cp id_rsapub authorized_keys

4、authorized_keys文件可以上传到任意你想用证书登录的电脑~/ssh

5、设置SecureCRT

查了一下资料，大概原因如下：

不能让所有者之外的用户对authorized_keys文件有写权限。

不仅如此，如果authorized_keys文件、$HOME/ssh目录 或 $HOME目录让本用户之外的用户有写权限，那么sshd都会拒绝使用 ~/ssh/authorized_keys 文件中的key来进行认证。

用chmod对相关目录和文件进行了权限修改，依然无法免密登录。

试验出了一个笨办法：

删除ssh文件夹，然后ssh登录其他主机，这样~目录下会自动重建一个ssh文件夹。

然后vim ssh/authorized_keys，输入个人电脑的公钥，退出登录后重新连接，发现不用输入密码了。

算是解决了，其中的原理后面再来探讨。

1 在 SecureCRT 的 Tools 菜单中选择 Create Public Key，会出现一个生成向导，根据它的提示一步步走，中间会让你选择一个 passphrase，有人翻译成“通关密语”，总之它是一个保护你的 key 的东西，建议设置，并记好，这是找不回的。向导的最后会提示你是否使用新生成的密钥来做为你的全局密钥，选择是。

2 向导完成后，会在你选择的目录下生成两个文件，Identity 和 Identitypub，第一个是你的私钥，需要自己保留的，第二个是公钥，需要上传到服务器（如果直接上传不方便，可以使用文本拷贝的方式）。

3 在服务器上，你的目录下(~/)，建立 ssh 目录，设置权限为700或755。

4 因为 SecureCRT 生成的公钥是 IETF SECSH 格式，与 OpenSSH 的格式不同，需要转换一下。执行命令 ssh-keygen -i ~/ssh/authorized_keys ，根据提示，输入存储你公钥的文件名（Identitypub或你自己更改的名字）。修改文件权限 chmod 600 ~/ssh/authorized_keys 。

5 大功告成。之后每次重新启动SecureCRT，需要输入你的 passphrase，但只要不关闭 SecureCRT，打开多个tab，或在多个服务器共享同一套密钥，就不需要重新输入了。

SecureCRT生成的key和sshd不兼容需要转换才能使用，keypub为SecureCRT生成的pubkey#ssh-keygen -X -f keypub keypub2

注意： 查看ssh-keygen命令帮助

-i Convert IETF SECSH to OpenSSH key file

-e Convert OpenSSH to IETF SECSH key file

所以以上命令#ssh-keygen -i -f keypub keypub2

# mkdir ~/ssh

# touch ~/ssh/authorized_keys

# cat keypub2 ~/ssh/authorized_keys

# rm freebsdpub

配置文件需要更改的地方

# vi /etc/ssh/sshd_config

===========+===========+===========+============Port 22Protocol 2PasswordAuthentication no

PubkeyAuthentication yes

AuthorizedKeysFile ssh/authorized_keys

===========+===========+===========+============

二、linux 为ssh客户端

linux 为客户端不涉及转码的问题，所以比较简单

首先生成本机的公钥 ssh-keygen -t rsa，在这过程中输入 passphrase。

ssl是通讯链路的附加层。可以包含很多协议。https, ftps, …

ssh只是加密的shell，最初是用来替代telnet的。通过port forward，也可以让其他协议通过ssh的隧道而起到加密的效果。

解释原因：

SSL，即安全套接层(Secure Sockets Layer)，它是一种安全协议，是Netscape公司在推出Web浏览器首版时一起提出的。

SSH，也就是Security Shell，由 IETF 的网络小组(Network Working Group)所制定，是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。

SSL有证书中心(CA)公正，可以确定发送者的身份。而SSH没有，可能会被“中间人攻击”，它相当于现代版的窃听。如果攻击者插在用户与远程主机之间(比如在公共wifi区域)，用伪造的公钥，获取用户的登录密码。再用这个密码登录远程主机，那么SSH的安全机制就荡然无存了。不过确保禁用了不安全的SSL/TLS协议，且所访问的网址前面有HTTPS作为开头，可以避免大多数的中间人攻击。SSL终止代理可以处理传入的SSL连接，解密SSL并将未加密的请求传递给其他服务器。SSL允许您通过签名证书使用PKI(公钥基础设施)。而使用SSH，您必须通过ftp等其他协议手动交换密钥指纹。

SSH有一个用户身份验证层，这是SSL所缺乏的(不过是因为它并不需要验证功能)。在使用utf – 8编码时，SSH协议使用了更多的协议。考虑到有更多的潜在攻击，SSH的攻击面似乎更大。但这只是因为SSH内建了一个完整的应用程序。安全性和SSL其实相差无几。

从概念上讲，我们可以使用SSH并将隧道部分替换为SSL中的隧道部分，甚至还可以使用HTTPS并使用SSH-with-data-transport替换SSL事务，并使用钩子从其证书中提取服务器公钥。没有科学上的不可能性，如果做得恰当，它们的安全性将保持不变。

OpenStack密钥对的作用是远程访问身份认证。

OpenStack是一个开源的云计算平台，用于搭建和管理大规模的虚拟机和其它资源。其中的密钥对主要用于远程访问身份认证，确保只有授权的用户才能访问和控制计算资源。

在OpenStack中，密钥对由一对公钥和私钥组成。公钥用于加密数据或对数据进行签名，而私钥用于解密数据或验证签名。在远程访问的身份认证过程中，用户首先使用私钥生成一个数字签名，然后将这个签名和公钥一起发送给服务器。服务器使用公钥来验证这个签名，如果验证成功，那么用户就被认为是合法的。

这种基于密钥对的身份认证机制提供了很高的安全性。只有持有正确的密钥对，用户才能进行有效的身份认证。同时，由于密钥对的非对称性，即使私钥被泄露，攻击者也不能轻易地伪造身份认证。这大大提高了OpenStack云环境的可靠性和安全性。

OpenStack的工作流程

OpenStack的各个服务之间通过统一的REST风格的API调用，实现系统的松耦合。它内部组件的工作过程是一个有序的整体。诸如计算资源分配、控制调度、网络通信等都通过AMQP实现。

OpenStack的上层用户是程序员、一般用户和Horizon界面等模块。这三者都是采用Open Stack各个组件提供的API接口进行交互，而它们之间则是通过AMQP进行互相调用，它们共同利用底层的虚拟资源为上层用户和程序提供云计算服务。

本文是笔者查阅网上资料做的总结，关于SSH原理，什么是对称加密和非对称加密，本文不过多介绍。这里介绍一下SHH的工作过程、配制方法，可能出现的问题及解决方法。

说明：本文中涉及的例子，SSH客户端为：本地主机A，SSH服务器为：服务器B

SSH协议采用C-S（客户端-服务器端）架构进行双方的身份验证以及数据的加密。

服务器端组件监听指定的端口，负责安全连接的建立、对连接方的身份认证、以及为通过身份认证的用户建立正确的环境。

客户端负责发起最初的TCP握手、安全连接的建立、验证服务器的身份与之前记录中的一致、并将自己的验证信息提供给服务器。

一个SSH会话的建立过程分为两个阶段。第一阶段，双方沟通并同意建立一个加密连接通道以供后续信息传输用。第二阶段，对请求接入的用户进行身份验证以确定服务器端是否要给该用户开放访问权限。

当客户端发起TCP连接时，服务器端返回信息说明自己支持的协议版本，如果客户端上支持的协议与之匹配，则连接继续。服务器会提供自己的公共主机密钥（public host key）以让客户端确认自己访问的是正确的机器。

然后，双方采用一种Diffie-Hellman算法共同为该会话建立密钥。每一方的一部分私有数据，加上来自对方的一部分公共数据，通过这种算法计算，能够得出完全相同的密钥用于本次会话。

整个会话的通讯内容都使用该密钥进行加密。这个阶段使用的公钥/私钥对与用户验证身份用的SSH密钥是完全无关的。

经典Diffie-Hellman算法的计算步骤如下：

这个共享密钥的加密方式被称为二进制数据包协议（binary packet protocol）。该过程能够让双方平等的参与密钥生成的过程，而不是由单方掌握。这种共享密钥生成的过程是安全的，双方没有交换过任何未经加密的信息。

生成的密钥是对称式密钥，一方用于加密信息的密钥等同于另一方用于解密信息的密钥，而任何第三方由于不持有该密钥，是无法解密双方传递的内容的。

会话加密通道建立后，SSH开始进入用户认证阶段。

下一步，服务器验证用户身份以决定是否准许其访问。验证有不同的方式，选择的验证方式取决于服务器的支持。

最简单的验证是密码验证：服务器要求客户端输入密码，客户端输入的密码经过上述的通道加密传输给服务器。

虽然密码是加密过的，然而该方法仍然不被推荐，因为用户经常为了省事而使用过于简单的密码，而这类密码很容易就能够被自动化脚本破解。

最流行的验证方式是SSH密钥对，这也是当前最推荐的方式。SSH密钥对是非对称密钥，私钥和公钥分别用于不同的功能。

公钥用于加密，而私钥用于解密。公钥可以随意上传、共享，因为公钥的流通并不会危及到私钥的保密性。

SSH密钥对的验证过程起始于上一部分加密通道建立之后，其具体执行步骤如下：

简单来说，服务器端用公钥加密信息，客户端用私钥解密信息以证明自己持有私钥。该过程同时使用了对称加密和非对称加密，两种方式各有自己的功用。

命令如下：

用户名：为要登录的服务器B中已存在的用户账户名

IP地址：为服务器B的IP地址

-p 端口号：用来指定端口号，默认为22

第一次登录时，会提示如下提示：

大概意思是说，你正在访问的主机不能验证它的真实性，它的RSA key（当前访问主机的公钥）指纹是怎样的，你确定要继续连接吗？

输入yes继续，会提示，已永久把当前访问主机的RSA key添加到了已知主机文件（用户目录下，ssh 文件夹中的knwon_hosts文件）中。之后再次 SSH 登录就不再有该提示了。

接着，输入登录账户的密码即可。

SSH 密码登录，需要服务器开启密码验证权限，编辑服务器SSH配置命令如下：

在 sshd_config 文件中，Protocol 2 下面 #PasswordAuthentication yes，将前面的#号去掉，保存退出。

公钥登录，即免密码登录。避免的每次登录都要输入的麻烦，也防止了中间人攻击。是SSH远程登录最常用的登录方式。

提示输入密钥对名称，直接回车，使用默认名称即可；

提示输入密码（使用私钥时，要输入密码），直接回车，不使用密码即可。

首先，登录服务器B，在进行下面的操作。

找到 #PubkeyAuthentication yes，删除 #号，保存退出。

重启 ssh 服务

也可指定验证私钥：

本地主机A，生成密钥对后：

sudo vim /etc/selinux/config