Jj git fetch not connecting to ssh-agent

xelxebar commented 1 year ago

Overview

For some reason, ssh operations don't seem to be connecting to the ssh-agent for me. This is means that my ~/.ssh/config doesn't get read, so port and key settings never get read:

$ jj git fetch
Error: Unexpected git error when fetching: failed to connect to git.wilsonb.com: Connection refused; class=Os (2)

Sanity checks

Level 1

I am fairly sure my ssh-agent is running and SSH_AUTH_SOCK is setup correctly:

$ ssh-add -L
...
<my key>
...

Level 2

But, just to be sure, I directly checked whether jj is actually trying to connect to ssh-agent

$ strace -fo ~/jj.strace jj git fetch
...
$ grep -F "$SSH_AUTH_SOCK" ~/jj.strace || echo nope
nope

Level 3

But since SSH_AUTH_SOCK was added in 4a1576c, I started to doubt my sanity, so I ran ssh-agent -d, which stays in the foreground and noisily shows when anyone connects. Running something like ssh example.com does cause it to generate connection logs; however, in the same shell as that working ssh command, running jj git fetch errors out, and ssh-agent stays completely silent.

Am I missing something obvious?

Version info

I am running the latest flake on HEAD:

$ nix shell github:martinvonz/jj#jujutsu
$ command -v jj
/nix/store/8i7lzldsqwl35zl04p8x7vlll03zjch4-jujutsu-unstable-86318bf/bin/jj

joyously commented 1 year ago

grep -F "$SSH_AUTH_SOCK" ~/jj.fetch || echo nope

I had to read about shell operators, but didn't get a clear answer on how the shell parses || ; as meaning "OR" or meaning pipe to nothing and then pipe to the echo. (I need a better reference manual, but don't know what shell you are using.)

xelxebar commented 1 year ago

Ah, that's just showing that grep failed to find anything. The relevant documentation for || is POSIX shell OR Lists. The key in this case is to know that grep exits with 1 when it finds zero matches.

martinvonz commented 1 year ago

What's the remote's URL? Does git clone from the same URL work? How about jj git clone?

xelxebar commented 1 year ago

It's my personal server: git@git.wilsonb.com:dyalog-play.git, and git clone succeeds, but jj git clone fails. The error message itself can probably be ignored. I'm running sshd on funky random port, so connect is getting ECONNREFUSED since it's not ussing ssh-agent and probably trying to directly connect over 22.

martinvonz commented 1 year ago

I suspect this is a libgit2 thing. I found https://stackoverflow.com/questions/41101414/unable-to-make-julia-package-manager-work-behind-proxy and https://discourse.julialang.org/t/using-pkg-behind-a-firewall/6295 about a similar issue. Do you have $HTTP_PROXY and/or $HTTPS_PROXY set? Maybe you need to move those to config in that case.

xelxebar commented 1 year ago

Unfortunately, that's not the culprit:

$ env | grep -Fi proxy || echo nope
nope

martinvonz commented 1 year ago

I don't have any other ideas, I'm afraid. I still suspect it's a libgit2 bug/limitation, or possibly a bug in how we use libgit2.

xelxebar commented 1 year ago

Roger. I'll try to spin up a Rust dev env and see what I can find.

yuja commented 1 year ago

I'm running sshd on funky random port,

Where did you set the destination port number? jj might not read ~/.ssh/config because it doesn't use the openssh's ssh command.

xelxebar commented 1 year ago

Hah. You're completely right. Embedding the port number in the fetch URL did the trick: ssh://git@git.wilsonb.com:24570/~/dyalog-play.git.

I was thinking that ssh-agent passed connection establishment off to openssh somehow, but it turns out that ssh-agent keeps its responsibilities small and only provides auth tokens. Here's a good overview explanation: https://unix.stackexchange.com/questions/338853/how-to-use-ssh-agent-for-offering-host-specific-keys-from-ssh-config-file-and#answer-590262

It's pretty annoying that sshlib2 pushes ssh_config parsing off to its users. Anyway, since that's on our radar already and this issue is unrelated, I'm closing.

xxxserxxx commented 1 year ago

What if it's not the port? I tried again with Sourcehut, but it seems to still be broken.

1334
389
928

Is there any chance of replacing libgit2? It seems to be having a remarkable number of issues.

xelxebar commented 1 year ago

