martinvonz / jj

A Git-compatible VCS that is both simple and powerful
https://martinvonz.github.io/jj/
Apache License 2.0
9.2k stars 319 forks source link

`ssh://` remote paths not supported. #2931

Open Zambito1 opened 9 months ago

Zambito1 commented 9 months ago

Description

I am trying to use jj git commands that deal with remotes, such as jj git clone and jj git fetch. After digging into some other issues (#1970, #440), I noticed that it seems like the only expected way that this is supported with ed25519 keys is by using ssh-agent for authentication. I set up ssh-agent and added my identity, but it still does not work.

Steps to Reproduce the Problem

  1. ssh-keygen -t ed25519
  2. ssh-copy-id <git server>
  3. eval "$(ssh-agent -s)"
  4. ssh-add
  5. jj git clone <repo on remote>

Expected Behavior

The repository should be cloned.

Actual Behavior

robby@lambda ~/src$ jj git clone -v ssh://git.robbyzambito.me/srv/git/mirror/guix.git
2024-02-03T20:56:05.894948Z  INFO jj_cli::cli_util: verbose logging enabled
2024-02-03T20:56:05.898074Z  INFO run_command:build_index_segments_at_operation{operation=Operation { id: OperationId("2e26ab22c9747860773f1af7981c7c7f5f65f0134e678bc26a1936a0161f8147d44415f002cc8006cec0b26679457dad1c404706ac33d11404817e1ef96a88b4") }}: jj_lib::default_index::store: indexing commits reachable from historical heads maybe_parent_file=None heads_count=1
2024-02-03T20:56:05.898164Z  INFO run_command:build_index_segments_at_operation{operation=Operation { id: OperationId("2e26ab22c9747860773f1af7981c7c7f5f65f0134e678bc26a1936a0161f8147d44415f002cc8006cec0b26679457dad1c404706ac33d11404817e1ef96a88b4") }}: jj_lib::default_index::store: saved new index file index_file=ReadonlyIndexSegment { name: "e40a190e9011a7c71a08afdfb7809ccc5812ebb438e0778a37fa51f155c445d68785e8d61fdfe1ed18c00a095430d28d3ec7673eb855aa92f0531327c161039e", parent_file: None } commits_count=1
Fetching into new repo in "/home/robby/src/guix"
2024-02-03T20:56:05.918800Z DEBUG run_command:fetch{remote_name="origin" branch_names=[Substring("")] git_settings=GitSettings { auto_local_branch: false, abandon_unreachable_commits: true }}: jj_lib::git: remote.download
2024-02-03T20:56:06.022789Z  INFO run_command:fetch{remote_name="origin" branch_names=[Substring("")] git_settings=GitSettings { auto_local_branch: false, abandon_unreachable_commits: true }}: jj_lib::git: using default
Error: authentication required but no callback set; class=Ssh (23); code=Auth (-16)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work?
robby@lambda ~/src$ ssh-add -l
256 SHA256:og0JCExBAAZWLBw9qj1fPEd1Pic2bHzoyxdse8fJE8I robby@lambda (ED25519)
robby@lambda ~/src$ ssh -F /dev/null git.robbyzambito.me
robby@robbyzambito.me ~$ 

Specifications

martinvonz commented 9 months ago

It looks like libssh2 got support for ed25519 keys on 6 months ago, in version 1.11 (https://github.com/libssh2/libssh2/releases). I actually don't know which version we build with. Maybe it also varies across platforms. Happy to accept a PR if you can figure it out.

martinvonz commented 9 months ago

Oh, libgit2 also has support for OpenSSH since quite recently, so switching to that is another option. That would solve various other SSH issues we've had.

necauqua commented 9 months ago

ed25519 keys worked for me for a long while, I don't think the issue you're facing has to do with them specifically. Does it work fine with RSA keys for you since you got to that conclusion?

Zambito1 commented 9 months ago

Oops, I should have done more testing. No, RSA keys also do not seem to work. I'm not sure what else I should try to diagnose this.

martinvonz commented 9 months ago

It looks like the jj git clone command above doesn't even try to connect to the ssh-agent. If it did, you should have seen the log message from here: https://github.com/martinvonz/jj/blob/99f0e7f8440eacafad9bd4ba5a30dc78ad209ad6/lib/src/git.rs#L1402-L1407

You could try adding more log messages in the code around there to see how far it gets.

Zambito1 commented 9 months ago

I was able to poke with it more, and I noticed the issue is that I was using a ssh://host/path URL instead of user@host:path for my remote. Switching to the latter format worked.

fschoenm commented 6 months ago

I was able to poke with it more, and I noticed the issue is that I was using a ssh://host/path URL instead of user@host:path for my remote. Switching to the latter format worked.

This doesn't seem to work if not using the default SSH port. The user@host:path syntax doesn't support specifying a port.

maltejur commented 3 months ago

Interestingly enough I get Error: authentication required but no callback set; class=Ssh (23); code=Auth (-16) when using user@host:path, but ssh://user@host/path works fine for me.