ssh加密

1. ssh密钥对登录安全吗原理篇

在 《使用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密钥对登录是安全的，也是推荐的。

2. SSH 密码与秘钥登录方式

密码登录顾名思义极其简单，登录之前需要在ssh服务器上有相应的用户名与登录密码。

密码登录命令行：ssh username@hostname -p port
username:登录用户名
hostname:ssh服务器，既可以是ip也可以是域名
port:这个为可选项，即ssh服务器的端口，如果为空则默认端口为22

秘钥登录使用加密的

终端下生成秘钥命令：ssh-keygen -t rsa（如果不输入密码，则不需要密码）
生成过程中会提示输入秘钥文件的名称，如果输入为 Key，则会生成 Key 与 Key.pub 两个文件， Key为私钥，Key.pub为公钥。将Key放入本机用户目录的 .ssh目录下，将.ssh目录权限改为700

将生成的公钥 Key.pub 上传至目标服务器，并将Key.pub放置于用户目录的.ssh目录，同样.ssh目录权限也为700
然后执行 cat Key.pub >> authorized_keys 将公钥导入，并确定authorized_keys权限为 600

秘钥配置好后，可以执行 ssh -i Key username@hostname -p port
ssh 默认秘钥为 id_rsa, 需要加上参数-i 指明秘钥

3. 如何禁用OpenSSH（CBC）加密模式防止信息泄露

OpenSSH是一种开放源码的SSH协议的实现，初始版本用于OpenBSD平台，现在已经被移植到多种Unix/Linux类操作系统下。如果配置为CBC模式的话，OpenSSH没有正确地处理分组密码算法加密的SSH会话中所出现的错误，导致可能泄露密文中任意块最多32位纯文本。在以标准配置使用OpenSSH时，攻击者恢复32位纯文本的成功概率为2^{-18}， 此外另一种攻击变种恢复14位纯文本的成功概率为2^{-14}。

编辑ssh配置文件

在 # Ciphers and keying 下或者 文件的末尾 添加下文

重启SSH服务使配置生效

使用SSH针对CBC分组类型的加密算法进行检查

屏幕打印的日志的最后一行：

出现 no matching cipher found: client aes128-cbc,3des-cbc … 说明配置生效。（此时的SSH登录并未成功）

查看默认SSH支持加密算法分组类型

4. 女生说ssh是什么意思

一种网络协议。
女生说ssh是一种网络协议，用于计算机之间的加密登录。
ssh是一种远程加密传输协议，并不是所谓的免密登录这一作用，那只是它的一小部分，你可以理解它跟https一样，是一种加密协议，有助于提高安全性。

5. SSH详解-3.密钥登陆

SSH详解-1.ssh基础知识
SSH详解-2.ssh基本用法
SSH详解-3.密钥登陆
SSH详解-4.多个ssh公钥

在上一篇中我们了解到了ssh基本用法，ssh通过密码进行登录。密码登录存在很多问题。密码太简单，又不安全。密码太复杂，不容易记，而且每次登录都要输入很麻烦。于是就有了密钥登陆。

什么是密钥(key)？

ssh密钥登录采用的是 非对称加密 。

非对称密钥加密系统，又称公钥密钥加密。它需要使用不同的密钥来分别完成加密和解密操作，一个公开发布，即公开密钥（public key）和，另一个由用户自己秘密保存，即私用密钥（private key）。
如果数据使用公钥加密，那么只有使用对应的私钥才能解密，其他密钥都不行；反过来，如果使用私钥加密（这个过程一般称为“签名”），也只有使用对应的公钥解密。

了解完密钥后，接下来看看密钥登录的过程，SSH 密钥登录分为以下的步骤。

第零步，准备步骤客户端通过 ssh-keygen 生成自己的公钥和私钥，并将公钥放入远程服务器的指定位置。

第一步，用户客户端向服务器发起SSH登录的请求。

第二步，服务器收到用户SSH登录的请求，服务器生成一些随机数据发送给客户端。

第三步，客户端接收到服务器发过来的数据，客户端使用私钥对数据进行签名后再返回给服务器。

第四步，服务器收到客户端加密后的数据，使用对应公钥进行解密。然后判断解密后的数据是否与原始数据一致，如果一致就允许用户登录。

ssh-keygen 是OpenSSH提供的一个命令行工具，用于生成密钥登录所需的公钥和私钥。

在上面的例子中，我使用了-t参数来指定加密算法，一遍会选择rsa或者dsa。
第一个问题，问我要保存在哪？（直接Enter默认会保存在~/.ssh/id_rsa中）因为我之前已经生成过密钥了，我就保存在tenxun里面。

