FR: better error for ssh hostname changes #1507

fowles · 2023-04-11T19:03:27Z

I recently tried to use jj to push to github. The error I got was very perplexing to me. In particular I saw this.

[sonmi]~/dev/protobuf$ jj git push
Branch changes to push to origin:
  Add branch test_jj to 5a9dbd9a4edc
Error: invalid or unknown remote ssh hostkey; class=Ssh (23); code=Certificate (-17)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work?

I eventually traced this down to the recent github host changing

[sonmi]~/dev$ git clone [email protected]:fowles/abseil-hello.git
Cloning into 'abseil-hello'...
The authenticity of host 'github.com (140.82.114.3)' can't be established.
ED25519 key fingerprint is XXXXXXXXXXXXX
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Warning: the ED25519 host key for 'github.com' differs from the key for the IP address '140.82.114.3'
Offending key for IP in /usr/local/google/home/kfm/.ssh/known_hosts:6
Are you sure you want to continue connecting (yes/no)? yes

so this fixed it, but an error message that told me something more (or better yet gave me the prompt that git does) would be awesome.

The text was updated successfully, but these errors were encountered:

necauqua · 2023-04-12T01:54:29Z

While this is true and we need a better human error, the ssh -F /dev/null hint was added because of this - did it not help you trace it down to the github thing right away?

ssh [email protected] would fail with a giant MITM error, prompting you to do ssh-key -R github.com and then ssh [email protected] again to get the new fingerprint.

fowles · 2023-04-12T01:58:32Z

truthfully I did not try ssh [email protected] because I just assumed there is no possible way that github left the default port for ssh open in that way. I am used to thinking of ssh solely in terms of machines I have remote terminal access to and I don't have remote terminal access to github. I suspect that if the suggestion had said to try ssh -F /dev/null [email protected] I would have tried that.

The end result is that I actually spent about 45 minutes trying various stupid things before figuring out the workaround I did.

necauqua · 2023-04-12T02:05:54Z

default port for ssh open in that way

Well what port would the git clone ~~over ssh~~ use then? :)

I suspect that if the suggestion had said to try ssh -F /dev/null [email protected] I would have tried that.

That should be an easy partial fix for the hint then, thanks, makes total sense that people don't think about ssh-ing to github.com like that.

Ideally ofc the hint would be specifically for when host identification changes like it happened with github, libssh2 errors dont give too much information though it seems

fowles · 2023-04-12T02:48:43Z

Well what port would the git clone ~~over ssh~~ use then? :)

Honestly, I had never thought about it. It is funny the abstractions we just accept :)

martinvonz · 2023-04-12T04:54:33Z

I suspect we should add a certificate_check callback and check known_hosts there but that's just a guess.

clintonc · 2023-06-06T16:19:23Z

Relatedly, when I attempted jj git clone [email protected]:..., I got the following error both before and after removing github.com from my known hosts:

Error: Fetch failed: invalid or unknown remote ssh hostkey; class=Ssh (23); code=Certificate (-17)

When I did a normal git clone with the same argument, I got the normal new host flow:

The authenticity of host 'github.com (192.30.255.113)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,192.30.255.113' (ECDSA) to the list of known hosts.

In this case, there was no error message to help me figure out (or remediate) the problem.

martinvonz · 2023-06-06T17:14:26Z

If you install jj from head, you should at least get a hint there: https://github.com/martinvonz/jj/blob/0c36b1ad4e13f270b015868d1dd66cd42f11490e/src/commands/git.rs#L165-L181

I'm guessing jj git clone works now after the successful git clone?

clintonc · 2023-06-07T16:35:00Z

I installed jj from head (using the cargo command above), and a hint does show then. Cloning does not work afterwards (just hangs; verbose logs just shows a lot of lines like INFO fetch{remote_name="origin" branch_name_globs=None git_settings=GitSettings { auto_local_branch: true }}: jujutsu_lib::git: using ssh_key_from_agent username="git", eventually failing with Error: remote rejected authentication: Failed getting response; class=Ssh (23); code=Auth (-16)) but that's a separate issue.

zzhaolei · 2024-08-25T03:50:21Z

(I turned on VPN (quantumult x).Yes, I have to turn it on.)

I encountered a similar situation
https is ok, but ssh failed:

11:37 ❯ jj git clone https://github.com/zzhaolei/jj-demo.git
Fetching into new repo in "/Users/zhaolei/Study/jj-demo"
branch: main@origin [new] untracked
Setting the revset alias "trunk()" to "main@origin"
Working copy now at: srltlnwl d6627064 (empty) (no description set)
Parent commit      : luoyttxn 58cd234f main | add gitignore
Added 2 files, modified 0 files, removed 0 files
11:37 ❯ rm -rf jj-demo/
11:37 ❯ jj git clone [email protected]:zzhaolei/jj-demo.git
Fetching into new repo in "/Users/zhaolei/Study/jj-demo"
Error: failed to start SSH session: Failed getting banner; class=Ssh (23)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work?

