SSH: Use OpenSSH instead of libssh2 for authentication with Git hosts

[bnjmnt4n]

This PR switches to OpenSSH instead of libssh2 for authentication with Git hosts. It allows configuration specified in ~/.ssh/config to be read when connecting via SSH, e.g. specifying custom keys to use for different hosts, or using a different SSH agent. In general, the OpenSSH-based connection seems slightly more robust then the libssh2 version, but I think there are still some issues which do not work well (eg., it didn't work for me when I hadn't connected to the host before, and didn't display the unknown host interaction that the ssh binary does).

I still need to look into whether this affects other workflows (eg. git credentials).

Marking this as a draft since this also depends on upstream PRs to land (rust-lang/git2-rs#1032 which bumps the version of libgit2 (update: landed), and rust-lang/git2-rs#1031 which builds libgit2 using OpenSSH for SSH execution), but I'm creating the PR for improved visibility.

Closes #63.

If you're interested in using this, the following code can be used to build this branch locally:

git clone [email protected]:bnjmnt4n/jj && cd jj
git checkout ssh-openssh
cargo install --path cli --locked --bin jj

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[bnjmnt4n]

Oddly enough, building this as a Nix derivation no longer works correctly with my IdentityAgent SSH config...

[khionu]

Could you include a list of reasons for this switch in the PR description? Would be good for historical purposes, especially for elsewhere in Rust where people may try to make the case for switching.

[khionu]

Could you link said blocking PRs?

[bnjmnt4n]

@khionu updated!

[joyously]

I'm wondering if other SSH implementations are susceptible also.
https://www.wired.com/story/xz-backdoor-everything-you-need-to-know/

Malicious code added to xz Utils versions 5.6.0 and 5.6.1 modified the way the software functions. The backdoor manipulated sshd, the executable file used to make remote SSH connections. Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device.

Wait, How Can a Compression Utility Manipulate a Process as Security-Sensitive as SSH?

Any library can tamper with the inner workings of any executable it is linked against.
OpenSSH, the most popular sshd implementation, doesn’t link the liblzma library, but Debian and many other Linux distributions add a patch to link sshd to systemd, a program that loads a variety of services during the system bootup. Systemd, in turn, links to liblzma, and this allows XZ Utils to exert control over sshd.

[khionu]

I'm wondering if other SSH implementations are susceptible also.

Not relevant to us, the exploit targeted the server-side daemon

[HybridEidolon]

I anticipate that changing to OpenSSH will probably fix the same issue on Windows that #3554 is attempting to address. Hard to imagine it being anything other than strictly better.

[emilazy]

The following patch fixes the Nix build for me:

diff --git a/Cargo.lock b/Cargo.lock
index 4b1d4c56f8...9a1f618ca9 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -1846,7 +1846,6 @@
 dependencies = [
  "cc",
  "libc",
- "libssh2-sys",
  "libz-sys",
  "openssl-sys",
  "pkg-config",
@@ -1864,20 +1863,6 @@
 ]
 
 [[package]]
-name = "libssh2-sys"
-version = "0.3.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "2dc8a030b787e2119a731f1951d6a773e2280c660f8ec4b0f5e1505a386e71ee"
-dependencies = [
- "cc",
- "libc",
- "libz-sys",
- "openssl-sys",
- "pkg-config",
- "vcpkg",
-]
-
-[[package]]
 name = "libz-sys"
 version = "1.1.16"
 source = "registry+https://github.com/rust-lang/crates.io-index"
diff --git a/flake.nix b/flake.nix
index 4fba5310ff...c06feae22c 100644
--- a/flake.nix
+++ b/flake.nix
@@ -84,7 +84,7 @@
 
           cargoLock.lockFile = ./Cargo.lock;
           cargoLock.outputHashes = {
-            "git2-0.18.3" = "sha256-Kfg3xWIAarAxeIo2wL30OFni7X4Thf9EzaXbFTWsehE=";
+            "git2-0.18.3" = "sha256-3g7ajPfLfuPWh46rIa70wQRWLZ+jZXBApkyPlJULi/I=";
           };
           nativeBuildInputs = with pkgs; [
             gzip

(An ironically retro way to share the change, I realize!)

[charlottia]

Just noting that I've been daily-driving this PR for a few days (rebased on main) and it's been working really beautifully for me! Thank you!

[codeslinger]

I've been using this branch ever since I started using jj a month ago and its had no problems. Thanks!

[ErichDonGubler]

Also wanted to dog-pile the praise here: This PR is what has allowed me to use JJ's jj git {fetch,push} on Windows in the same way as other platforms. It's let me enjoy JJ to make my life much simpler. Thank you, @bnjmnt4n!

[itinerare]

I've likewise been using this PR (rebased on main) and it's been very helpful! The only issue I've run into is that it doesn't seem to respect the "port" value in ~/.ssh/config; this was resolved by changing the relevant remote(s) to use the ssh://user@host:port/path/to/repo format for addresses, but ideally I'd like to be able to use the existing global setting from ~/.ssh/config/not to need to specify that per remote when connecting via a non-standard port.

[Maverik]

I would love to take this PR for a spin as well. I've just started using JJ and cannot get it to fetch/push etc because of libgit2 issues (my identities are tied to hosts through ssh config file but libgit can't even see my windows ssh environment initialized). I've tried building this PR from source, but unfortunately cmake isn't happy with my msbuild VC tools.

Is there any way to get the artefacts from somewhere that the CI is already building up?

PS: thank you very much for this PR work. Looking forward to it landing upstream. From my limited use of JJ, I can't wait to make it my daily driver! Thank you team <3

[martinvonz]

Is there any way to get the artefacts from somewhere that the CI is already building up?

I'm afraid not. I think you'll have to fetch from Benjamin's repo and build from source.

[charlottia]

@Maverik what kind of trouble? I found this was enough on Windows for me:

cargo install --git https://github.com/bnjmnt4n/jj.git --branch ssh-openssh --locked --bin jj jj-cli --features vendored-openssl

(but I'm not sure what the difference in the rest of our non-Rust environments are like)

[Maverik]

@Maverik what kind of trouble? I found this was enough on Windows for me:

cargo install --git https://github.com/bnjmnt4n/jj.git --branch ssh-openssh --locked --bin jj jj-cli --features vendored-openssl

(but I'm not sure what the difference in the rest of our non-Rust environments are like)

I was having issue with cmake calling msbuild and finding VCTargetsPath as empty. I did a "repair" on VS installer and I think that fixed it. Having your command to hand was helpful as a reference point that I wasn't just messing up the install myself.

I was able to compile both the branch directly and through above after repairing the install. Thank you for the swift help.

[thoughtpolice]

Is there any way to get the artefacts from somewhere that the CI is already building up?

I'm afraid not. I think you'll have to fetch from Benjamin's repo and build from source.

The current system does actually build binaries from main and create GitHub artifacts, like so: https://github.com/martinvonz/jj/actions/runs/12251132093

In theory we could extend this to the PRs pretty easily. I'd say I'm worried about users downloading random binaries, but in this case they're already compiling them anyway... So it's probably not that bad, I guess.

[martinvonz]

It would also be wasteful to build release binaries that don't get used in 99.9% of cases.