最近要使用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其他的還會有問題。
現在只是測了測簡單的功能，具體的測試，還是等明天吧。怕遺忘，故記錄並分享，希望可以幫助一些人。
一定要看二，二找出了真正原因。