@xxxserxxx It's hard to say without knowing specifics of your case.

Is ssh-agent running?
Do you have SSH_AUTH_SOCK set correctly?
Have you added your key(s) with ssh-add?
What settings, if any, are you setting in ~/.ssh/config that apply to SourceHut?

Is there any chance of replacing libgit2? It seems to be having a remarkable number of issues.

AFAICT, the issues are all centered around libssh2 (not libgit2) electing to not parse ssh_config files.

martinvonz commented 1 year ago

@xxxserxxx, see the update from @yuja in https://github.com/martinvonz/jj/issues/389#issuecomment-1473098558.

xxxserxxx commented 1 year ago

@martinvonz, #389 doesn't fix it for me:

$ ###### Remove the existing keys
$ ssh-keygen -R git.sr.ht -f .ssh/known_hosts
# Host git.sr.ht found: line 40
# Host git.sr.ht found: line 61
.ssh/known_hosts updated.
Original contents retained as .ssh/known_hosts.old
$ 
$ ###### And then, from the the instructions, re-add the keys (keys trimmed for brevity)
$ cat >> .ssh/known_hosts
git.sr.ht ssh-rsa AAAAB3...W+UvKB3SOz
git.sr.ht ecdsa-sha2-nistp256 AAAAE2VjZHN...WTkmglpYhFp4Iy4=
git.sr.ht ssh-ed25519 AAAAC3NzaC1lZ...DSAvW0t2Tkj60
$ 
$ ###### Cloning with jj fails
$ jj git clone git@git.sr.ht:~ser/gonic
Fetching into new repo in "/home/ser/gonic"
Error: Fetch failed: failed to start SSH session: Unable to exchange encryption keys; class=Ssh (23)
$ 
$ ###### But cloning with git succeeds
$ git clone git@git.sr.ht:~ser/gonic
Cloning into 'gonic'...
X11 forwarding request failed on channel 0
remote: Enumerating objects: 8702, done.
remote: Counting objects: 100% (8702/8702), done.
remote: Compressing objects: 100% (2653/2653), done.
remote: Total 8702 (delta 5643), reused 8702 (delta 5643), pack-reused 0
Receiving objects: 100% (8702/8702), 42.80 MiB | 1.67 MiB/s, done.
Resolving deltas: 100% (5643/5643), done.

To answer @xelxebar's questions, yes, ssh-agent is running -- and verified with the correct key, since the previous git clone worked. But test it anyway trimming the keys for brevity:

$ ssh-add -L
ssh-rsa AAAAB3N...XzHVWc= ser@glamdring
ssh-rsa AAAAB3Nz...7sedW+EKEHDcFYpNpk= /home/ser/.ssh/id_rsa
ssh-ed25519 AAAAC3NzaC...1v2HFDG+dDv1w9VihOIv7J57w ser@glamdring
ssh-dss AAAAB3Nz...OHE+cpyB3IqbwA== /home/ser/.ssh/id_dsa
$ 
$ ###### I have nothing in my .ssh/config for Sourcehut
$ grep sr.ht ~/.ssh/config
$

So: I completely moved .ssh out of the way, copied only the required in, and ran a totally new agent; git cloned the repo successfully, jj git fails.

$ mv .ssh ssh_
$ mkdir .ssh
$ cat > .ssh/known_hosts
git.sr.ht ssh-rsa AAAAB...PYW+UvKB3SOz
git.sr.ht ecdsa-sha2-nistp256 AAAAE...TkmglpYhFp4Iy4=
git.sr.ht ssh-ed25519 AAAAC3...SAvW0t2Tkj60
$ 
$ ###### Set up ssh-agent again
$ eval $(ssh-agent)
Agent pid 2971163
$ ssh-add -L
The agent has no identities.
$ ssh-add .ssh_/id_rsa
Enter passphrase for .ssh_/id_rsa:
Identity added: .ssh_/id_rsa (.ssh_/id_rsa)
$ ssh-add -L
ssh-rsa AAAAB3Nz...W+EKEHDcFYpNpk= .ssh_/id_rsa
$ 
$ ###### Test git success
$ git clone git@git.sr.ht:~ser/gonic
Cloning into 'gonic'...
remote: Enumerating objects: 8702, done.
remote: Counting objects: 100% (8702/8702), done.
remote: Compressing objects: 100% (2653/2653), done.
remote: Total 8702 (delta 5643), reused 8702 (delta 5643), pack-reused 0
Receiving objects: 100% (8702/8702), 42.80 MiB | 1.56 MiB/s, done.
Resolving deltas: 100% (5643/5643), done.
$ 
$ rm -rf gonic
$ jj -v git clone git@git.sr.ht:~ser/gonic
2023-03-17T17:21:00.505079Z DEBUG jujutsu::cli_util: verbose logging enabled
Fetching into new repo in "/home/ser/gonic"
2023-03-17T17:21:00.531264Z DEBUG fetch{remote_name="origin" branch_name_globs=None git_settings=GitSettings { auto_local_branch: true }}: jujutsu_lib::git: remote.download
Error: Fetch failed: failed to start SSH session: Unable to exchange encryption keys; class=Ssh (23)
$

