ssh:// remote paths not supported.

[Zambito1]

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

• Platform: GNU Guix
• Version: jj 0.13.0-5450e6c9bae40b941b05942bdd78a88e1b9093a6

[martinvonz]

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]

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]

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]

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]

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:

jj/lib/src/git.rs

Lines 1402 to 1407 in 99f0e7f

	tracing::info!(username, "trying ssh_key_from_agent");
	tried_ssh_agent = true;
	return git2::Cred::ssh_key_from_agent(username).map_err(|err| {
	tracing::error!(err = %err);
	err
	});

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

[Zambito1]

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]

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]

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.