Community
Participate
Working Groups
Eclipse 2021-03 with EGit 5.11 doesn't seem to work with BitBucket via git protocol. Eclipse 2020-12 worked fine. SSH settings were the same (default private keys id_dsa,id_rsa in the user's home directory). Any attempt to execute git operations involving the remote bitbucket host (e.g. fetch) fail. Eclipse 2021-03 with EGit 5.11 doesn't seem to work with BitBucket via git (SSH?) protocol. Eclipse 2020-12 worked fine. SSH settings were the same (default private keys id_dsa,id_rsa in the user's home directory). Any attempt to execute git operations involving the remote bitbucket host (e.g. fetch) fail. The logs contain (project/repo hid for privacy): !MESSAGE git@bitbucket.org:<project>/<repo>.git: Cannot log in at bitbucket.org:22 !STACK 0 org.eclipse.jgit.api.errors.TransportException: git@bitbucket.org:<project>/<repo>.git: Cannot log in at bitbucket.org:22 at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:224) at org.eclipse.egit.core.op.FetchOperation.run(FetchOperation.java:134) at org.eclipse.egit.ui.internal.fetch.FetchOperationUI.execute(FetchOperationUI.java:111) at org.eclipse.egit.ui.internal.fetch.FetchOperationUI$1.performJob(FetchOperationUI.java:137) at org.eclipse.egit.ui.internal.jobs.RepositoryJob.run(RepositoryJob.java:59) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Caused by: org.eclipse.jgit.errors.TransportException: git@bitbucket.org:<project>/<repo>.git: Cannot log in at bitbucket.org:22 at org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:174) at org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99) at org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235) at org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:1) at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:107) at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:281) at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:153) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:142) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:94) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1309) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:213) ... 5 more Caused by: org.apache.sshd.common.SshException: No more authentication methods available at org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:126) at org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) at org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) at org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:68) at org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:164) ... 15 more Caused by: org.apache.sshd.common.SshException: No more authentication methods available at org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:342) at org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:277) at org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:224) at org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:502) at org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:428) at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1463) at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:388) at org.eclipse.jgit.internal.transport.sshd.JGitClientSession.messageReceived(JGitClientSession.java:197) at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64) at org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:358) at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:335) at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:332) at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37) at java.base/sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:127) at java.base/sun.nio.ch.Invoker$2.run(Invoker.java:219) at java.base/sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at java.base/java.lang.Thread.run(Thread.java:832)
Perhaps a problem with the new sshd 2.6.0 library? :-( (Unclear why we only ever get reports about ssh problems with bitbucket. bitbucket must be doing something different from all others.) Can you try to run this with debug logging enabled? See [1] for some hints how to get debug logging from that SSH library. (Unfortunately it's not quite straight-forward...) Then attach the logging output here. [1] https://www.eclipse.org/forums/index.php?t=msg&th=1105101&goto=1832952&#msg_1832952
Created attachment 285869 [details] BitBucket SSH Debug log Added BitBucket SSH Debug log (for the 'Fetch' operation that fails)
Thanks, that's helpful. 13:22:46.597 [sshd-JGitSshClient[337a1f2d]-nio2-thread-10] DEBUG o.a.s.c.auth.pubkey.UserAuthPublicKey - sendAuthDataRequest(JGitClientSession[git@bitbucket.org/104.192.141.1:22])[ssh-connection] send SSH_MSG_USERAUTH_REQUEST request publickey type=rsa-sha2-512 - fingerprint=SHA256:OvXAnjD/uTZ9vpdSsB9chTgIgnxUZkn4coCIngHay7k 13:22:46.598 [sshd-JGitSshClient[337a1f2d]-nio2-thread-10] DEBUG o.apache.sshd.common.io.nio2.Nio2Session - writeBuffer(Nio2Session[local=/[0:0:0:0:0:0:0:0]:55271, remote=bitbucket.org/104.192.141.1:22]) writing 404 bytes 13:22:46.598 [sshd-JGitSshClient[337a1f2d]-nio2-thread-10] DEBUG o.a.s.c.session.ClientUserAuthService - tryNext(JGitClientSession[git@bitbucket.org/104.192.141.1:22]) successfully processed initial buffer by method=publickey 13:22:46.732 [sshd-JGitSshClient[337a1f2d]-nio2-thread-12] DEBUG o.a.s.c.session.ClientUserAuthService - processUserAuth(JGitClientSession[git@bitbucket.org/104.192.141.1:22]) Received SSH_MSG_USERAUTH_FAILURE - partial=false, methods=publickey EGit sends a userauth of type rsa-sha2-512 using the key with fingerprint SHA256:OvXAnjD/uTZ9vpdSsB9chTgIgnxUZkn4coCIngHay7k and receives a failure reply from the server. So... is that the right key? Check with ssh-keygen -lf <keyfilename>, for instance ssh-keygen -lf ~/.ssh/id_rsa, if your key is id_rsa. (This bug says it's been reported for Windows 10; I don't know how you'd do that with putty. But the git bash shell should have ssh and probably also ssh-keygen.) If it's the right key, then maybe something is wrong with the rsa-sha2-512 implementation in sshd 2.6.0? Or the bitbucket SSH server can't deal with it? Perhaps it's SSHD-1118?[1] In that case, I can only suggest using another key type, for instance ed25519. [1] https://issues.apache.org/jira/browse/SSHD-1118
Also see the bitbucket issue tracker at [1]. Could you please also try the ssh (in git bash, if on Windows)? ssh -vvv git@git.bitbucket.org That would show what stock openssh would try. Also see [2]. [1] https://jira.atlassian.com/browse/BSERV-10175 [2] https://community.atlassian.com/t5/Git-questions/Git-2-28-cannot-connect/qaq-p/1515301
(In reply to Thomas Wolf from comment #4) > ssh -vvv git@git.bitbucket.org ssh -vvv git@bitbucket.org
Created attachment 285870 [details] ssh -vvv git@bitbucket.org Added results of ssh -vvv to bitbucket
$ ssh-keygen -lf id_rsa 2048 SHA256:<protected for privacy> Leonid@LROZENBLYUM (RSA)
Thomas, thanks! As a workaround I've created a pair of keys with the algorithm: ed25519, and it works fine with BitBucket!
(In reply to leokom leokom from comment #6) > Created attachment 285870 [details] > ssh -vvv git@bitbucket.org > > Added results of ssh -vvv to bitbucket Very helpful. Openssh does: debug3: sign_and_send_pubkey: RSA SHA256:OvXAnjD/uTZ9vpdSsB9chTgIgnxUZkn4coCIngHay7k debug3: sign_and_send_pubkey: signing using ssh-rsa debug3: send packet: type 50 debug3: receive packet: type 52 debug1: Authentication succeeded (publickey). It uses ssh-rsa, not rsa-sha2-512. So the upshot is: connecting to bitbucket with a client that uses ssh-rsa works, but rsa-sha2-512 does not. Pfff. Not sure we can do a lot about this. Maybe change the default order; currently rsa-sha2-512 is preferred over ssh-rsa in the client.
(In reply to leokom leokom from comment #8) > Thomas, thanks! > As a workaround I've created a pair of keys with the algorithm: ed25519, and > it works fine with BitBucket! Good. As I wrote above; I don't think I can do a lot about rsa-sha2-512 not working with bitbucket except trying to change some default order such that by default ssh-rsa would be preferred. So the work-around for EGit 5.11 is to use an ed25519 key.
Same here with an RSA key and bitbucket. But the same key works with github. Anything we can help?
(In reply to Christian Strebel from comment #11) > Same here with an RSA key and bitbucket. But the same key works with github. > Anything we can help? No. Bitbucket has a problem with the rsa-sha2-512 pubkey signature used. Current work-around is to use an ed25519 key. If you use a ~/.ssh/config file to configure your connections, you could try adding a PubkeyAcceptedAlgorithms setting that enumerates ssh-rsa *before* rsa-sha2-512. See [1]. But honestly said, I'm not sure the current implementation with the Apache MINA sshd library will even pick it up. [1] https://man.openbsd.org/ssh_config
The problem is that the bitbucket server only knows public key signature algorithm "ssh-rsa" for RSA keys. Now the Apache MINA library has the available algorithms defined as (amongst others) "rsa-sha2-512,rsa-sha2-256,ssh-rsa" It _can_ do all three. However, due to bug SSHD-1105[1], it only and unconditionally uses the first. Hence once cannot connect to bitbucket with an RSA key anymore. :-( ssh-rsa is deprecated (it uses the cryptographically unsafe SHA1), but apparently still widely used. Github, OTOH, can do rsa-sha2-512 (and even announces so in the SSH protocol messages), so there it works fine. What can we do on the JGit side? - we could change that order to "ssh-rsa,rsa-sha2-512,rsa-sha2-256". This effectively will switch off the sha2 variants because of SSHD-1105. This is probably not good, given that Fedora 33 has already disabled ssh-rsa on the server side. - we could implement support for ssh config PubkeyAcceptedAlgorithms. This would enable users to re-order the algorithms. For instance, an entry like the following in ~/.ssh/config Host bitbucket.org Hostname bitbucket.org User git IdentityFile ~/.ssh/id_rsa.bitbucket IdentitiesOnly yes PubkeyAcceptedAlgorithms ^ssh-rsa would put "ssh-rsa" at the front of the list *for connections to bitbucket.org only*. [1] https://issues.apache.org/jira/browse/SSHD-1105
I want to report that this issue does not only affect BitBucket. I encountered the same problem connecting to my self-hosted OneDev instance. The workaround of creating an ed25519 key also works for OneDev. It appears that OneDev and BitBucket are both using Apache MINA SSHD: https://github.com/theonedev/onedev/blob/main/server-core/src/main/java/io/onedev/server/ssh/SshServerLauncher.java https://confluence.atlassian.com/bitbucketserver/enable-ssh-access-to-git-repositories-776640358.html
Same problem for AWS Code Commit repositories. The work-around using an ed25519 key does *not* work for AWS Code Commit as AWS only support RSA keys. Adding "PubkeyAcceptedAlgorithms ^ssh-rsa" to .ssh/config does not seem to be picked up by Apache MINA, command line ssh complains when this line is present in the .ssh/config file: user@host:~/.ssh$ ssh -vvv APK(snip)IIL@git-codecommit.eu-central-1.amazonaws.com OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /home/user/.ssh/config debug1: /home/user/.ssh/config line 1: Applying options for git-codecommit.*.amazonaws.com /home/user/.ssh/config: line 4: Bad configuration option: pubkeyacceptedalgorithms /home/user/.ssh/config: terminating, 1 bad configuration options user@host:~/.ssh$ cat config Host git-codecommit.*.amazonaws.com User APK(snip)IIL IdentityFile ~/.ssh/id_rsa PubkeyAcceptedAlgorithms ^ssh-rsa When trying to connect to AWS Code Commit using rsa-sha2-512: $ ssh -vvv -oHostKeyAlgorithms=rsa-sha2-512 APK(snip)IIL@git-codecommit.eu-central-1.amazonaws.com (...) Unable to negotiate with 52.94.205.33 port 22: no matching host key type found. Their offer: ssh-rsa git from command line works fine. So, effectively EGit as of version 5.11 is not usable with AWS Code Commit repositories any longer. I will have to find a way of downgrading EGit back to version 5.10 :-(
It's just very unfortunate that the selection of ssh client, either JSch or Apache MINA, was still available in 5.10 and dropped in 5.11. Using JSch could have been a simple work-around for this issue with several git repository providers that is caused by Apache MINA.
Try PubKeyAcceptedKeyTypes ^ssh-rsa instead of PubkeyAcceptedAlgorithms ^ssh-rsa The latter appears to be very recent. See [1]. And yes, it'll work only on the command-line. We would have to implement support for this first in the binding from JGit to Apache MINA sshd.
(In reply to Jochen Seifarth from comment #16) > It's just very unfortunate that the selection of ssh client, either JSch or > Apache MINA, was still available in 5.10 and dropped in 5.11. Using JSch > could have been a simple work-around for this issue with several git > repository providers that is caused by Apache MINA. At some point that old JSch just could no longer be supported. That point has come. Another work-around might be to set environment variable GIT_SSH (set to the command-line ssh executable) when Eclipse is run. EGit should then use the command-line ssh, not any Java library.
(In reply to Thomas Wolf from comment #17) > Try > > PubKeyAcceptedKeyTypes ^ssh-rsa > > instead of > > PubkeyAcceptedAlgorithms ^ssh-rsa > > The latter appears to be very recent. See [1]. Here's the link I forgot: [1] https://github.com/openssh/openssh-portable/commits/master/readconf.c openssh has renamed some ssh config keys...
New Gerrit change created: https://git.eclipse.org/r/c/jgit/jgit/+/178041
New Gerrit change created: https://git.eclipse.org/r/c/jgit/jgit/+/178043
(In reply to Thomas Wolf from comment #17) > Try > > PubKeyAcceptedKeyTypes ^ssh-rsa > > instead of > > PubkeyAcceptedAlgorithms ^ssh-rsa > > The latter appears to be very recent. ^ is handled since openssh 8.1 only; see https://github.com/openssh/openssh-portable/commit/91a2135f3 (2019-09-08). For earlier openssh versions, you'd have to redefine the whole list, or try without the ^ if ssh-rsa is all that's needed.
Using a .ssh/config file with egit does not solve the problem. Seams that it gets parsed, but not correctly interpreted. I am not sure if this is a Apache MINA sshd or a egit/jgit problem. Because jgit does override many things like: - JGitSshClient instead of SshClient - JGitSshConfig instead of DefaultConfigFileHostEntryResolver
(In reply to Christian Strebel from comment #23) > Using a .ssh/config file with egit does not solve the problem. > Seams that it gets parsed, but not correctly interpreted. Yes, we do. Yes, we need to implement support for PubkeyAcceptedAlgorithms first.
Ok great. Due to bug SSHD-1105[1] of Apache MINA sshd library not all available algorithms are tried. (So only rsa-sha2-512 instead of the whole list). But there is another bug that the .ssh/config is not respected. Does plain Apache MINA sshd also not interpret the PubkeyAcceptedAlgorithms config? Because it sounds strange for me this needs to be implemented on the JGit side.
(In reply to Christian Strebel from comment #25) > Ok great. > > Due to bug SSHD-1105[1] of Apache MINA sshd library not all available > algorithms are tried. (So only rsa-sha2-512 instead of the whole list). > > But there is another bug that the .ssh/config is not respected. > Does plain Apache MINA sshd also not interpret the PubkeyAcceptedAlgorithms > config? It does not. JGit uses its own config file parser anyway. ~/.ssh/config is read and used by EGit/JGit. Just PubkeyAcceptedAlgorithms is not yet implemented.
> It does not. JGit uses its own config file parser anyway. > > ~/.ssh/config is read and used by EGit/JGit. Just PubkeyAcceptedAlgorithms > is not yet implemented. Thanks for clarification and your work :). What to you think is there any chance to workaround this problem by setting the right system property or something like this?
(In reply to Christian Strebel from comment #27) > > It does not. JGit uses its own config file parser anyway. > > > > ~/.ssh/config is read and used by EGit/JGit. Just PubkeyAcceptedAlgorithms > > is not yet implemented. > > Thanks for clarification and your work :). > > What to you think is there any chance to workaround this problem by setting > the right system property or something like this? Known work-arounds are documented at [1]. I'm not aware of any other possibilities currently. Otherwise wait for the code fixes in JGit to work around this problem in Apache MINA sshd 2.6.0 and then install EGit nightly. (I've already pushed changes to Gerrit; they're linked top right in this issue.) [1] https://wiki.eclipse.org/EGit/New_and_Noteworthy/5.11#Known_problems
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/178043 was merged to [stable-5.11]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=fd3edc7bfc65f9bdfe785c92c72790261881dd40
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/178041 was merged to [stable-5.11]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=ffc1f9b02618a59ee72298e9af15f64fe157fa8a
*** Bug 572186 has been marked as a duplicate of this bug. ***
*** Bug 572194 has been marked as a duplicate of this bug. ***
*** Bug 572318 has been marked as a duplicate of this bug. ***
(In reply to Thomas Wolf from comment #18) (...) > Another work-around might be to set environment variable GIT_SSH (set to the > command-line ssh executable) when Eclipse is run. EGit should then use the > command-line ssh, not any Java library. Many thanks, that work-around using GIT_SSH works nicely for me. In my search for a work-around I had switched switched from ssh (ssh://git-codecommit.eu-central-1.amazonaws.com/...) to https using git remote set-url origin https://git-codecommit.eu-central-1.amazonaws.com/... You need a user ID and password with https, ssh key don't work with the above work-around.
New Gerrit change created: https://git.eclipse.org/r/c/jgit/jgit/+/178741
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/178741 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=8edde18c8c3240dadd7f3411d2065d8df28cdc5c
I'm closing this as fixed in EGit nightly (5.12). Unfortunately our publishing a 5.11.1 fix release is delayed. EGit nightly already contains that fix. A description of the work-around is available at [1]. If the problem re-occurs with EGit 5.12 and re-ordering signature algorithms via the ssh config file as described at [1] doesn't help, feel free to re-open this. [1] https://wiki.eclipse.org/EGit/New_and_Noteworthy/5.11#Known_problems
*** Bug 573091 has been marked as a duplicate of this bug. ***
*** Bug 573500 has been marked as a duplicate of this bug. ***