I was able to clone from Sourcehut earlier by building with --no-default-features; it was recommended in another ticket because it disabled bundled libssh2 (or something like that). However, with or without that it no longer talks to Sourcehut. Github and Gitlab work; just not Sourcehut:

$ jj git clone git@github.com:xxxserxxx/stmp.git stmp
Fetching into new repo in "/home/ser/stmp"
Working copy now at: 26128964732d (no description set)
Added 12 files, modified 0 files, removed 0 files
$ 
$ jj git clone git@gitlab.com:serussell/logxi.git
Fetching into new repo in "/home/ser/logxi"
Working copy now at: 29639e852b47 (no description set)
Added 29 files, modified 0 files, removed 0 files
$ 
$ jj git clone git@git.sr.ht:~ser/stmp
Fetching into new repo in "/home/ser/stmp"
Error: Fetch failed: failed to start SSH session: Unable to exchange encryption keys; class=Ssh (23)
$

yuja commented 1 year ago

$ cat >> .ssh/known_hosts
git.sr.ht ssh-rsa AAAAB3...W+UvKB3SOz
git.sr.ht ecdsa-sha2-nistp256 AAAAE2VjZHN...WTkmglpYhFp4Iy4=
git.sr.ht ssh-ed25519 AAAAC3NzaC1lZ...DSAvW0t2Tkj60

If you mean you've added the ssh-rsa line, remove it (or at least move it after the other lines.)

xxxserxxx commented 1 year ago

Hmm. Without the ssh-rsa key, it now gives a different error. Cloning with plain git still works, though.

$  ssh-keygen -R git.sr.ht -f .ssh/known_hosts
# Host git.sr.ht found: line 94
# Host git.sr.ht found: line 95
.ssh/known_hosts updated.
Original contents retained as .ssh/known_hosts.old

$ cat >> .ssh/known_hosts
git.sr.ht ecdsa-sha2-nistp256 AAAA...1GGwF4g1jwu3L8gOZUTIvUptqWTkmglpYhFp4Iy4=
git.sr.ht ssh-ed25519 AAAAC3NzaC...W0t2Tkj60

$ ssh-keygen -F git.sr.ht -f .ssh/known_hosts 
# Host git.sr.ht found: line 94
git.sr.ht ecdsa-sha2-nistp256 AAAAE2VjZHN...GGwF4g1jwu3L8gOZUTIvUptqWTkmglpYhFp4Iy4=
# Host git.sr.ht found: line 95
git.sr.ht ssh-ed25519 AAAAC3NzaC...U3VLQTSwQDSAvW0t2Tkj60

$ jj git clone git@git.sr.ht:~ser/stmp
Fetching into new repo in "/home/ser/stmp"
Error: Fetch failed: Failed to retrieve list of SSH authentication methods: Failed getting response; class=Ssh (23); code=Auth (-16)

Edit: re-arranging the remaining two sr.ht keys in the file makes no difference.

yuja commented 1 year ago

Error: Fetch failed: Failed to retrieve list of SSH authentication methods: Failed getting response; class=Ssh (23); code=Auth (-16)

I got this error if I deleted my private keys from the agent (ssh-add -D), but I have no idea if that's the error you saw.

jj -v (or RUST_LOG=trace jj) might show some more information, but tracing options are far more restricted compared to ssh -v. You can also use wireshark to inspect the initial key exchange part.

xelxebar commented 1 year ago

FWIW, I can successfully reproduce.

