Community
Participate
Working Groups
We use git over ssh with public key authentication. Say I want to push to the repo, I fill the URI as 'ssh://foo@bar.example.com/data/git/project'. I leave the password blank because we use pubkey auth. Egit asks for password for '/home/me/.ssh/id_rsa', which I enter correctly but I can't get past this screen, egit just keeps showing me this password dialog. Of course doing things manually through command-line git works perfectly, that is, the password is correct, authentication at server works, etc.
- which version of EGit are you using on which platform version ? - did you try with the exact same URL from native git ? usually bare repos have postfix .git in their URL - did you verify that Eclipse points at the right .ssh directory (Preferences > General > Network Connections > SSH2 > General > SSH2 home)
(In reply to comment #1) > - which version of EGit are you using on which platform version ? Linux, 64-bit, egit 0.9.3 > - did you try with the exact same URL from native git ? usually bare repos have > postfix .git in their URL Yes tried. I know we don't have a .git suffix but otherwise it's just a normal git bare repo that works with other people/intellij idea/command line git/... - is that a problem? > - did you verify that Eclipse points at the right .ssh directory (Preferences > > General > Network Connections > SSH2 > General > SSH2 home) Yes.
(In reply to comment #2) > (In reply to comment #1) > > - which version of EGit are you using on which platform version ? > > Linux, 64-bit, egit 0.9.3 We also tried 0.10.0 and nightly, same problem. Any ideas?
I see the bug has been ASSIGNED - any news?
Apparently the problem is caused by the fact that the eclipse-internal ssh that is used by egit (right?) does not handle private keys encrypted by AES but only by 3DES. Can this be fixed?
bump?
Sorry for the late answer. Yes, it's true: EGit/JGit is using the jschd (http://www.jcraft.com/jsch/) component for ssh traffic. To be honest: I have no idea how we can modify EGit/JGit to make other types of key encryptions work. One other problem: You say that you have problems using AES encrypted keys (in contrast to 3DES encrypted keys). I wanted to reproduce your problem but couldn't find the switches in the different keygen tools (in Eclipse, in openSsh's ssh-keygen tool) where I can choose between the encryption. I can always only choose between RSA and DSA keys to be created. How can I recreate your problem.
(In reply to comment #7) > To be honest: I have no idea how we can modify EGit/JGit to make other types of key encryptions work. To be honest, I looked at the source code of the JSch library and I have serious doubts about its ability to establish a SECURE (ie. without all these pesky crypto attacks) shell connection... so why not use a real and proven solution like openssh? > One other problem: You say that you have problems using AES encrypted keys > (in contrast to 3DES encrypted keys). I wanted to reproduce your problem but > couldn't find the switches in the different keygen tools (in Eclipse, in > openSsh's ssh-keygen tool) where I can choose between the encryption. I can > always only choose between RSA and DSA keys to be created. How can I recreate > your problem. It's part of openssh since some (recent) version. You need to have a passphrase on the key (that's why it's encrypted). Private key from OpenSSH_5.2p1 starts with: DEK-Info: DES-EDE3-CBC Private key from OpenSSH_5.6p1 starts with: DEK-Info: AES-128-CBC In JSch source they only check for the string CBC, with no regard for the cipher. Thus the probable enhancement would be to distinguish the cipher algo and decrypt the key accordingly. The AES algo should be available in JSch as it can be used for encrypting the SSH session itself. That is if you want to stick with JSch.
One change which may help you is now introduced by http://egit.eclipse.org/r/#change,2037. If you get latest EGit/JGit builds this change is included. With this change JGit honors GIT_SHH environment variable. You may set the environment variable e.g. to plink to let this program deal with ssh connections. Does this help you?
(In reply to comment #9) > Does this help you? Yes, we set GIT_SSH to /usr/bin/ssh and works as expected. It would be cool to make this a GUI setting though as setting environment variables is advanced stuff.
I was not successful to use ssh keys defined in preferences (see comment 1) on Windows. I am getting 5x passphrase dialog similarly as observed in bug 308205 then "Auth fail" message. The only way I was able to set it up on Windows: 1. Installed cygwin 2. Under cygwin setup keychain to be able to reuse ssh keys between sessions "eval $(keychain --eval ~/.ssh/id_rsa)" 3. Use GIT_SSH to point to ssh program. That gotta be DOS path like "C:\..." not cygwin style. I set "export GIT_SSH" in bash profile 4. Run eclipse *under cygwin* to get advantage of SSH_... environment set by keychain on step 2. After that ssh keys started working.
(In reply to comment #10) > (In reply to comment #9) > > Does this help you? > > Yes, we set GIT_SSH to /usr/bin/ssh and works as expected. It would be cool to > make this a GUI setting though as setting environment variables is advanced > stuff. This helps for me, too. +1 for adding a GUI Toggle between internal and external ssh toolkit
Using an environment variable works, but is inconvenient. It seems support for private keys ciphered with aes192-cbc and aes128-cbc is a new feature supported by jsch 0.1.44 released in November 2010. Is this version already shipped with Egit ?
jgit comes with jsch 0.1.44 since Mar 31 2011. You get this version from nightly download [1]. Next release is planned for end of April. Please retest. [1] http://download.eclipse.org/egit/updates-nightly
Change bringing this jsch version was http://egit.eclipse.org/r/#change,2211
could you retry with current nightly build and jsch 0.1.44 which should be supporting aes ?
(In reply to comment #16) > could you retry with current nightly build and jsch 0.1.44 which should be > supporting aes ? I have installed nthe nightly version (0.12.1), but it didn't work. It seems I still have Jsch 0.1.41 installed, not 0.1.44. It appears in the Eclipse installation details tab as 0.1.41.v200903070017 with plugin ID com.jcraft.jsch. There is also a Jsch core 1.1.200 with plugin id org.eclipse.jsch.core, so I guess this one is an eclipse wrapper. How can I force 0.1.44 to be installed ?
According to this message: http://www.eclipse.org/forums/index.php/mv/msg/209439/671397/ A feature patch should be created.Could this be provided by Egit ?
(In reply to comment #17) > (In reply to comment #16) > > could you retry with current nightly build and jsch 0.1.44 which should be > > supporting aes ? > > I have installed nthe nightly version (0.12.1), but it didn't work. 0.12.1 is not a current nightly but the latest stable release. Install egit nightly (1.0.0-SNAPSHOT) from [1]. [1] http://download.eclipse.org/egit/updates-nightly
(In reply to comment #19) > 0.12.1 is not a current nightly but the latest stable release. > Install egit nightly (1.0.0-SNAPSHOT) from [1]. > > [1] http://download.eclipse.org/egit/updates-nightly I have checked again, I do have changed the update site to updates-nightly. When I check for updates, now I find Eclipse 1.0.0.201105231713. I don't know if it is really a nightly or a stable release. Is it possible my change to updates-nightly was not taken into account ? Nevertheless, I tested this version and it still doesn't work. My Jsch version still seem to be 0.1.41 in the plugins list tab on the Eclipse installation details, and not 0.1.44.
Sounds like jsch library is a bit shaky and might cause attempts to fail even if everything is configured ok. See: http://groups.google.com/group/repo-discuss/browse_thread/thread/0eba8b131dfb3a2b I also experienced the perpetual password prompting even with nightly build of 1.1.0.201106060423. My workaround was to remove the passphrase from the key. After that, I got "channel is not opened" and even "Auth failed" issue couple of times but now it's working (don't know why). It all seems pretty random and mysterious - maybe due to jsch library(?)
The new Eclipse indigo patform still ships with Jsch 0.1.41. There is an update request for upgrading jsch here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=344469
(In reply to comment #14) I'm still not sure how the JSch version that "comes with egit" is supposed to be installed for the end user? - In the indigo packages which include egit (eg eclipse-cpp-indigo-win32), I still get 0.1.41 from the Platform. What about the other idea of providing a UI toggle to switch between "internal" and "external" SSH?
As a workaround you could try installing jsch 1.44 eclipse/eclipse \ -noSplash \ -application org.eclipse.equinox.p2.director \ -repository http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository \ -i com.jcraft.jsch/0.1.44.v201101211721,\ com.jcraft.jsch.source/0.1.44.v201101211721 My brief test on 3.7 indicates that jgit will wire up to 0.1.44 if it is available. osgi> bundle 206 org.eclipse.jgit_1.1.0.201106251700 [206] Id=206, Status=ACTIVE Data Root=/opt/local/eclipse/jschTest/eclipse/configuration/org.eclipse.osgi/bundles/206/data ... Imported packages com.jcraft.jsch; version="0.1.44"<com.jcraft.jsch_0.1.44.v201101211721 [195]> com.jcraft.jsch.jce; version="0.1.44"<com.jcraft.jsch_0.1.44.v201101211721 [195]> com.jcraft.jsch.jcraft; version="0.1.44"<com.jcraft.jsch_0.1.44.v201101211721 [195]> com.jcraft.jsch.jgss; version="0.1.44"<com.jcraft.jsch_0.1.44.v201101211721 [195]> No fragment bundles Named class space org.eclipse.jgit; bundle-version="1.1.0.201106251700"[provided] Required bundles com.jcraft.jsch; bundle-version="0.1.44.v201101211721"<com.jcraft.jsch_0.1.44.v201101211721 [195]> PW
Just to make people aware, it looks like with Apache SSHD (and Mina as underlying library) an SSH alternative is now coming to Orbit: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5091 http://mina.apache.org/sshd/
(In reply to comment #24) > As a workaround you could try installing jsch 1.44 > > eclipse/eclipse \ > -noSplash \ > -application org.eclipse.equinox.p2.director \ > -repository > http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository > \ > -i com.jcraft.jsch/0.1.44.v201101211721,\ > com.jcraft.jsch.source/0.1.44.v201101211721 I am currently behind an authenticating proxy, which requires a password. This password is saved in Eclipse configuration, which itself needs a master password at login. the command line above allows to enter neither the proxy password nor the Eclipse master password. Is there a way to specify them on the command line or trigger a dialog window so Eclipse could pass through the proxy and download the jar ? Another way would be to use the traditional UI, is there a way to have the orbit repository as a traditional update-site ?
(In reply to comment #26) > I am currently behind an authenticating proxy, which requires a password. This > password is saved in Eclipse configuration, which itself needs a master > password at login. the command line above allows to enter neither the proxy > password nor the Eclipse master password. Is there a way to specify them on the > command line or trigger a dialog window so Eclipse could pass through the proxy > and download the jar ? Another way would be to use the traditional UI, is there > a way to have the orbit repository as a traditional update-site ? Yes, just add http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository as an update site. The Orbit repo has categories the expose the bundles directly. PW
(In reply to comment #27) > Yes, just add > http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository > as an update site. The Orbit repo has categories the expose the bundles > directly. I tried that. The JSCH 0.1.44 jar is in the "All Orbit Bundles" list. However, when I select it, it is stuck at the very beginning of the "Calculating requirements and dependencies" step. It's not a simple network timeout (I let it run a few hours as I went to a meeting) and it's probably not a proxy setting failue (when I came back, I tried to install something else to check and it went smoothly).
Was having the same issue with the passphrase. I followed Pauls comment (#24) and the next time I launched eclipse I was prompted for my passphrase and this time everything worked. Thanks Paul for the info, Earle
Change [1] modified how we ask for and store user/password and passphrase credentials. At least I can now push via ssh to github repos. Per eclipse session I am asked once for the passphrase. I think it would make sense to retest this. [1] http://egit.eclipse.org/r/#change,3796
Created attachment 200437 [details] Difference of behaviour in eclipse vs runtime workbench I am still able to replicate this after the workaround, but with some very strange behaviour. I used the installation of the updated jsch via the command line as suggested above. After that, loading eclipse directly and trying to push to git works fine. The proper dialog comes up and it accepts my passphrase. However, using the exact same updated installation, if I instead create a workspace with some plugins, and then run the eclipse runtime workbench, pushing does *not* work, and in fact the dialog box prompting me for a password looks different. This seems very very strange to me, obviously ;)
This might be worth adding, and I feel quite stupid for not having mentioned it ;) The workspace I have with 'some plugins' is actually the egit source code ;) So perhaps that's what's causing the change in behaviour. Ha Ha Ha. Ha. Ha. However it doesn't change the fact that even with the proper jsch installed, I am still unable to push using the current source code. The following are the commands I used to get the source code: git clone http://egit.eclipse.org/jgit.git jgit git clone http://egit.eclipse.org/egit.git egit git clone http://egit.eclipse.org/egit-pde.git egit-pde git clone http://egit.eclipse.org/egit-github.git egit-github As per the contributor guide: http://wiki.eclipse.org/EGit/Contributor_Guide#Obtaining_Sources So... I guess I can say the "workaround" works fine for Indigo, but not using the current source code... ? Heh.
(In reply to comment #23) > (In reply to comment #14) > > I'm still not sure how the JSch version that "comes with egit" is supposed to > be installed for the end user? - In the indigo packages which include egit (eg > eclipse-cpp-indigo-win32), I still get 0.1.41 from the Platform. egit doesn't ship jsch but instead uses the version available in the underlying platform
(In reply to comment #33) > (In reply to comment #23) > > (In reply to comment #14) > > > > I'm still not sure how the JSch version that "comes with egit" is supposed to > > be installed for the end user? - In the indigo packages which include egit (eg > > eclipse-cpp-indigo-win32), I still get 0.1.41 from the Platform. > > egit doesn't ship jsch but instead uses the version available in the underlying > platform The problem Rob Stryker has occurrs if you setup the contributor workspace and follow the EGit contributor guide. You'll then setup the 3rd party dependencies to your workspace (either manually or by using the team project set). You end up having com.jcraft.jsch in v0.1.41 in your workspace. This bundle obviously takes precedence over com.jcraft.jsch 0.1.44 that you have in your platform if you include both in the launch configuration (ex. by enabling all workspace and platfrom bundles). You end up having a Test IDE (the one you use to run the egit source code) which only includes jsch 0.1.41. The solution is pretty simple: you'd have to exclude the workspace com.jcraft.jsch 0.1.41 from your launch config or simply close the project in your workspace.
I'll fix the contributor guide and update the psf file to the required jsch plugin version.
Confirming the GIT_SSH workaround, I set it to /usr/bin/ssh, however for any one facing a hanging dialog waiting for the GUI password dialog to appear in EGit, it won't appear, instead the terminal which you have executed Eclipse from (ssh executable it self) will be waiting you to enter the password there so Eclipse can continue cloning.
(In reply to comment #33) > (In reply to comment #23) > > (In reply to comment #14) > > > > I'm still not sure how the JSch version that "comes with egit" is supposed to > > be installed for the end user? - In the indigo packages which include egit (eg > > eclipse-cpp-indigo-win32), I still get 0.1.41 from the Platform. > > egit doesn't ship jsch but instead uses the version available in the underlying > platform Hello, friends! I want to share my late evening hungry hacking solution experience for this issue, just until everything goes smooth. So here it is: 1. Download the latest version of JSch jar (currently 0.1.45) from the creator's site: http://sourceforge.net/projects/jsch/files/jsch.jar/0.1.45/jsch-0.1.45.jar/download 2. Rename it so it has the same name as the JSch plugin jar from your Eclipse Indigo. 3. Add the eclipse specific files to the newly renamed jar, by copying the originals from the one in Indigo. 4. Replace the jar in Indigo with this one. Now, authentication goes well to git, passphrase is successfully accepted. Wish you all the best and my thanks to you all for a great job:)
This was fixed with d087744b091b88083710563510a1dbe6cebb3f9d which replaced the dialog coming with JSch by a dialog implemented in EGit. I just retested this using current nightly build and JSch v0_1_41 and the passphrase dialog comes up and when providing the passphrase SSH authentication works as expected. Also the passphrase can be stored in the secure store.
I just tried with the latest nightly, and it still does not work. I have still have to use the GIT_SSH workaround.
(In reply to comment #27) > (In reply to comment #26) > > I am currently behind an authenticating proxy, which requires a password. This > > password is saved in Eclipse configuration, which itself needs a master > > password at login. the command line above allows to enter neither the proxy > > password nor the Eclipse master password. Is there a way to specify them on the > > command line or trigger a dialog window so Eclipse could pass through the proxy > > and download the jar ? Another way would be to use the traditional UI, is there > > a way to have the orbit repository as a traditional update-site ? > > Yes, just add > http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/repository > as an update site. The Orbit repo has categories the expose the bundles > directly. > > PW This repo seems to only hold jsch 0.1.44 (JSch 0.1.44.v201101211721 to be precise), however I had to use JSCH 0.1.45 in order to get my id_rsa encrypted with the AES-128-CBC cipher properly unlocked. Thoughts?
(In reply to comment #40) > > This repo seems to only hold jsch 0.1.44 (JSch 0.1.44.v201101211721 to be > precise), however I had to use JSCH 0.1.45 in order to get my id_rsa encrypted > with the AES-128-CBC cipher properly unlocked. We currently only have 2 versions of JSCH in orbit, 0.1.41 and 0.1.44 http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/ New versions are only picked up on a requirement by a consuming eclipse foundation project (as they need IP approval to get it into Orbit). To use 0.1.45 you would have to produce an OSGi bundle of 0.1.45 yourself, create a p2 site, and install it (assuming that allows you to use it). PW
(In reply to comment #41) > (In reply to comment #40) > > > > This repo seems to only hold jsch 0.1.44 (JSch 0.1.44.v201101211721 to be > > precise), however I had to use JSCH 0.1.45 in order to get my id_rsa encrypted > > with the AES-128-CBC cipher properly unlocked. > > We currently only have 2 versions of JSCH in orbit, 0.1.41 and 0.1.44 > > http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/ > > New versions are only picked up on a requirement by a consuming eclipse > foundation project (as they need IP approval to get it into Orbit). > > To use 0.1.45 you would have to produce an OSGi bundle of 0.1.45 yourself, > create a p2 site, and install it (assuming that allows you to use it). > > PW OK, thanks. I guess my point was that 0.1.44 failed to encrypt my existing id_rsa and thought other people might bump into this as well. Since Eclipse 4.2 M2 only comes with 0.1.44 I'm not sure how much value it is to ship with that version. Anyhow, thanks for the heads-up.
FWIW the TM project will need JSch-0.1.45 to get bug 359184 fixed. But I'm not a fan of multiple products shipping JSch themselves ... this hasn't worked well in the past. Could the Platform team do the IPZilla and ship it with Platform ?
bug 360663 Will EGit happily consume 0.1.45? PW
Let me note that I succeeded to fix the issue the brute-force-way on Helios with JSCH 0.1.44 downloaded from http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/ What I did is: 1) Replace com.jcraft.jsch_0.1.41.v200903070017.jar by the downloaded com.jcraft.jsch_0.1.44.v201101211721.jar in the Eclipse plugin folder 2) Replace all references to the 0.1.41 version by the appropriate 0.1.44 in the Eclipse configuration: (as follows) $ grep -Rl 0.1.41.v200903070017 * | xargs -I FILE sed -i 's/0\.1\.41\.v200903070017/0.1.44.v201101211721/g' FILE
Comment 24 FTW! I'm using Eclipse 3.7 (standard at work) and needed to access a github account.
(In reply to comment #46) > Let me note that I succeeded to fix the issue the brute-force-way on Helios > with JSCH 0.1.44 downloaded from > http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/ > > What I did is: > 1) Replace com.jcraft.jsch_0.1.41.v200903070017.jar by the downloaded > com.jcraft.jsch_0.1.44.v201101211721.jar in the Eclipse plugin folder > 2) Replace all references to the 0.1.41 version by the appropriate 0.1.44 > in the Eclipse configuration: (as follows) > $ grep -Rl 0.1.41.v200903070017 * | xargs -I FILE sed -i > 's/0\.1\.41\.v200903070017/0.1.44.v201101211721/g' FILE JGit 2.2.0.201212191850-r and hence EGit 2.2.0.201212191850-r include JSch 0.1.46
Another, much simpler workaround is to remove the (AES) passphrase using OpenSSH and then ask the (old) JSch to set the same passphrase again - using DES3. Even though OpenSSH's is now using AES by default it supports DES3 fine. Using DES3 the same passphrase can be shared across all agents. No GIT_SSH variable required. Tested. Sorry if this workaround sounds obvious: I'm afraid it got lost in the number of comments. - To remove the AES passphrase: ssh-keygen -p -f .ssh/id_rsa - To set the same passphrase again use the "Key Management" tab in Eclipse preferences.
I had this problem with Eclipse Luna 4.4.2 and EGit 3.4.2.201412180340-r. I connect now to git through ssh with ssh-keys and the EGit using config file in ~/.ssh as is writing here http://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use. In ~/.ssh/config, add: host <ip> IdentityFile ~/.ssh/id_rsa User <username>