11:39 ❯ ssh -F /dev/null [email protected]
Connection closed by 198.18.1.134 port 22

git erverything is ok:

11:40 ❯ git clone https://github.com/zzhaolei/jj-demo.git
...
11:40 ❯ rm -rf jj-demo/
11:40 ❯ git clone [email protected]:zzhaolei/jj-demo.git
...

11:42 ❯ ssh -T [email protected]
Hi zzhaolei! You've successfully authenticated, but GitHub does not provide shell access.

~/.ssh/config and ~.gitconfig has no configuration for github.com

yuchenshi · 2024-10-02T23:58:28Z

I'm guessing jj git clone works now after the successful git clone?

@martinvonz I just ran into this when cloning for the first time on a new device. The ssh -F /dev/null hint was helpful and prompted me to accept the public key for github.com for the first time. And then it worked perfectly fine. Does libssh2 have a way to add the key to known hosts (after user confirmation)?

martinvonz · 2024-10-03T00:11:20Z

Does libssh2 have a way to add the key to known hosts (after user confirmation)?

Yes, looks like it: https://libssh2.org/libssh2_knownhost_addc.html There's also #3191 for switching from libssh2 to OpenSSH, which should solve lots of problems related to ssh config.

Reasoning: `jj` fails to push/fetch over ssh depending on the system. Issue jj-vcs#4979 lists over 20 related issues on this and proposes spawning a `git` subprocess for tasks related to the network (in fact, just push/fetch are enough). This PR implements this. Users can either enable shelling out to git in a config file: ```toml [git] subprocess = true ``` Implementation Details: This PR implements shelling out to `git` via `std::process::Command`. There are 2 sharp edges with the patch: - it relies on having to parse out git errors to match the error codes (and parsing git2's errors in one particular instance to match the error behaviour). This seems mostly unavoidable - to ensure matching behaviour with git2, the tests are maintained across the two implementations. This is done using test_case, as with the rest of the codebase Testing: Run the rust tests: ``` $ cargo test ``` Build: ``` $ cargo build ``` Clone a private repo: ``` $ path/to/jj git clone --shell <REPO_SSH_URL> ``` Create new commit and push ``` $ echo "TEST" > this_is_a_test_file.txt $ path/to/jj describe -m 'test commit' $ path/to/jj git push --shell -b <branch> ``` Issues Closed With a grain of salt, but most of these problems should be fixed (or at least checked if they are fixed). They are the ones listed in jj-vcs#4979 . SSH: - jj-vcs#63 - jj-vcs#440 - jj-vcs#1455 - jj-vcs#1507 - jj-vcs#2931 - jj-vcs#2958 - jj-vcs#3322 - jj-vcs#4101 - jj-vcs#4333 - jj-vcs#4386 - jj-vcs#4488 - jj-vcs#4591 - jj-vcs#4802 - jj-vcs#4870 - jj-vcs#4937 - jj-vcs#4978 - jj-vcs#5120 - jj-vcs#5166 Clone/fetch/push/pull: - jj-vcs#360 - jj-vcs#1278 - jj-vcs#1957 - jj-vcs#2295 - jj-vcs#3851 - jj-vcs#4177 - jj-vcs#4682 - jj-vcs#4719 - jj-vcs#4889 - jj-vcs#5147 - jj-vcs#5238 Notable Holdouts: - Interactive HTTP authentication (jj-vcs#401, jj-vcs#469) - libssh2-sys dependency on windows problem (can only be removed if/when we get rid of libgit2): jj-vcs#3984