After playing around a bit, the issue only appears when I have lots of keys in ssh-agent. In fact, it only happens when my sourcehut keys is low in the list of keys added to ssh-agent. The last successful cutoff seems to be 6th place. I am guessing that libssh2 simply ends up trying all keys in the agent, in order, and that Sourcehut has a hard limit of 5 on the number of failed auth attempts before forecfully killing the connection.

@xxxserxxx What happens if you use an ssh-agent with only your Sourcehut key?

The "correct" fix in this case is to register each of your keys with ssh-agent to be host-specific, cf the -h flag from ssh-add(1).

xxxserxxx commented 1 year ago

How many are "lots of keys?" I rarely have about 4 keys registered in my agent, although there are ca. 96 in my known_hosts. My private key is an RSA key

If I register only the access key for Sourcehut, and have only the sr.ht keys in known_hosts, and add a host constraint, I continue to get the error.

$ cat .ssh/known_hosts | cut -b -60
git.sr.ht ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMZvRd4EtM7R+I
git.sr.ht ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNT

$ eval $(ssh-agent)
Agent pid 555692

$ ssh-add -h git.sr.ht .ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)

$ ssh-add -L | cut -b -60
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA5zu8ta8M23L3VZeY7EjxNqyg

$ jj git clone git@git.sr.ht:~ser/stmp
Fetching into new repo in "/home/ser/stmp"
Error: Fetch failed: Failed to retrieve list of SSH authentication methods: Failed getting response; class=Ssh (23); code=Auth (-16)

Git, as usual, succeeds. RUST_LOG=trace doesn't tell any more than that it's using the ssh_key_from_agent.