第二个问题，询问是否要为私钥文件设定密码保护（passphrase）。这样的话，即使入侵者拿到私钥，还是需要破解密码。如果为了方便，不想设定密码保护，可以直接按回车键，密码就会为空。

最后，就会生成私钥和公钥，屏幕上还会给出公钥的指纹，以及当前的用户名和主机名作为注释，用来识别密钥的来源。

从上面的公钥中我们可以看到末尾的公钥注释 23696@DESKTOP-GKRBCVI
公钥注释可以用来识别不同的公钥，表示这是哪台主机（DESKTOP-GKRBCVI）的哪个用户（username）的公钥。

注意 ，公钥只有一行。因为它太长了，显示的时候可能自动换行了。

OpenSSH 规定，用户公钥保存在服务器的 ~/.ssh/authorized_keys 文件。你要以哪个用户的身份登录到服务器，密钥就必须保存在该用户主目录的~/.ssh/authorized_keys文件。只要把公钥添加到这个文件之中，就相当于公钥上传到服务器了。每个公钥占据一行。如果该文件不存在，可以手动创建。

-i 指定要上传公钥（公钥文件可以不指定路径和 .pub 后缀名），user是所要登录的用户名，hostname是主机名，这两个参数与ssh 登录命令是一致。

特别注意 ，不是把公钥上传上去就行了，还需要把 authorized_keys 文件的权限要设为644，即只有文件所有者才能写。如果权限设置不对，SSH服务器可能会拒绝读取该文件，导致密钥登录失效，登录的时候还需要输入密码。

提到输入密码，如果再生成公钥和私钥的时候设置了密码，使用密钥登录的时候也需要输入私钥的密码，这样可以防止他人非法窃取了私钥。

私钥设置了密码以后，每次使用都必须输入私钥密码，这个问题可以使用 ssh-agent 命令解决。

网络-密钥
Git - 生成 SSH 公钥 (git-scm.com)
ssh(1) - OpenBSD manual pages

6. 对SSH包,在包加密过程中假如没有包括MAC,会有什么好处吗

没有好处的。
加密连接建立后，每一条发送的信息都会包含一个MAC，这样接收方就能够用这个MAC来验证信息完整性。MAC的计算过程使用了共享密钥、信息包的顺序代号、以及信息自身的内容。在内容发送过程中，MAC是在每一个信息包的最后发送的，位于对称加密区之外。这是因为根据科研人员的建议，最好按照先加密、后计算MAC的顺序进行数据的处理。

7. ssh原理及应用

简单说，SSH是一种网络协议，用于计算机之间的远程加密登录。

SSH 为 Secure Shell的缩写，由 IETF 的网络小组（Network Working Group）所制定，SSH 为建立在应用层基础上的安全协议。SSH 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序，后来又迅速扩展到其他操作平台。SSH安装容易、使用简单，而且比较常见，一般的Unix系统、Linux系统、FreeBSD系统都附带有支持SSH的应用程序包。Windows如果需要使用SSH，可以安装PuTTY或者Cygwin。

SSH 服务基于非对称加密（public-key cryptography，也称公开密钥加密）技术实现数据加密传输。该技术会生成一对数学相关的密钥， 其中一个用于对数据进行加密，而且只能用于加密，而另一个只能用于解密 。使用加密密钥加密后的数据，只能用对应的解密密钥才能解密。而且，只知道其中一个密钥，无法计算出另一个。因此，如果公开了一对密钥中的一个，并不会危害到另一个的秘密性质。通常把公开的密钥称为公钥（public key），而不公开的密钥称为私钥（private key）。

一般来说，非对称加密的应用场景有两个：

与对称密钥加密相比，非对称加密的优点在于不存在共享的通用密钥。由于解密用的私钥无需发送给任何用户，所以可以避免密钥被劫持或篡改。而加密用的公钥即便被劫持或篡改，如果没有与其匹配的私钥，也无法解密数据。所以，截获的公钥是没有任何用处的。

当前，SSH主要采用 RSA 算法（协议 V2 默认算法）和 DSA 算法（协议 V1 仅支持该算法）来实现非对称加密技术。

SSH连接时，整个交互过程如上图。，主要可以分为三个阶段

服务端在每次启动 SSH 服务时，都会自动检查 /etc/ssh/ 目录下相关密钥文件的有效性。如果相关文件检查发现异常，则会导致服务启动失败，并抛出相应错误信息。 如果文件相关不存在，则会自动重新创建。

默认创建的相关文件及用途说明如下：

当服务器SSH服务启动，客户端也安装了SSH后，就可以进行连接了。

