‘壹’ SSH的工作原理
传统的网络服务程序，比如 FTP ， POP ， Telnet ，本质上都是不安全的，因为它们在网络上用明文传送数据、用户账号和用户口令，很容易受到 中间人 攻击方式的攻击，攻击者会冒充真正的服务器接收用户传给服务器的数据，然后再冒充用户把数据传给真正的服务器。
为了满足安全性的需求， IETF 的网络工作小组制定了 Secure Shell （缩写为 SSH ），这是一项创建在 应用层 和 传输层 基础上的安全协议，为计算机上的 Shell 提供安全的传输和使用环境。
SSH 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄漏问题。通过 SSH 可以对所有传输的数据进行加密，也能够防止DNS欺骗和IP欺骗。
本文将会重点讨论 SSH 中用到的加密算法和建立安全连接的过程。
为了保证信息传输的安全性， SSH 使用了对称加密、非对称加密和散列等技术。
对称密钥加密又称为对称加密、私钥加密、共享密钥加密，是密码学中一类加密算法。这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。
SSH 使用对称密钥加密整个连接过程中传输的信息。值得注意的是，用户自己创建的public/private密钥对仅仅用于验证，不会用在加密连接上。对称加密允许对密码进行身份验证，以防止第三方窥探。
共享密钥通过密钥交换算法生成，它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥。客户端和服务端都参与了这个过程，过程的细节将在后面阐述。
生成的密钥将用来加密这次会话过程中客户端和服务端传输的数据。这个过程会在验证客户身份之前完成。
SSH 支持多种对称密钥算法，包括AES，Blowfish，3DES，CAST128和Arcfour。客户端和服务端可以配置采用算法的列表。客户端列表中第一个能被服务端支持的算法将被采用。
比如在Ubuntu 14.04上，客户端和服务端默认的配置如下： aes128-ctr , aes192-ctr , aes256-ctr , arcfour256 , arcfour128 , [email protected] , [email protected] , [email protected] , aes128-cbc , blowfish-cbc , cast128-cbc , aes192-cbc , aes256-cbc , arcfour 。
也就是说，如果两台Ubuntu 14.04采用默认配置，它们总是会采用 aes128-ctr 算法来加密连接。
在非对称加密方法中，需要一对密钥，一个是私钥，一个是公钥。这两个密钥数学相关。用公钥加密后所得的信息，只能用私钥才能解密。如果知道了其中一个，并不能计算另外一个。因此，如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。
SSH 在一些地方使用了非对称加密。
在密钥交换过程中使用到了非对称加密。在这个阶段，客户端和服务端生成临时密钥对，并且交换公钥来生成共享密钥。
在身份验证的过程中也使用了非对称加密。 SSH 密钥对用来向服务端验证客户端身份。客户端创建一对密钥，然后将公钥上传到远程服务器上，写入文件 ~/.ssh/authorized_keys 。
在创建共享密钥后，客户端必须向服务端证明身份。服务端会使用文件中的公钥加密一段信息，并将加密后的信息发送给客户端。如果客户端可以能够破解这段信息，那么就能够证明自己拥有相关的私钥。之后服务端会为客户端设置shell环境。
散列是电脑科学中一种对资料的处理方法，它通过某种特定的算法将要检索的项与涌来检索的索引关联起来，生成一种便于搜索的数据结构（散列表）。它也常用做一种资讯安全的方法，由一串资料中经过散列算法计算出来的资料指纹，来识别档案和资料是否有被篡改。
SSH 主要使用了散列消息认证码（Keyed-hash message authentication code，缩写为HMAC)，来确认消息没有被篡改。
上面提到的对称加密协商过程中，会使用消息认证码（MAC）算法。这个算法会从客户端支持的算法中选出。
在密钥协商完成后，所有的消息都必须携带MAC，用于通信双方验证消息的一致性。MAC值由共享密钥，消息的分组序列和实际消息内容计算得到。
在对称加密区域之外，MAC本身作为分组的最后部分被发送。研究者通常建议先机密数据，然后计算MAC
SSH 协议采用客户端-服务端模型对两方进行身份验证，并对它们之间的数据进行加密。
服务端在指定端口监听连接请求。它负责协商安全连接，认证连接方，并为客户端生成正确的shell环境。
客户端负责协商安全连接，验证服务器的身份是否与以前记录的信息相匹配，并提供凭证进行身份验证。
SSH会话分为两个阶段。第一个是同意和建立加密来保护未来的沟通。第二个阶段是对用户进行身份验证，并发现是否应该授予对服务器的访问权限。
当客户端发起请求后，服务端返回支持的协议版本。如果客户端可以匹配其中一个协议版本，则连接继续。服务端会提供它的公共主机密钥，客户端可以用这个密钥来验证服务端是否合法。
此时，通信双方采用迪菲-赫尔曼算法来协商会话密钥。
该算法的大致过程如下：
用于其余连接的共享密钥加密被称为二进制数据包协议。上述过程允许双方平等地参与生成共享密钥。
生成的密钥是对称密钥，这意味着用于加密消息的密钥也可以用于解密。其目的是将后面的通信包装在不能被外部人员解密的加密隧道中。
在生成会话密钥后，就开始进行用户身份验证。
根据服务器接受的方式，有几种不同的方法可用于身份验证。
最简单的方法是密码验证，其中服务器要求客户端输入尝试登陆账号的密码。密码是通过协商加密发送的。
虽然密码被加密，但由于密码的复杂性受到限制，因此通常不建议使用此方法。与其他身份验证的方法相比，自动脚本相对容易攻破正常长度的密码。
最为推荐的选择是使用SSH密钥对。SSH密钥对是非对称密钥。
公钥用于加密只能用私钥解密的数据。公钥可以自由共享，因为没有从公钥中导出私钥的方法。
验证流程如下：
可以看到，密钥的不对称性允许服务端使用公钥加密消息给客户端。然后，客户端可以通过正确解密消息来证明它拥有私钥。
笔者本科专业是信息安全，不过毕业后并没有从事安全行业，工作4年课堂上学习的知识基本忘的差不多了。
而SSH算是工作中最常用到的东西之一，其工作原理涉及不少密码学的东西。
写这篇博文，一是希望能帮助读者了解SSH，二也是希望自己能捡起一些专业知识。在互联网／软件相关行业里，不论是否从事安全工作，了解这些东西都是很有必要的。
‘贰’ SSH 协议原理、组成、认证方式和过程
SSH 是（Secure SHell protocol） 的简写，安全外壳协议（SSH）是一种在不安全网络上提供安全远程登录及其它安全网络服务的协议。
OpenSSH 是SSH （Secure SHell）协议的免费开源实现。SSH协议族可以用来进行远程控制，或在计算机之间传送文件。而实现此功能的传统方式，如telnet(终端仿真协议)、 rcp ftp、 rlogin、rsh都是极为不安全的，并且会使用明文传送密码。OpenSSH提供了服务端后台程序和客户端工具，用来加密远程控件和文件传输过程的中的数据，并由此来代替原来的类似服务。
在过去我们使用的rsh和telnet，因为包括登录时的ID和密码数据没有加密就传到网络上，存在安全上的问题。即使在内部网上，也有在因特网上的窃取和篡改等危险性。SSH将包括密码在内的所有数据都已进行了加密处理，可以进行更安全的远程操作。在SSH中，由于协议标准的不同而存在SSH1和SSH2两个不同的版本。SSH2是为了回避SSH1所使用的加密算法的许可证问题而开发的（现在这一许可证问题已经不存在了）。TLES 8中作为安装SSH协议的应用程序采用了开放源码的OpenSSH。OpenSSH与SSH1和SSH2的任何一个协议都能对应，但默认使用SSH2。
SSH 主要有三部分组成：
同时SSH协议框架中还为许多高层的网络安全应用协议提供扩展的支持。它们之间的层次关系可以用如下图来表示：
对于SSH这样以提供安全通讯为目标的协议，其中必不可少的就是一套完备的密钥机制。由于SSH协议是面向互联网网络中主机之间的互访与信息交换，所以主机密钥成为基本的密钥机制。也就是说，SSH协议要求每一个使用本协议的主机都必须至少有一个自己的主机密钥对，服务方通过对客户方主机密钥的认证之后，才能允许其连接请求。一个主机可以使用多个密钥，针对不同的密钥算法而拥有不同的密钥，但是至少有一种是必备的，即通过 DSS算法产生的密钥。关于DSS算法，请参考 FIPS-186 文档.SSH协议关于主机密钥认证的管理方案有两种，如下图所示:
每一个主机都必须有自己的主机密钥，密钥可以有多对，每一对主机密钥对包括公开密钥和私有密钥。在实际应用过程中怎样使用这些密钥，并依赖它们来实现安全特性呢？如上图所示，SSH协议框架中提出了两种方案。
在第一种方案中，主机将自己的公用密钥分发给相关的客户机，客户机在访问主机时则使用该主机的公开密钥来加密数据，主机则使用自己的私有密钥来解密数据，从而实现主机密钥认证，确定客户机的可靠身份。在图2（a）中可以看到，用户从主机A上发起操作，去访问，主机B和主机C，此时，A成为客户机，它必须事先配置主机B和主机C的公开密钥，在访问的时候根据主机名来查找相应的公开密钥。对于被访问主机（也就是服务器端）来说则只要保证安全地存储自己的私有密钥就可以了。
在第二种方案中，存在一个密钥认证中心，所有系统中提供服务的主机都将自己的公开密钥提交给认证中心，而任何作为客户机的主机则只要保存一份认证中心的公开密钥就可以了。在这种模式下，客户机在访问服务器主机之前，还必须向密钥认证中心请求认证，认证之后才能够正确地连接到目的主机上。
很显然，第一种方式比较容易实现，但是客户机关于密钥的维护却是个麻烦事，因为每次变更都必须在客户机上有所体现；第二种方式比较完美地解决管理维护问题，然而这样的模式对认证中心的要求很高，在互联网络上要实现这样的集中认证，单单是权威机构的确定就是个大麻烦，有谁能够什么都能说了算呢？但是从长远的发展来看，在企业应用和商业应用领域，采用中心认证的方案是必要的。
另外，SSH协议框架中还允许对主机密钥的一个折中处理，那就是首次访问免认证。首次访问免认证是指，在某客户机第一次访问主机时，主机不检查主机密钥，而向该客户都发放一个公开密钥的拷贝，这样在以后的访问中则必须使用该密钥，否则会被认为非法而拒绝其访问。
在整个通讯过程中，为实现 SSH的安全连接，服务器端与客户端要经历如下五个阶段：
* 版本号协商阶段，SSH目前包括 SSH1和SSH2两个版本， 双方通过版本协商确定使用的版本
* 密钥和算法协商阶段，SSH支持多种加密算法， 双方根据本端和对端支持的算法，协商出最终使用的算法
* 认证阶段，SSH客户端向服务器端发起认证请求， 服务器端对客户端进行认证
* 会话请求阶段， 认证通过后，客户端向服务器端发送会话请求
* 交互会话阶段 ，会话请求通过后，服务器端和客户端进行信息的交互
Q1: SSH的版本和区别。
SSH2避免了RSA的专利问题，并修补了CRC的缺陷。SSH2用数字签名算法（DSA）和Diffie-Hellman（DH）算法代替RSA来完成对称密钥的交换，用HMAC来代替CRC。同时SSH2增加了AES和Twofish等对称加密算法。
A1: SSH(Secure SHell)到目前为止有两个不兼容的版本——SSH1和SSH2。SSH1又分为1.3和1.5两个版本。SSH1采用DES、3DES、 Blowfish和RC4等对称加密算法保护数据安全传输，而对称加密算法的密钥是通过非对称加密算法（RSA）来完成交换的。SSH1使用循环冗余校验码（CRC）来保证数据的完整性，但是后来发现这种方法有缺陷。
更多内容请参考The SSHv1 Protocol & The SSHv2 Protocol
Q2: 什么是HMAC？
A2: HMAC(Hash Message Authentication Code) ，散列消息鉴别码，基于密钥的Hash算法的认证协议。消息鉴别码实现鉴别的原理是，用公开函数和密钥产生一个固定长度的值作为认证标识，用这个标识鉴别消息的完整性。使用一个密钥生成一个固定大小的小数据块，即MAC，并将其加入到消息中，然后传输。接收方利用与发送方共享的密钥进行鉴别认证等。
Q3: 什么是X11 forwarding？
A3: sh的X11 forwarding特性可以使X client和X server安全地通讯。使用X11 forwarding后，从X client到X Server方向的数据先被送至ssh server，ssh server利用和ssh client的安全通道转发给ssh client，再由ssh client转发给X server，从X server到X client的数据流同理。这里ssh server和ssh client充当了X client和X server间数据的转发器，由于ssh server和X client、ssh client和X server一般在同一台机器上，它们之间是一种安全的进程间通讯，而ssh server和ssh client间的通讯也是安全的，所以X client和X server间的通讯就是安全的。
Q4: 什么是TTY？
A4: 终端是一种字符型设备，它有多种类型，通常使用tty来简称各种类型的终端设备。tty是 Teletype的缩写。Teletype是最早出现的一种终端设备，很象电传打字机，是由Teletype公司生产的。设备名放在特殊文件目录/dev/下。
Q5: 简单描述下SSH运行的过程？
‘叁’ 非对称加密、SSH加密算法、数字签名简介
非对称加密算法的核心源于数学问题，它存在公钥和私钥的概念，要完成加解密操作，需要两个密钥同时参与。我们常说的“公钥加密，私钥加密”或“私钥加密， 公钥解密”都属于非对称加密的范畴。公钥加密的数据必须使用私钥才可以解密，同样，私钥加密的数据也 只能通过公钥进行解密。
相比对称加密，非对称加密的安全性得到了提升，但是也存在明显的缺点，非对称加解密的效率要远远小于对称加解密。所以非对称加密往往被用在一些安全性要求比较高的应用或领域中。
RSA加密算法是一种典型的非对称加密算法，它基于大数的因式分解数学难题，它也是应用最广泛的非对称加密算法，于1978年由美国麻省理工学院（MIT）的三位学者：Ron Rivest、Adi Shamir 和 Leonard Adleman 共同提出。
它的原理较为简单，我们假设有消息发送方A和消息接收方B，通过下面的几个步骤，我们就可以完成消息的加密传递：
（1）消息发送方A在本地构建密钥对，公钥和私钥；
（2）消息发送方A将产生的公钥发送给消息接收方B；
（3）B向A发送数据时，通过公钥进行加密，A接收到数据后通过私钥进行解密，完成一次通信；
（4）反之，A向B发送数据时，通过私钥对数据进行加密，B接收到数据后通过公钥进行解密。
由于公钥是消息发送方A暴露给消息接收方B的，所以这种方式也存在一定的安全隐患，如果公钥在数据传输过程中泄漏，则A通过私钥加密的数据就可能被解密。
如果要建立更安全的加密消息传递模型，需要消息发送方和消息接收方各构建一套密钥对，并分别将各自的公钥暴露给对方，在进行消息传递时，A通过B的公钥对数据加密，B接收到消息通过B的私钥进行解密，反之，B通过A的公钥进行加密，A接收到消息后通过A的私钥进行解密。
当然，这种方式可能存在数据传递被模拟的隐患，我们可以通过数字签名等技术进行安全性的进一步提升。由于存在多次的非对称加解密，这种方式带来的效率问题也更加严重。可以详读这两篇文章：RSA 算法原理 （一） （二）
在SSH安全协议的原理中， 是一种非对称加密与对称加密算法的结合，先看下图：
这里进行一下说明：
（1）首先服务端会通过非对称加密，产生一个 公钥 和 私钥
（2）在客户端发起请求时，服务端将 公钥 暴露给客户端，这个 公钥 可以被任意暴露；
（3）客户端在获取 公钥 后，会先产生一个由256位随机数字组成的会话密钥，这里称为口令；
（4）客户端通过 公钥 将这个口令加密，发送给服务器端；
（5）服务器端通过 私钥 进行解密，获取到通讯口令；
之后，客户端和服务端的信息传递，都通过这个口令进行对称的加密。
这样的设计在一定程度上提高了加解密的效率，不过，与客户端服务端各构建一套密钥对的加解密方式相比，在安全性上可能有所下降。在上面所述的通过口令进行加密的过程中，数据也是可以被窃听的，不过由于密钥是256个随机数字，有10的256次方中组合方式，所以破解难度也很大。相对还是比较安全的。服务端和客户端都提前知道了密钥，SSH的这种方式，服务端是通过解密获取到了密钥。
现在知道了有非对称加密这东西，那数字签名是怎么回事呢？
数字签名的作用是我对某一份数据打个标记，表示我认可了这份数据（签了个名），然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
有了上述非对称加密算法，就可以实现这个需求：
‘肆’ 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 文件后，公钥登录的设置就完成了。
‘伍’ ssh使用详解
简单来说，ssh是一种 网络协议 ，用于计算机之间的加密登录。如果一个用户从本地计算机，使用ssh协议登录另一台远程计算机，我们就可以认为，这种登录是安全的，即使被中途截获，密码也不会泄露。
SSH 之所以安全是采用了公钥加密的方式，通过客户自己签发公钥加密用户密码，再通过主机持有的私钥解密；不像 HTTPS 协议存在证书管理中心CA用于验证公钥的合法性，因此，存在被中间人劫持的风险，即劫持登录请求发送篡改的公钥来截获用户登录密码，俗称”中间人攻击“；
不过 SSH 存在一套自有的验证方式：口令验证及密钥验证，可有效避免大部分的攻击；
使用上述命令测试连接性及验证流程；
通过 ssh-keygen 工具生成本地公钥文件，常用命令如下：
在 $HOME/.ssh/ 目录下，会新生成两个文件： id_rsa.pub 和 id_rsa 。 id_rsa.pub 是公钥， id_rsa 是私钥，其中 id_rsa 为默认文件名称，若如上图指定了文件路径及名称，则按照指定路径及文件名生成；
说明：若 ssh 登录使用密钥验证方式登录，则需要输入私钥的密码(生成密钥时指定的密码)，若使用 ssh-agent 代理，则在同一个 session 会话下，只需要输入一次私钥密码即可，由 ssh-agent 帮我们代理，避免每次登录都需要输入私密码；
若登录时未开启，可手动开启 ssh-agent ，可通过如下命令：
添加生成的 SSH key 到 ssh-agent :
查看添加的 SSH key ：
若需要免密登录，则需要将用户的 public key 文件内存追加复制到登录主机的 authorized_keys 配置文件中(默认路径为 ~/.ssh/authorized_keys )，或者直接通过 ssh--id 工具完成，具体如下：
使用上述命令后即可实现 免密登录 ；
ssh 配置包括系统级别的(针对客户端的默认为 /etc/ssh/ssh_config ，针对服务端的``/etc/ssh/sshd_config )及用户级别的配置文件(默认为 ~/.ssh/config`)；且配置文件存在优先级，低优先级的配置项可视作默认值；而高优先级的配置项则会覆盖默认值。按优先级，有如下排序：
/etc/ssh/config 配置文件选项如下：
/etc/ssh/sshd_config 配置文件选项如下：
常用的选项如下：
ssh -T [email protected] 验证连接性，成功如下：
ssh配置文件详解
git-ssh 配置和使用
ssh-keygen - Generate a New SSH Key
最佳搭档：利用 SSH 及其配置文件节省你的生命