jj: Cannot run `jj git push`: using ssh_key_from_agent loop

Description

Steps to Reproduce the Problem

  1. 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

Most upvoted comments

I think it should use /home/preston/.ssh/id_ed25519?

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.

Yes, that’s what I tried and that seemed to work. I’m thinking I should remove the special case for ssh-agent and have the callback go through a list of methods to attempt. Sounds good?

SGTM. As far as I can tell, Remote::download() nor Remote::push() doesn’t set up SSH connection more than once, so we can assume the previous credential attempt would be failed.

git fetch / pull / push etc works fine without the ssh-agent running with those environment variables. Is it going to be a requirement to have the agent running?

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.

I started it with

eval `ssh-agent -s`

and this shows no identities when running ssh-agent -l.

You’ll need to run ssh-add and then ssh-add -l (not ssh-agent -l, but maybe that was also just a typo 😃) should include your keys. Once ssh-add -l lists your keys, I would expect jj git fetch to work.

I’ll work on a fix for the bug.

Is your key password protected?

No it is not.

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.

Is your key password protected?

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 -d breaks 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.