后续登录校验及正常的数据传输，都会通过双向加密方式进行。相关交互说明如下：

从这个连接过程中，可以看出，主要使用到两个文件夹下的内容：

在连接中的两个过程：

之所以有多组密钥，是因为使用了不同的加密算法。
客户端接收到之后，会存储在 ~/.ssh/known_hosts 文件里，查看这个文件，可以看到有一行与服务器 ssh_host_ecdsa_key.pub 内容一致。

所以， ~/.ssh/authorized_keys 里表示本机可以被哪些机器访问
~/.ssh/known_hosts 里表示本机访问过哪些机器

SSH配置文件有两个，一个是 ssh_config ,一个是 sshd_config 。前者是客户端配置，后者是服务器配置。也就是说，如果本机是作为客户端，那么就修改第一个配置，如果本机是作为服务器，那么就修改第二个配置，

一般来说，和密钥登录的配置有关的有以下几个，如果密钥配置好后无法登录，尝试配置以下三项。

其他

传统的网络服务程序，如ftp、Pop和Telnet在传输机制和实现原理上是没有考虑安全机制的，其本质上都是不安全的。因为它们在网络上用明文传送数据、用户帐号和用户口令，别有用心的人通过窃听等网络攻击手段非常容易地就可以截获这些数据、用户帐号和用户口令。而且，这些网络服务程序的简单安全验证方式也有其弱点，那就是很容易受到"中间人"（man-in-the-middle）这种攻击方式的攻击。

所谓"中间人"的攻击方式，就是"中间人"冒充真正的服务器接收你的传给服务器的数据，然后再冒充你把数据传给真正的服务器。服务器和你之间的数据传送被"中间人"一转手做了手脚之后，就会出现很严重的问题。中间人能够攻击，主要原因在于他能认识截取的信息，也能发出让接受者认识的信息。

使用SSH，你可以把所有传输的数据进行加密，这样"中间人"这种攻击方式就不可能实现了，而且也能够防止DNS欺骗和IP欺骗。使用SSH，还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。SSH有很多功能，它既可以代替Telnet，又可以为FTP、Pop、甚至为PPP提供一个安全的"通道"。

最初的SSH是由芬兰的一家公司开发的。但是因为受版权和加密算法的限制，现在很多人都转而使用OpenSSH。OpenSSH是SSH的替代软件包，而且是免费的，可以预计将来会有越来越多的人使用它而不是SSH。

8. ssh和telnet区别

telnet是明文传输，而ssh是加密传输，相对来说比较安全。 1.ssh机制第一种是路由器公钥加密，私钥解密。ssh路由器会产生一个公钥public,一个私钥pri.当客户端通过ssh登录到设备的时候，路由器会将自己的公钥发送给客户端，客户端接受并保存这个公钥，接下来的过程就是加密，客户端输入用户名和密码的过程是通过路由器的公钥来加密的，客户端输入完成将这个在发送给路由器，路由器通过自己的私钥来解密这个公钥。再将这个用户名和密码发送到本地进行认证。认证成功，整个登录即ok。 2.ssh机制第二种是路由器产生一个公钥秘钥，客户端也产生一个公钥秘钥。当客户端试图登录路由器，客户端输入正确的用户名admin后，路由器发现admin用户被绑定到名称为AR1的rsa秘钥。所以路由器会将此公钥发送给客户端进行验证，因为客户端有对应的私钥可以解密公钥，故认证成功。难点：客户端的公钥如何产生，客户端的公钥如何导入路由器。路由器的公钥如何产生，路由器的公钥如何导入客户端。

9. SSH隧道协议（AES密钥对加密法则）

SSH是每一台Linux电脑的标准配置

随着Linux设备从电脑逐渐扩展到手机、外设和家用电器，SSH的适用范围也越来越广。不仅程序员离不开它，很多普通用户也每天使用；SSH具备多种功能，可以用于很多场合。有些事情，没有它就是办不成

简单说，SSH是一种网络协议，用于计算机之间的加密登录。
如果一个用户从本地计算机，使用SSH协议登录另一台远程计算机，我们就可以认为，这种登录是安全的，即使被中途截获，密码也不会泄露。
最早的时候，互联网通信都是明文通信，一旦被截获，内容就暴露无疑。1995年，芬兰学者Tatu Ylonen设计了SSH协议，将登录信息全部加密，成为互联网安全的一个基本解决方案，迅速在全世界获得推广，目前已经成为Linux系统的标准配置。
需要指出的是，SSH只是一种协议，存在多种实现，既有商业实现，也有开源实现。

