Community
Participate
Working Groups
extssh connection fails with a server key larger than 768 bits. Using OpenSSH 3.0 on linux 2.0.34. Don't have more details since the problem is about six months old and I don't have access to the same environment I used then.
I'm not sure if this is relevant since we only support password authentication with extssh. Should investigate what role server keys play in password authentication, if any.
Server key is needed for password authentication - that's because the server public key is used to encrypt the password sent from the client. I am having problem using Eclipse with a SSH server that's using 1024bit server key (e.g. IBM Internal OpenSource Bazaar). You can replicate this problem by changing the sshd on your server to use 1024bit key (on a linux box, add/modify your sshd config with ServerKeyBits 1024) it will say Unexpected End of stream and stop. It fails for 2.0 and 2.01.
One bug was found and fixed that may have been causing this problem. If possible, could you try the latest 2.1 integration build?
I tried Integration build I20021016 and it doesn't work, and the following error message is found in "configuration details" !SESSION Oct 18, 2002 17:46:25.954 --------------------------------------------- java.fullversion=J2RE 1.3.1 IBM Windows 32 build cn131-20020710 (JIT enabled: jitc) BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86 -install file:D:/eclipse/ !ENTRY org.eclipse.ui 4 4 Oct 18, 2002 17:46:25.954 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Oct 18, 2002 17:46:25.954 !MESSAGE -17 !STACK 0 java.lang.ArrayIndexOutOfBoundsException: -17 at org.eclipse.team.internal.ccvs.ssh.Misc.encryptRSAPkcs1(Misc.java:437) at org.eclipse.team.internal.ccvs.ssh.Client.send_SSH_CMSG_SESSION_KEY(Client.java:655) at org.eclipse.team.internal.ccvs.ssh.Client.receive_SSH_SMSG_PUBLIC_KEY(Client.java:569) at org.eclipse.team.internal.ccvs.ssh.Client.login(Client.java:486) at org.eclipse.team.internal.ccvs.ssh.Client.connect(Client.java:404) at org.eclipse.team.internal.ccvs.ssh.SSHServerConnection.open(SSHServerConnection.java:76) at org.eclipse.team.internal.ccvs.core.connection.Connection.open(Connection.java:123) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.createConnection(CVSRepositoryLocation.java:150) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.openConnection(CVSRepositoryLocation.java:333) at org.eclipse.team.internal.ccvs.core.client.Session.open(Session.java:295) at org.eclipse.team.internal.ccvs.core.client.Session.run(Session.java:188) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolder.getMembers(RemoteFolder.java:325) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolder.getMembers(RemoteFolder.java:253) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolder.members(RemoteFolder.java:598) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.members(CVSRepositoryLocation.java:231) at org.eclipse.team.internal.ccvs.ui.model.BranchTag$1.run(BranchTag.java:63) at org.eclipse.team.internal.ui.TeamUIPlugin$2.run(TeamUIPlugin.java:142) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:66) at org.eclipse.team.internal.ui.TeamUIPlugin.runWithProgress(TeamUIPlugin.java:139) at org.eclipse.team.internal.ccvs.ui.CVSUIPlugin.runWithProgress(CVSUIPlugin.java:221) at org.eclipse.team.internal.ccvs.ui.model.BranchTag.getChildren(BranchTag.java:59) at org.eclipse.ui.model.WorkbenchContentProvider.getChildren(WorkbenchContentProvider.java:51) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:571) at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:346) at org.eclipse.jface.viewers.StructuredViewer.getSortedChildren(StructuredViewer.java:447) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:241) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:614) at org.eclipse.jface.viewers.AbstractTreeViewer$1.treeExpanded(AbstractTreeViewer.java:626) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:173) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java(Compiled Code)) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:1764) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:3703) at org.eclipse.swt.widgets.Composite.WM_NOTIFY(Composite.java:639) at org.eclipse.swt.widgets.Control.windowProc(Control.java(Compiled Code)) at org.eclipse.swt.widgets.Display.windowProc(Display.java(Compiled Code)) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java(Compiled Code)) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:152) at org.eclipse.swt.widgets.Tree.WM_LBUTTONDOWN(Tree.java:1393) at org.eclipse.swt.widgets.Control.windowProc(Control.java(Compiled Code)) at org.eclipse.swt.widgets.Display.windowProc(Display.java(Compiled Code)) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1420) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1403) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:775) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
I have reproduced this. The problem is that the chunk of data we are trying to encrypt, is too big for the given modulus. This results in the line "offset+=block.length-data.length- 3" (line 435 in Misc.java rev.1.6), giving a negative offset.
The problem is in Client.java 1.12, line 655. The session key encryption code always uses the server key first. This breaks if the server key is numerically larger than the host key. The fix is to follow the SSH protocol spec which says, "The resulting string is then encrypted using the smaller key (one with smaller modulus), and the result is then encrypted using the other key:" byte[] result; if (new BigInteger(1,server_key_public_modulus).compareTo(new BigInteger (1,host_key_public_modulus)) == -1) { result = Misc.encryptRSAPkcs1(session_key_xored, server_key_public_exponent, server_key_public_modulus); result = Misc.encryptRSAPkcs1(result, host_key_public_exponent, host_key_public_modulus); } else { result = Misc.encryptRSAPkcs1(session_key_xored, host_key_public_exponent, host_key_public_modulus); result = Misc.encryptRSAPkcs1(result, server_key_public_exponent, server_key_public_modulus); }
Created attachment 2251 [details] Proposed fix
Fix released to HEAD
*** Bug 24298 has been marked as a duplicate of this bug. ***
