java 实现 sftp 文件的上传下载——踩坑记

    最近要使用java实现sftp上传文件。上网搜索了一下，觉得十分简单。添加jsch jar包，再写点链接方法，上传下载删除方法。ok。为了测试连接性。我下载了一个工具 freesshd。freesshd可以在windows上创建一个通过sftp方式访问的服务器。一切都很顺利的进行着。
   等到代码写完。到正式环境上跑。在connect的时候开始报错。心瞬间慌了。进一步了解，发觉是服务器的原因。因为我是在自己的电脑上，用的是windows系统。而正式环境上是linux系统，对于linux系统我也只是会些基本的命令。并不了解sshd服务。百度了一下，在windows系统上安装了vm虚拟机，在虚拟机上安装了linux系统。linux系统安装的时候回自动安装sshd,就算没有安装，一条yum语句就简单的实现了安装。
   linux服务起了之后，根据报错原因。上网一查，解决办法一大堆。这里是重点。许多人说jsch jar包不支持sshd的算法。（通过linux sshd -T|grep kex可以查看linux sshd的加密算法）,jsch 默认的加密算法是diffie-hellman-group1-sha1，这种算法linux的sshd虽然支持，但是没有打开。正常思维 打开sshd的这种加密算法。如何打开，网上很多人已经支招了，在sshd_config配置文件的末尾添加kex.......， diffie-hellman-group1-sha1。我按照网上的说法在本机虚拟器的linux操作系统上加了上去，再通过java代码访问成功！但是通过filezilla工具访问sshd,报错...心继续慌乱
  filezilla报错原因是什么呢？原来是不支持这种diffie-hellman-group1-sha1加密算法。解决办法也有，别把这种算法放在众多加密算法的首项。这样问题就解决了。 no no no no no。问题可不是这么解决的。首先diffie-hellman-group1-sha1这种算法linux为什么会关闭（或者说是不建议使用），仔细搜查了一下。原来linux为了安全起见，关闭了许多的弱加密算法，这种算法就是其中之一。这也是filezilla为什么不支持的原因了。另外，服务器一般不会在自己的公司，或者是别人提供的服务器，你总不可以让别人去修改服务器，更何况是将自己的服务器改的不安全。再次陷入惶恐。
    接下来的思路，自然是修改自己的代码，或者想办法让自己的jsch jar包支持更多的加密算法。又是一通搜索，此时网上大多数人还是觉得jsch支持的算法只是一两种。因此我被这种错误的说法误导了，找了好久没有找到添加jsch插件的解决办法。当然还是有很少人是这么说的，jsch支持的算法不止一种。在jsch某个版本之后支持diffie-hellman-group-exchange-sha256.在代码中我通过config.put("kex", "diffie-hellman-group1-sha1"),和config.put("diffie-hellman-group-exchange-sha256"),和config.put("kex", "diffie-hellman-group14-sha1"),居然报了三种错 分别是recieve_kex、End of io、accept_kex，仔细的想了想，肯定有一个是linux sshd不支持的算法，还有一个是jsch不支持的加密算法。那么end of io是什么。我个人猜测是传输的东西无法解析。
  在上网找，一共看到两片文章，提到了那么一句而且本人都没有去实现的方法。jdk添加插件。恍然醒悟。因为jdk不支持这种加密算法。导致两者之间的传输出现输入输出流异常，很合情理啊！升级到jdk8,据说jdk8支持的加密算法很多。傻傻的升了，反正也不是很烦。升级完成。发现项目报错，上网一搜myeclipse10不支持jdk8。因为公司项目还是用低版本的jdk，开发工具用的也是myeclipse10,所以升级jdk也不现实，这时候伟大jce出现了。jce就像jdk的一个补丁。不晓得的朋友，百度一下jce的安装教程。其实就是下载，解压，将jdk以及jre安装目录下的两个文件替换掉。最多再重启一下开发工具。jdk加密算法变多。成功！至此问题就全部解决了。最后再说一句jsch版本选0.1.5.4或者0.1.5.3其他的还会有问题。
   现在只是测了测简单的功能，具体的测试，还是等明天吧。怕遗忘，故记录并分享，希望可以帮助一些人。