SSH主要用于远程登录。假定你要以用户名user，登录远程主机host，只要一条简单命令就可以了。

如果本地用户名与远程用户名一致，登录时可以省略用户名。

SSH的默认端口是22，也就是说，你的登录请求会送进远程主机的22端口。使用p参数，可以修改这个端口。

上面这条命令表示，ssh直接连接远程主机的2222端口。

SSH之所以能够保证安全，原因在于它采用了公钥加密。
整个过程是这样的：（1）远程主机收到用户的登录请求，把自己的公钥发给用户。（2）用户使用这个公钥，将登录密码加密后，发送回来。（3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

这个过程本身是安全的，但是实施的时候存在一个风险：如果有人截获了登录请求，然后冒充远程主机，将伪造的公钥发给用户，那么用户很难辨别真伪。因为不像https协议，SSH协议的公钥是没有证书中心（CA）公证的，也就是说，都是自己签发的。

可以设想，如果攻击者插在用户与远程主机之间（比如在公共的wifi区域），用伪造的公钥，获取用户的登录密码。再用这个密码登录远程主机，那么SSH的安全机制就荡然无存了。这种风险就是着名的“中间人攻击”（Man-in-the-middle attack）。

SSH协议是如何应对的呢？

如果你是第一次登录对方主机，系统会出现下面的提示：

这段话的意思是，无法确认host主机的真实性，只知道它的公钥指纹，问你还想继续连接吗？

所谓”公钥指纹”，是指公钥长度较长（这里采用RSA算法，长达1024位），很难比对，所以对其进行MD5计算，将它变成一个128位的指纹。上例中是98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d，再进行比较，就容易多了。

很自然的一个问题就是，用户怎么知道远程主机的公钥指纹应该是多少？回答是没有好办法，远程主机必须在自己的网站上贴出公钥指纹，以便用户自行核对。

假定经过风险衡量以后，用户决定接受这个远程主机的公钥。

系统会出现一句提示，表示host主机已经得到认可。

然后，会要求输入密码。

如果密码正确，就可以登录了。

当远程主机的公钥被接受以后，它就会被保存在文件 $HOME/.ssh/known_hosts 之中。下次再连接这台主机，系统就会认出它的公钥已经保存在本地了，从而跳过警告部分，直接提示输入密码。

每个SSH用户都有自己的 known_hosts 文件，此外系统也有一个这样的文件，通常是 /etc/ssh/ssh_known_hosts ，保存一些对所有用户都可信赖的远程主机的公钥。

使用密码登录，每次都必须输入密码，非常麻烦。好在SSH还提供了公钥登录，可以省去输入密码的步骤。

所谓”公钥登录”，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。

这种方法要求用户必须提供自己的公钥。如果没有现成的，可以直接用 ssh-keygen 生成一个：

运行上面的命令以后，系统会出现一系列提示，可以一路回车。其中有一个问题是，要不要对私钥设置口令（passphrase），如果担心私钥的安全，这里可以设置一个。

运行结束以后，在$HOME/.ssh/目录下，会新生成两个文件： id_rsa.pub 和 id_rsa 。前者是你的公钥，后者是你的私钥。

这时再输入下面的命令，将公钥传送到远程主机host上面：

好了，从此你再登录，就不需要输入密码了。

如果还是不行，就打开远程主机的 /etc/ssh/sshd_config 这个文件，检查下面几行前面”#”注释是否取掉。

然后，重启远程主机的ssh服务。

远程主机将用户的公钥，保存在登录后的用户主目录的 $HOME/.ssh/authorized_keys 文件中。公钥就是一段字符串，只要把它追加在 authorized_keys 文件的末尾就行了。

这里不使用上面的ssh--id命令，改用下面的命令，解释公钥的保存过程：

这条命令由多个语句组成，依次分解开来看：

（1） ”$ ssh user@host” ，表示登录远程主机；

（2）单引号中的 mkdir .ssh && cat >> .ssh/authorized_keys ，表示登录后在远程shell上执行的命令：

（3） ”$ mkdir -p .ssh” 的作用是，如果用户主目录中的.ssh目录不存在，就创建一个；

（4） ’cat >> .ssh/authorized_keys’ < ~/.ssh/id_rsa.pub 的作用是，将本地的公钥文件 ~/.ssh/id_rsa.pub ，重定向追加到远程文件 authorized_keys 的末尾。

写入 authorized_keys 文件后，公钥登录的设置就完成了。

10. SSH和SSL是什么意思

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事务，并使用钩子从其证书中提取服务器公钥。没有科学上的不可能性，如果做得恰当，它们的安全性将保持不变。