Out FTP服务器经过迁移以获得更好的安全性(不知道有关它的详细信息)。
但升级后,我们无法从服务器下载/上传文件。它在升级之前工作正常。错误日志显示:
ns0:Client无法连接到FTP服务器。http://schemas.cordys.com/ftpconnector/1.1Cordys.FTPConnector.Messages.ftpserverConnectionFailedcom.eibus.applicationconnector.ftp.FTPException:算法协商失败
at com.eibus.applicationconnector.ftp.CordysSFTPClient.connect(CordysSFTPClient.java:78) 在com.eibus.applicationconnector.ftp.FTPCommand.connect(FTPCommand.java:86) 在com.eibus.applicationconnector.ftp.FTPTransaction.process(FTPTransaction.java:109) 在com.eibus.soap.SOAPTransaction.handleBodyBlock(SOAPTransaction.java:1340) 在com.eibus.soap.SOAPTransaction。(SOAPTransaction.java:546) 在com.eibus.soap.SOAPTransaction。(SOAPTransaction.java:195) 在com.eibus.soap.Processor.onReceive(Processor.java:1024) 在com.eibus.soap.Processor.onReceive(Processor.java:997) 在com.eibus.connector.nom.Connector.onReceive(Connector.java:483) at com.eibus.transport.NonTransactionalWorkerThreadBody.doWork(NonTransactionalWorkerThreadBody.java:61) at com.eibus.transport.NonTransactionalWorkerThreadBody.run(NonTransactionalWorkerThreadBody.java:26) 在com.eibus.util.threadpool.WorkerThread.run(WorkerThread.java:67) 引起:com.jcraft.jsch.JSchException:算法协商失败 在com.jcraft.jsch.Session.receive_kexinit(Session.java:520) 在com.jcraft.jsch.Session.connect(Session.java:286) 在com.jcraft.jsch.Session.connect(Session.java:150) 在com.eibus.applicationconnector.ftp.CordysSFTPClient.connectOnce(CordysSFTPClient.java:124) 在com.eibus.applicationconnector.ftp.CordysSFTPClient.connect(CordysSFTPClient.java:64) ......还有11个
使用的jsch jar版本是:jsch-0.1.41.jar 使用的java版本是:1.7.0_40
请注意
试用1 在google上花了一些时间后,我明白升级jsch jar版本可能有所帮助。所以我使用了最新的jsch jar:jsch-0.1.54.jar。在此之后我开始收到以下错误:
com.eibus.applicationconnector.ftp.FTPException:Session.connect:java.security.InvalidAlgorithmParameterException:Prime大小必须是64的倍数,且只能是512到1024(含) 在com.eibus.applicationconnector.ftp.CordysSFTPClient.connect(CordysSFTPClient.java:78) 在com.eibus.applicationconnector.ftp.FTPCommand.connect(FTPCommand.java:86) 在com.eibus.applicationconnector.ftp.FTPTransaction.process(FTPTransaction.java:109) 在com.eibus.soap.SOAPTransaction.handleBodyBlock(SOAPTransaction.java:1340) 在com.eibus.soap.SOAPTransaction。(SOAPTransaction.java:546) 在com.eibus.soap.SOAPTransaction。(SOAPTransaction.java:195) 在com.eibus.soap.Processor.onReceive(Processor.java:1024) 在com.eibus.soap.Processor.onReceive(Processor.java:997) 在com.eibus.connector.nom.Connector.onReceive(Connector.java:483) at com.eibus.transport.NonTransactionalWorkerThreadBody.doWork(NonTransactionalWorkerThreadBody.java:61) at com.eibus.transport.NonTransactionalWorkerThreadBody.run(NonTransactionalWorkerThreadBody.java:26) 在com.eibus.util.threadpool.WorkerThread.run(WorkerThread.java:67) 引起:com.jcraft.jsch.JSchException:Session.connect:java.security.InvalidAlgorithmParameterException:Prime大小必须是64的倍数,并且只能是512到1024(含) 在com.jcraft.jsch.Session.connect(Session.java:565) 在com.jcraft.jsch.Session.connect(Session.java:183) 在com.eibus.applicationconnector.ftp.CordysSFTPClient.connectOnce(CordysSFTPClient.java:124) 在com.eibus.applicationconnector.ftp.CordysSFTPClient.connect(CordysSFTPClient.java:64) ......还有11个
试用2 :已安装无限强度辖区政策文件(www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html),这也是没有使用。得到了同样的错误
任何指针都会有所帮助。
以下是我用来连接ftp的代码:
private void connectOnce(FTPConfiguration ftpConfiguration) throws JSchException {
JSch jsch = new JSch();
this.session = jsch.getSession(ftpConfiguration.getUsername(), ftpConfiguration.getServer(), ftpConfiguration.getPort());
this.session.setPassword(ftpConfiguration.getPassword());
Properties config = new Properties();
config.put("StrictHostKeyChecking", "no");
this.session.setConfig(config);
if (logger.isDebugEnabled()) {
logger.debug("Opening SFTP connection to " + ftpConfiguration.getServer());
}
this.session.connect();
}
答案 0 :(得分:2)
我想我找到了解决方案。
解决方案涉及修改jsch源代码。 (最新版本1.0.54)。我做了一些研究,最终能够强迫jsch使用“Bouncy Castle”安全提供商。这涉及到更改jsch库中以下类的源代码:
我在尝试使用keyGenerator的geInstance时添加了以下参数。
KeyPairGenerator.getInstance("DSA","BC");
从这篇文章中获得了一些想法(I've put security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider but it isn't being used during SSL handshake)