@yuja how would I use ssh -v with jj? I'm happy to try; I don't know that using ssh alone would tell me anything, since I have no problem using the key or connecting with Sourcehut with anything but jj git. Git itself works fine, and I have several Mercurial repos which also use the same key successfully (e.g. default = ssh://hg@hg.sr.ht/~ser/forage).

yuja commented 1 year ago

Maybe you can try other type of private key? My key is ssh-ed25519, which appears to work for jj to connect to git.sr.ht.

how would I use ssh -v with jj?

I don't know libgit2 internals, but maybe it doesn't support shelling out ssh transport. What we can do with ssh -vvv... is, to trace how git/hg can establish ssh connection, and guess workaround for libgit2/libssh2.

xelxebar commented 1 year ago

@xxxserxxx I recommend doing some sanity checking yourself: E.g.

Are you sure you sure git is actually connecting to ssh-agent? E.g. put ssh-agent in a known broken state (i.e. with no keys) and make sure git clone fails.
Is ssh-agent actually getting a request from jj? I.e. run ssh-agent in the foreground with debug logs enabled. Compare logs between when you run jj git clone and git clone;
Exactly what settings are needed for git clone to work? E.g. Drop into a lightweight Alpine Linux container (or whatever) and set up the bare minimum needed to connect with git.

The above are just examples. The key is to doggedly check your assumptions, which will help you nail down exactly what is falling over. Heck, there is a whole zoo of more low-level options for debugging as well, e.g. strace/ltrace, rust-gdb, etc.

xxxserxxx commented 1 year ago

I've confirmed that git uses the agent; it asks for the key password, and fails if I don't provide it. However, if I add the key to the agent, it then succeeds. I'll spare you the shell output.

I'll also clip most of the text for running ssh-agent in debug mode; here is the output for both git clone and jj git clone -- they're both talking to the ssh-agent:

ssh-agent -d output; they're different for git and jj git, but they're both connecting to the agent, requesting and then receiving a key.

$ ssh-agent -d
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXOwhxAa/agent.897184; export SSH_AUTH_SOCK;
echo Agent pid 897184;

########## ... output truncated

###### git clone
debug1: new_socket: type = CONNECTION
debug2: fd 4 setting O_NONBLOCK
debug1: process_message: socket 1 (fd=4) type 27
debug2: process_extension: entering
debug2: process_ext_session_bind: entering
debug1: process_ext_session_bind: recorded ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g (slot 0 of 16)
debug1: process_message: socket 1 (fd=4) type 11
debug2: process_request_identities: entering
debug3: identity_permitted: entering: key RSA comment ".ssh/id_rsa", 1 socket bindings, 1 constraints
debug3: identity_permitted: socketentry fd=4, entry 0 AUTH, from hostkey (ORIGIN)  to user (ANY) hostkey ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g
debug2: permitted_by_dest_constraints: constraint 0 (ORIGIN) (0 keys) > git.sr.ht (3 keys)
debug3: match_key_hop: to: entering hostname git.sr.ht, requested key ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g, 3 keys avail
debug3: match_key_hop: to: key 0: ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g
debug2: permitted_by_dest_constraints: allowed for hostname git.sr.ht
debug2: process_request_identities: replying with 1 allowed of 1 available keys
debug1: process_message: socket 1 (fd=4) type 13
debug1: process_sign_request2: entering
debug3: parse_userauth_request: well formed userauth
debug1: process_sign_request2: user=git
debug3: identity_permitted: entering: key RSA comment ".ssh/id_rsa", 1 socket bindings, 1 constraints
debug3: identity_permitted: socketentry fd=4, entry 0 AUTH, from hostkey (ORIGIN)  to user git hostkey ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g
debug2: permitted_by_dest_constraints: constraint 0 (ORIGIN) (0 keys) > git.sr.ht (3 keys)
debug3: match_key_hop: to: entering hostname git.sr.ht, requested key ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g, 3 keys avail
debug3: match_key_hop: to: key 0: ED25519 SHA256:WXXNZu0YyoE3KBl5qh4GsnF1vR0NeEPYJAiPME+P09g
debug2: permitted_by_dest_constraints: allowed for hostname git.sr.ht
debug1: process_sign_request2: good signature

########### jj git clone, same repo
debug1: new_socket: type = CONNECTION
debug2: fd 4 setting O_NONBLOCK
debug1: process_message: socket 1 (fd=4) type 11
debug2: process_request_identities: entering
debug3: identity_permitted: entering: key RSA comment ".ssh/id_rsa", 0 socket bindings, 1 constraints
debug2: process_request_identities: replying with 1 allowed of 1 available keys
debug1: new_socket: type = CONNECTION
debug2: fd 4 setting O_NONBLOCK
debug1: process_message: socket 1 (fd=4) type 11
debug2: process_request_identities: entering
debug3: identity_permitted: entering: key RSA comment ".ssh/id_rsa", 0 socket bindings, 1 constraints
debug2: process_request_identities: replying with 1 allowed of 1 available keys
debug1: new_socket: type = CONNECTION
debug2: fd 4 setting O_NONBLOCK
debug1: process_message: socket 1 (fd=4) type 11
debug2: process_request_identities: entering
debug3: identity_permitted: entering: key RSA comment ".ssh/id_rsa", 0 socket bindings, 1 constraints
debug2: process_request_identities: replying with 1 allowed of 1 available keys
debug1: cleanup_socket: cleanup

And then, in the other terminal:

$ export SSH_AGENT_PID=897184

$ export SSH_AUTH_SOCK=/tmp/ssh-XXXXXXOwhxAa/agent.897184

$ ssh-add -L
The agent has no identities.

$ ssh-add -h git.sr.ht .ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)

$ git clone git@git.sr.ht:~ser/stmp
Cloning into 'stmp'...
X11 forwarding request failed on channel 0
remote: Enumerating objects: 244, done.
remote: Counting objects: 100% (244/244), done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 244 (delta 143), reused 244 (delta 143), pack-reused 0
Receiving objects: 100% (244/244), 93.37 KiB | 1.10 MiB/s, done.
Resolving deltas: 100% (143/143), done.

$ rm -rf stmp

$ jj git clone git@git.sr.ht:~ser/stmp
Fetching into new repo in "/home/ser/stmp"
Error: Fetch failed: Failed to retrieve list of SSH authentication methods: Failed getting response; class=Ssh (23); code=Auth (-16)

I'm by no means an expert at parsing ssh-agent logs, but it appears that the jj git requests a key and receives one. ssh-agent says there's no socket connection (and, so, how is libssh2 communicating with it? But it obviously is), and there's no sign request like there is from git.

What I don't understand is that everything else that uses SSH works. I am regularly connected via ssh or mosh to four different machines on my LAN and three VPNs on other people's computers. I git clone, pull and push from github and Sourcehut, and hg clone and push to Sourcehut. The only thing that fails is jj git commands to Sourcehut.

