Closed xelxebar closed 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.)
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.
What's the remote's URL? Does git clone
from the same URL work? How about jj git clone
?
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.
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.
Unfortunately, that's not the culprit:
$ env | grep -Fi proxy || echo nope
nope
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.
Roger. I'll try to spin up a Rust dev env and see what I can find.
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.
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.
What if it's not the port? I tried again with Sourcehut, but it seems to still be broken.
Is there any chance of replacing libgit2? It seems to be having a remarkable number of issues.
@xxxserxxx It's hard to say without knowing specifics of your case.
ssh-agent
running?SSH_AUTH_SOCK
set correctly?ssh-add
?~/.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.
@xxxserxxx, see the update from @yuja in https://github.com/martinvonz/jj/issues/389#issuecomment-1473098558.
@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)
$
$ 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.)
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.
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.
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).
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
).
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.
@xxxserxxx I recommend doing some sanity checking yourself: E.g.
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.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
;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.
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.
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
@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
.
@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.
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.
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.
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:Sanity checks
Level 1
I am fairly sure my
ssh-agent
is running andSSH_AUTH_SOCK
is setup correctly:Level 2
But, just to be sure, I directly checked whether
jj
is actually trying to connect tossh-agent
Level 3
But since
SSH_AUTH_SOCK
was added in 4a1576c, I started to doubt my sanity, so I ranssh-agent -d
, which stays in the foreground and noisily shows when anyone connects. Running something likessh example.com
does cause it to generate connection logs; however, in the same shell as that workingssh
command, runningjj git fetch
errors out, andssh-agent
stays completely silent.Am I missing something obvious?
Version info
I am running the latest flake on
HEAD
: