jj: Cannot run `jj git push`: using ssh_key_from_agent loop
Description
Steps to Reproduce the Problem
jj git push
Not sure how I can provide a repro example. Just started using jj yesterday on an existing git repo.
Expected Behavior
It pushes
Actual Behavior
jj git push -v
2023-08-03T20:04:20.124904Z INFO jj_cli::cli_util: verbose logging enabled
Branch changes to push to origin:
Move branch assertion-api from eba925600601 to 2e9b7b55bbeb
2023-08-03T20:04:20.420168Z INFO run_command: jj_lib::git: using ssh_key_from_agent username="git"
2023-08-03T20:04:20.443888Z INFO run_command: jj_lib::git: using ssh_key_from_agent username="git"
2023-08-03T20:04:20.467704Z INFO run_command: jj_lib::git: using ssh_key_from_agent username="git"
...
The log statement INFO run_command: jj_lib::git: using ssh_key_from_agent username="git" is sent repeatedly in an apparent infinite loop.
Specifications
- Platform: linux amd64
- Version:
jj 0.8.0-6ee8feea861c95f8246aee9e720ed5db66161006
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 34 (15 by maintainers)
Commits related to this issue
- git: only try to use ssh-agent once per connection As reported in #1970, SSH authentication would sometimes run into a loop where it repeatedly tries to use ssh-agent for authentication without makin... — committed to martinvonz/jj by martinvonz a year ago
- git: only try to use ssh-agent once per connection As reported in #1970, SSH authentication would sometimes run into a loop where it repeatedly tries to use ssh-agent for authentication without makin... — committed to martinvonz/jj by martinvonz a year ago
- devel/jj: update to 0.10.0 [0.10.0] - 2023-10-04 ### Breaking changes * A default revset-alias function `trunk()` now exists. If you previously defined your own `trunk()` alias it will continue t... — committed to NetBSD/pkgsrc by deleted user 9 months ago
Ah, right that’s another limitation I had almost forgotten (#440). I’ll see what I can do about that too. Closing this now since the hang has been fixed and we do try to use password-less id_rsa keys afterwards now.
SGTM. As far as I can tell,
Remote::download()norRemote::push()doesn’t set up SSH connection more than once, so we can assume the previous credential attempt would be failed.No, it was just a workaround. The bug is that we repeatedly try the ssh-agent even if it’s not there, so we never end up trying the password-less key.
You’ll need to run
ssh-addand thenssh-add -l(notssh-agent -l, but maybe that was also just a typo 😃) should include your keys. Oncessh-add -llists your keys, I would expectjj git fetchto work.I’ll work on a fix for the bug.
Ah, so maybe what happens is that jj finds $SSH_AUTH_SOCK and uses only ssh-agent credential, while git first tries ssh-agent and then falls back to check if any password-less keys are available (or maybe it does it in the opposite order). We should do the same.
No it is not.
And I don’t have anything special in
~/.ssh/config.Thanks a lot for the help and the great tool. Happy to try some things in my setup (
ssh-add -dbreaks things again) if you want to investigate.Bizarre indeed. I don’t know how to troubleshoot it more, so I’m going to rely on you and @prestonvanloon to try to figure out what’s different between the old and the new repo. There is no retrying in jj’s code anyway. I don’t know how best to debug it even if i had access to your repos and environments. Maybe adding
println!()statements in jj’s code, or maybe libgit2 or libssh2 have some logging you can turn on. Or maybe even Wireshark.