I have jj installed on my laptop as well, and it also fails, with the same error. I know that this has worked in the past on that machine, but also with some fiddling to rebuild with(out?) vendored libssl2, but I've upgraded it since. On my laptop, it's jj 0.6.0, and on my desktop 0.7.0.

Both machines using the same private keys. Both are Arch-based (one is Artix, the other EndeavourOS). In both cases, jj was installed with the cargo install --git ... command. On both machines, I can jj git clone repos from github (using the private key & the git@github source), but can not clone from Sourcehut.

Git, by itself, always works. I have no problems with any SSH communications with any hosts, Sourcehut or otherwise, except jj git. The only thing I need for git is my private key; you don't need ssh-agent because git will ask for the password to the key, and it'll also fetch and store the remote key. The bare minimum in a container will be: git, and my private key. I'll go ahead and verify that, but I don't know what this will tell me.

xxxserxxx commented 1 year ago

So, to try the "really-truly" isolated approach, I tried in an Alpine container. I'm trimming liberally for brevity, but the punchline is that jj segfaults when trying to do a clone.

I'm running a container that's sharing the key via a mount; the minimum to get git working was pretty minimal:

$ mkdir container-ssh
$ cp .ssh/id_rsa .ssh/id_rsa.pub container-ssh
$ podman run -it --rm -v $PWD/container-ssh:/root/.ssh docker.io/library/alpine:latest /bin/sh
# cd ~
# apk add git openssh
...
# eval $(ssh-agent)
# ssh-add .ssh/id_rsa
...
# git clone git@git.sr.ht:~/stmp
... (Success)
# rm -rf stmp

To get jj running was a bit more work; rustup was required because the Alpine package's rustc is 1.60, and the jujutsu build requires 1.64. Compressing a fair bit of trail and error, it needed 5 more packages. FWIW, not only does the ssh clone from sr.ht segfault, but https clone from github does as well.

# apk add rustup build-base pkgconfig openssl openssl-dev
...
# rustup-init -y
...
# cargo install --git https://github.com/martinvonz/jj.git --bin jj jujutsu
...
   Compiling jujutsu v0.7.0 (/root/.cargo/git/checkouts/jj-1467e3dd78fc324a/2a87e1f)
    Finished release [optimized] target(s) in 4m 41s
  Installing /root/.cargo/bin/jj
   Installed package `jujutsu v0.7.0 (https://github.com/martinvonz/jj.git#2a87e1f9)` (executable `jj`)
# jj version
0.7.0
# jj git clone git@git.sr.ht:~ser/stmp
Segmentation fault
# jj git clone https://github.com/xxxserxxx/stmp
Segmentation fault

I installed strace but the failure point means nothing to me:

# strace jj git clone https://github.com/xxxserxxx/stmp
...
stat("/etc/ssl/certs", {st_mode=S_IFDIR|0755, st_size=13488, ...}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f34ef756b06}, NULL, 8) = 0
rt_sigreturn({mask=[]})                 = 140725235409168
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++
Segmentation fault

xelxebar commented 1 year ago

@xxxserxxx As @yuja points out, it looks like you're using an RSA key. The only salient difference I can see between your setup and mine at this point is that I'm using ed-25519.

xxxserxxx commented 1 year ago

@xelxebar I think you're right. At least, that's my pet theory: it's the private key itself. If it's true, though, then that indicates a bug in libssl2, right? Or, possibly, libssl2 is technically correct and openssl is wrong (I'm guessing everything else in my toolchain, and on Github, Gitlab, and Sourcehut, uses openssh and openssl).

I'll try a different key; changing it on sr.ht won't be too much of a PITA. However, if this is a bug in libssl2 I'm going to have to drop it; I don't program in Rust and feel unqualified to file a coherent ticket. While I keep mentioning libssl2, it's only because of other references made in various tickets about issues with it.

xxxserxxx commented 1 year ago

I've confirmed that jj will not successfully clone from Sourcehut using RSA keys. It does work if using ed25519. From other tickets, it appears that the SSL key can be RSA neither on the client, nor on the server.

yuja commented 1 year ago

If it's true, though, then that indicates a bug in libssl2, right?

Correction: libssh2

I suspect it's a bug of libgit2 (and/or missing feature of libssh2.) As I explained in #389, libgit2 (which uses libssh2 under the hood) has some problem in host key exchange. I guess libgit2 would have a similar shortcoming in authentication process.

martinvonz / jj