SFTP传输，验证文件完整性
第一次接触与合作方的文件传输方面的需求，这里稍微整理一下整个流程纪要，以免遗忘~
如果有不恰当的地方，还请指教~
传输方法
- 生成N个业务文件，并对每个文件的内容采用AES进行加密；
- 生成OkFile.txt文件，记录N个文件对应的行数以及大小，AES加密；（仅用于对每个文件进行粗略的校验）
- 将N个业务文件和OKFile文件进行压缩打包为tar.gz文件；
- 对tar.gz文件求md5码，生成md5文件；（防止第三方篡改某个文件的内容，供合作方验证文件完整性）
- 将tar.gz文件和md5文件传送给合作方；（合作方在收到文件后，会采用相同算法对tar.gz文件求md5码，并比对md5值是否相同，如果相同，说明文件完整性没问题）
- 如何传输？== 复用前人的方法，将需要传输的文件放在SFTP服务器上，对方定时拉取SFTP服务器上的文件；（注意账号的读写权限）
这里为什么采用了sftp而不是用https传输呢？下面对这两部分协议进行调研，但是感觉还是没有get到心中的点上，后续有时间继续研究~
https还是sftp？
对于文件的传输，我们更加关心的是传输文件的大小以及安全性问题；对于性能方面的考虑，可能没有那么重要。
安全性上来说，https和sftp协议都是安全的传输协议，https = http + ssl，sftp是基于ssh的安全文件传输协议；
性能上来说，https协议的传输速度可能比sftp速度更快；
参考HTTPS or SFTP – which is best?这篇博文，最后有说到，对于一些普通的用户，如果仅仅是要下载文件的功能，那么https是更好的选择（这里是从用户体验考虑）；然而，如果涉及传输的文件比较复杂，比较大，那么请采用sftp协议。
SFTP安全性？
sftp的安全性是由ssh协议进行保证，因此只需要弄懂ssh协议的安全性原理就ok了。
ssh协议目的是实现安全的远程登录或其他网络安全服务，根源还是采用了非对称加密和对称加密的算法实现，但是却无法解决中间人攻击的问题。https是通过ca证书解决，那么ssh是如何解决的呢？
基于口令的认证
由于ssh的publish key和private key都是自己生成的，没办法进行公证，只能通过client自己对公钥进行确认。因此，在第一次登录某台server时，系统中会出现如下提示信息：
这里采用主机密钥指纹（MD5）而不是直接采用主机密钥，是因为主机密钥的key过长（采用rsa算法生成的公钥有024位），不易比较，因此对公钥进行hash生成一个128位的指纹。
点击 接受并保存 后，就表示该server已经被确认，并且会追加到client的known_hosts文件中。后续会用该公钥对密钥进行加密传输给server，此时server就能够安全的拿到对称加密的密钥了，后面对数据的加密也是采用对称加密的密钥进行。
基于公钥的认证
公钥不同于上面的口令认证，不需要输入密码，而是需要用户手动将client的公钥添加到server端的authorized_key中。这样用户发送请求给server端时，server首先生成随机数R，并用client的公钥对其加密，得到pubKey®，返回给客户端；客户端拿到数据后，用私钥解密，得到R，并用MD5对R和sessionKey生成摘要信息，将摘要信息传输给server，server同样用MD5对R和sessionKey生成摘要，对比两个摘要信息，完整认证过程。
由上面的两种方法认证过程可知，ssh协议还是非常安全的，也能在一定程度上防止中间人攻击。为什么说是一定程度上呢？因为ssh协议的安全认证过程的前提是第一次连接认证的时候，不会被中间人攻击，那么client就会把指纹存放在本地的known_hosts文件中，以后的通讯就会通过known_hosts文件中的内容进行验证。但是，如何中间人攻击出现在第一次连接认证的时候，那么安全性就无法得到保证了。