Reasoning: `jj` fails to push/fetch over ssh depending on the system. Issue jj-vcs#4979 lists over 20 related issues on this and proposes spawning a `git` subprocess for tasks related to the network (in fact, just push/fetch are enough). This PR implements this. Users can either enable shelling out to git in a config file: ```toml [git] subprocess = true ``` Implementation Details: This PR implements shelling out to `git` via `std::process::Command`. There are 2 sharp edges with the patch: - it relies on having to parse out git errors to match the error codes (and parsing git2's errors in one particular instance to match the error behaviour). This seems mostly unavoidable - to ensure matching behaviour with git2, the tests are maintained across the two implementations. This is done using test_case, as with the rest of the codebase Testing: Run the rust tests: ``` $ cargo test ``` Build: ``` $ cargo build ``` Clone a private repo: ``` $ path/to/jj git clone --shell <REPO_SSH_URL> ``` Create new commit and push ``` $ echo "TEST" > this_is_a_test_file.txt $ path/to/jj describe -m 'test commit' $ path/to/jj git push --shell -b <branch> ```  Issues Closed With a grain of salt, but most of these problems should be fixed (or at least checked if they are fixed). They are the ones listed in jj-vcs#4979 . SSH: - jj-vcs#63 - jj-vcs#440 - jj-vcs#1455 - jj-vcs#1507 - jj-vcs#2931 - jj-vcs#2958 - jj-vcs#3322 - jj-vcs#4101 - jj-vcs#4333 - jj-vcs#4386 - jj-vcs#4488 - jj-vcs#4591 - jj-vcs#4802 - jj-vcs#4870 - jj-vcs#4937 - jj-vcs#4978 - jj-vcs#5120 - jj-vcs#5166 Clone/fetch/push/pull: - jj-vcs#360 - jj-vcs#1278 - jj-vcs#1957 - jj-vcs#2295 - jj-vcs#3851 - jj-vcs#4177 - jj-vcs#4682 - jj-vcs#4719 - jj-vcs#4889 - jj-vcs#5147 - jj-vcs#5238 Notable Holdouts: - Interactive HTTP authentication (jj-vcs#401, jj-vcs#469) - libssh2-sys dependency on windows problem (can only be removed if/when we get rid of libgit2): jj-vcs#3984

Reasoning: `jj` fails to push/fetch over ssh depending on the system. Issue jj-vcs#4979 lists over 20 related issues on this and proposes spawning a `git` subprocess for tasks related to the network (in fact, just push/fetch are enough). This PR implements this. Users can either enable shelling out to git in a config file: ```toml [git] subprocess = true ``` Implementation Details: This PR implements shelling out to `git` via `std::process::Command`. There are 2 sharp edges with the patch: - it relies on having to parse out git errors to match the error codes (and parsing git2's errors in one particular instance to match the error behaviour). This seems mostly unavoidable - to ensure matching behaviour with git2, the tests are maintained across the two implementations. This is done using test_case, as with the rest of the codebase Testing: Run the rust tests: ``` $ cargo test ``` Build: ``` $ cargo build ``` Clone a private repo: ``` $ path/to/jj git clone --config='git.subprocess=true' <REPO_SSH_URL> ``` Create new commit and push ``` $ echo "TEST" > this_is_a_test_file.txt $ path/to/jj describe -m 'test commit' $ path/to/jj git push --config='git.subprocess=true' -b <branch> ```  Issues Closed With a grain of salt, but most of these problems should be fixed (or at least checked if they are fixed). They are the ones listed in jj-vcs#4979 . SSH: - jj-vcs#63 - jj-vcs#440 - jj-vcs#1455 - jj-vcs#1507 - jj-vcs#2931 - jj-vcs#2958 - jj-vcs#3322 - jj-vcs#4101 - jj-vcs#4333 - jj-vcs#4386 - jj-vcs#4488 - jj-vcs#4591 - jj-vcs#4802 - jj-vcs#4870 - jj-vcs#4937 - jj-vcs#4978 - jj-vcs#5120 - jj-vcs#5166 Clone/fetch/push/pull: - jj-vcs#360 - jj-vcs#1278 - jj-vcs#1957 - jj-vcs#2295 - jj-vcs#3851 - jj-vcs#4177 - jj-vcs#4682 - jj-vcs#4719 - jj-vcs#4889 - jj-vcs#5147 - jj-vcs#5238 Notable Holdouts: - Interactive HTTP authentication (jj-vcs#401, jj-vcs#469) - libssh2-sys dependency on windows problem (can only be removed if/when we get rid of libgit2): jj-vcs#3984

