failed to authenticate SSH session

[stacyharper]

Description

I'm not sure what I did wrong here. But I also encountered this on another machine. So maybe something is wrong?

The repo here is hosted on git.sr.ht. Also, I note that I am not asked for my ssh passphrase, while ssh -F /dev/null [email protected] does.

Remotes are:

$ git remote -v
origin	[email protected]:~stacyharper/dotfiles (fetch)
origin	[email protected]:~stacyharper/dotfiles (push)
$ jj git remote list
origin [email protected]:~stacyharper/dotfiles

Steps to Reproduce the Problem

1. Just push

Expected Behavior

It pushs correctly

Actual Behavior

It fails with this error

$ jj git push
Branch changes to push to origin:
  Move forward branch master from 81814485b3b3 to e8ba7c520132
Error: failed to authenticate SSH session: Unable to extract public key from private key file: Wrong passphrase or invalid/unrecognized private key file format; class=Ssh (23)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work?

Specifications

• Platform: alpine linux
• Version: 0.21.0

Complementary

I can git push, a vanilla way:

$ jj
@  zzqxtwpu [email protected] 2024-09-17 09:46:56 e601c582
│  (empty) (no description set)
○  klzwoxvq [email protected] 2024-09-17 09:46:39 master* HEAD@git e8ba7c52
│  bin: new diffd to diff edit directories
◆  ltowlwsu [email protected] 2024-09-13 15:39:29 master@origin 81814485
│  Less spam please
~
$ git log origin/master^..HEAD
e8ba7c52 bin: new diffd to diff edit directories Willow Barraco (HEAD, master) 2024-09-17 09:46
81814485 Less spam please Willow Barraco (origin/master, origin/HEAD) 2024-09-13 15:39
$ git push origin master 
Enter passphrase for key '/home/stacy/.ssh/id_rsa': 
Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Delta compression using up to 12 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 1.67 KiB | 1.67 MiB/s, done.
Total 7 (delta 4), reused 3 (delta 0), pack-reused 0 (from 0)
To git.sr.ht:~stacyharper/dotfiles
   81814485..e8ba7c52  master -> master

[essiene]

$ git push origin master
Enter passphrase for key '/home/stacy/.ssh/id_rsa':

Looking at the log of the successfull git push, it looks like the SSH key is an rsa ssh key.

The last time I ran into something like this, that turned out to be the problem and the error message and hint were both wrong.

Would it be possible for you to try out an ed25519 key, just to rule that out? They can be created with $ ssh-keygen -t ed25519.

if that doesn't work, I'll see if I can try to repro this locally.

[essiene]

Hmmmm, I found a similar problem with cargo-generate[1]. It seems the problem is because the private key file was passwd protected. Maybe you could try with a non-passwd protected file or use ssh-agent[2]. jj can work with keys loaded into the agent.

If that turns out to be the problem, we can probably add another hint.

[1] - cargo-generate/cargo-generate#470
[2] - https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#adding-your-ssh-key-to-the-ssh-agent

[stacyharper]

The fetch works after the initial unlock from vanilla git:

$ jj git fetch
Error: failed to authenticate SSH session: Unable to extract public key from private key file: Wrong passphrase or invalid/unrecognized private key file format; class=Ssh (23)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work?
$ git fetch 
Enter passphrase for key '/home/stacy/.ssh/id_rsa': 
$ jj git fetch
Nothing changed.

So I guess the problem come with the passphrase.

[essiene]

As a workaround you can use either use password less ssh certs or use ssh-add to add the keys to ssh-agent, then jj will work well with keys in the agent.

For a workaround, I guess we could add a hint about passwd protected private key files as well.

For long term fix, we should probably optionally collect and pass in the passphrase, but I don't know a good way to detect if an ssh private key file is passwd protected, so this can be a pain.

@martinvonz @yuja may have ideas for a long term fix.

[yuja]

#3191 might help if ssh command tries hard to obtain tty.