Reasoning: `jj` fails to push/fetch over ssh depending on the system. Issue jj-vcs#4979 lists over 20 related issues on this and proposes spawning a `git` subprocess for tasks related to the network (in fact, just push/fetch are enough). This PR implements this. Implementation Details: This PR implements shelling out to `git` via `std::process::Command`. There are 2 sharp edges with the patch: - it relies on having to parse out git errors to match the error codes (and parsing git2's errors in one particular instance to match the error behaviour). This seems mostly unavoidable - to ensure matching behaviour with git2, the tests are maintained across the two implementations. This is done using test_case, as with the rest of the codebase Testing: Run the rust tests: ``` $ cargo test ``` Build: ``` $ cargo build ``` Clone a private repo: ``` $ path/to/jj git clone --config='git.subprocess=true' <REPO_SSH_URL> ``` Create new commit and push ``` $ echo "TEST" > this_is_a_test_file.txt $ path/to/jj describe -m 'test commit' $ path/to/jj git push --config='git.subprocess=true' -b <branch> ``` Issues Closed With a grain of salt, but most of these problems should be fixed (or at least checked if they are fixed). They are the ones listed in jj-vcs#4979 . SSH: - jj-vcs#63 - jj-vcs#440 - jj-vcs#1455 - jj-vcs#1507 - jj-vcs#2931 - jj-vcs#2958 - jj-vcs#3322 - jj-vcs#4101 - jj-vcs#4333 - jj-vcs#4386 - jj-vcs#4488 - jj-vcs#4591 - jj-vcs#4802 - jj-vcs#4870 - jj-vcs#4937 - jj-vcs#4978 - jj-vcs#5120 - jj-vcs#5166 Clone/fetch/push/pull: - jj-vcs#360 - jj-vcs#1278 - jj-vcs#1957 - jj-vcs#2295 - jj-vcs#3851 - jj-vcs#4177 - jj-vcs#4682 - jj-vcs#4719 - jj-vcs#4889 - jj-vcs#5147 - jj-vcs#5238 Notable Holdouts: - Interactive HTTP authentication (jj-vcs#401, jj-vcs#469) - libssh2-sys dependency on windows problem (can only be removed if/when we get rid of libgit2): jj-vcs#3984

Reasoning: `jj` fails to push/fetch over ssh depending on the system. Issue #4979 lists over 20 related issues on this and proposes spawning a `git` subprocess for tasks related to the network (in fact, just push/fetch are enough). This PR implements this. Implementation Details: This PR implements shelling out to `git` via `std::process::Command`. There are 2 sharp edges with the patch: - it relies on having to parse out git errors to match the error codes (and parsing git2's errors in one particular instance to match the error behaviour). This seems mostly unavoidable - to ensure matching behaviour with git2, the tests are maintained across the two implementations. This is done using test_case, as with the rest of the codebase Testing: Run the rust tests: ``` $ cargo test ``` Build: ``` $ cargo build ``` Clone a private repo: ``` $ path/to/jj git clone --config='git.subprocess=true' <REPO_SSH_URL> ``` Create new commit and push ``` $ echo "TEST" > this_is_a_test_file.txt $ path/to/jj describe -m 'test commit' $ path/to/jj git push --config='git.subprocess=true' -b <branch> ``` Issues Closed With a grain of salt, but most of these problems should be fixed (or at least checked if they are fixed). They are the ones listed in #4979 . SSH: - #63 - #440 - #1455 - #1507 - #2931 - #2958 - #3322 - #4101 - #4333 - #4386 - #4488 - #4591 - #4802 - #4870 - #4937 - #4978 - #5120 - #5166 Clone/fetch/push/pull: - #360 - #1278 - #1957 - #2295 - #3851 - #4177 - #4682 - #4719 - #4889 - #5147 - #5238 Notable Holdouts: - Interactive HTTP authentication (#401, #469) - libssh2-sys dependency on windows problem (can only be removed if/when we get rid of libgit2): #3984

PhilipMetzger added the enhancement New feature or request label Sep 29, 2023

arxanas mentioned this issue Nov 26, 2024

FR: Resolve many SSH issues by having networked jj git commands shell out to git #4979

Closed

bsdinis mentioned this issue Jan 9, 2025

git: spawn a separate git process for network operations #5228

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FR: better error for ssh hostname changes #1507

FR: better error for ssh hostname changes #1507

fowles commented Apr 11, 2023

necauqua commented Apr 12, 2023

fowles commented Apr 12, 2023

necauqua commented Apr 12, 2023 •

edited

Loading

fowles commented Apr 12, 2023

martinvonz commented Apr 12, 2023

clintonc commented Jun 6, 2023

martinvonz commented Jun 6, 2023

clintonc commented Jun 7, 2023

zzhaolei commented Aug 25, 2024 •

edited

Loading

yuchenshi commented Oct 2, 2024

martinvonz commented Oct 3, 2024

FR: better error for ssh hostname changes #1507

FR: better error for ssh hostname changes #1507

Comments

fowles commented Apr 11, 2023

necauqua commented Apr 12, 2023

fowles commented Apr 12, 2023

necauqua commented Apr 12, 2023 • edited Loading

fowles commented Apr 12, 2023

martinvonz commented Apr 12, 2023

clintonc commented Jun 6, 2023

martinvonz commented Jun 6, 2023

clintonc commented Jun 7, 2023

zzhaolei commented Aug 25, 2024 • edited Loading

yuchenshi commented Oct 2, 2024

martinvonz commented Oct 3, 2024

necauqua commented Apr 12, 2023 •

edited

Loading

zzhaolei commented Aug 25, 2024 •

edited

Loading