Hello.
I need to manage multiple git identities on the same computer. For the vanilla git tool, and any tool that calls git, I can use env variables GIT_SSH_COMMAND, GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME and adding/removing keys to ssh-agent accordingly.
However, for git-bug, I have an error which I suspect comes from that situation:
$ git pull
Everything up-to-date
$ git bug pull
Fetching remote ...
Error: repository not found
Do you have an idea of the reason of the issue?
Best,
github-actions (github-actions) commented
This bot triages untriaged issues and PRs according to the following rules:
After 90 days of inactivity, the lifecycle/stale label is applied
After 30 days of inactivity since lifecycle/stale was applied, the issue is closed
Hey, I still have the issue. Not sure why github-actions would think the problem is "stale" or "rotten".
sudoforge commented
hey @MartyLake, apologies for the lack of a reply here -- i came on as a maintainer in the middle of last year and have been (slowly) ramping up since then.
i'm going to need a little more information from you in order to be able to reproduce your issue.
can you confirm that:
your git remote is a fully qualified ssh uri
you have ssh-agent running and your key added
you can git-push to that remote without issue
you encounter this issue with git bug push, without changing any of the above
Fetching remote ...
Error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Not sure if related though.
sudoforge commented (edited)
hmm. i recreated the workflow you provided:
➜ cd $(mktemp -d)
➜ gh repo create --private git-bug-1139
✓ Created repository sudoforge/git-bug-1139 on GitHub
https://github.com/sudoforge/git-bug-1139
➜ git init
Initialized empty Git repository in /tmp/tmp.nL3ryY0Ev3/.git/
➜ git commit --allow-empty -m 'initial commit'
[trunk (root-commit) 5450d59] initial commit
➜ git remote add origin git@github.com:sudoforge/git-bug-1139.git
➜ git push -u origin trunk
Enumerating objects: 2, done.
Counting objects: 100% (2/2), done.
Writing objects: 100% (2/2), 343 bytes | 343.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To github.com:sudoforge/git-bug-1139.git
* [new branch] trunk -> trunk
branch 'trunk' set up to track 'origin/trunk' by rebasing.
➜ git bug version
git-bug version: v0.8.1
this is a pretty standard approach for creating a github repository and pushing to it, proving that SSH works. neat, but a bit rote.
next, you ran git-bug-pull. this is actually not valid; you first need to have a local git-bug identity configured, which is actually a bit of an issue if you have an identity in the remote and are expecting to be able to pull seamlessly -- see #1003 for more info.
with an identity configured, git-bug-pull completes without error for me (there is nothing to pull from this new repository, but it hits the remote and exits without error).
if you don't have an identity set, but the actual communication with the remote works, you'd get these error messages (which are a bit repetitive, this needs to fail faster, probably):
➜ git bug pull
Building cache...
Fetching remote ...
already up-to-date
Merging data ...
No identity is set.
To interact with bugs, an identity first needs to be created using "git bug user new" or adopted with "git bug user adopt"
: merge error: No identity is set.
To interact with bugs, an identity first needs to be created using "git bug user new" or adopted with "git bug user adopt"
No identity is set.
To interact with bugs, an identity first needs to be created using "git bug user new" or adopted with "git bug user adopt"
: merge error: No identity is set.
To interact with bugs, an identity first needs to be created using "git bug user new" or adopted with "git bug user adopt"
so, the fact that you're getting:
Error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
leads me to believe that you have something bespoke to your environment that is non-standard, that's messing with your ssh configuration. that said, i'm happy to help you debug this, as it could be that git-bug isn't supporting some git-config or ssh feature that it probably should.
on that same repository (or a new one created with the same steps), can you run:
echo "SSH_AUTH_SOCK: ${SSH_AUTH_SOCK}" (or just tell me if you are using openssh or gpg-agent)
additionally, if you have any custom ssh configuration for github.com in ~/.ssh/config, copy and paste that.
PLEASE BE SURE TO REDACT ANYTHING YOU CONSIDER TO BE PRIVATE OR SENSITIVE. doing so without removing the context around what the value is would be greatly appreciated.
unfortunately, there isn't anything i can see that indicates custom configuration that would potentially lead to an issue with git-bug. i have (effectively) the same exact configuration, save for a insteadOf directive that rewrites git@github.com: to the fully-qualified ssh://git@github.com/ -- but in my earlier comment, the test was performed with this disabled.
i also use gpg-agent as ssh-agent, and if my key is not cached when i run git-bug-pull, i'm prompted to enter my passphrase -- if my key is cached, the cache entry is used and i authenticate successfully to the remote.
i'm at a bit of a loss as to why you are experiencing this issue. these next suggestions may be a bit more involved, but would help validate (or provide steps to reproduce) your issue. i'll provide some reproducible steps below.
i'd recommend doing this in a container to provide a decent level of isolation. i'll provide instructions to use a nix container image so that the git-bug binary can be built with the same tools this repository uses (at least for development), and improves the reproducibility factor.
git-bug currently fails if SSH_AUTH_SOCK isn't set (related: #1023)
eval "$(ssh-agent -s)"
add the temporary key to the agent
ssh-add
AHA! i think i discovered your issue. continue these steps, but read after the break below.
attempt to pull from the remote
git bug pull
expected output for this is simply:
Fetching remote ...
already up-to-date
Merging data ...
with nothing else (assuming you have no git-bug objects in the remote repo). this indicates a successful read of the remote repository.
was this reproducible for you?
clean up
exit the container
delete the read-only deploy key from your repository
optional: remove the image: podman rmi ghcr.io/nixos/nix:latest
aha!
as indicated above, i think i discovered the issue you're experiencing. initially, i ran git bug pull after starting the agent (without adding the key). this reproduced the error you're seeing:
git clone worked, but that's because git is a lot smarter than go-git, which is the library that git-bug uses for git operations. i think we'll find that on the machine you've been running the tests on, your key isn't added to your agent.
you can check this:
ssh-add -L
what you'd see if this assumption is correct, is:
The agent has no identities.
[!NOTE]
alternatively, you might actually see some output here indicating you have one or more keys added, but if you do, none of them have access to your repo
given that you're using gpg-agent in ssh-agent mode, i'll ask a couple follow-up questions to confirm this assumption:
if the authentication key you're using is a gpg authentication subkey, have you added the keygrip to ~/.gnupg/sshcontrol?
if the authentication key you're using in an ssh key, are you sure you see it when running ssh-add -L?
sudoforge commented
hey @MartyLake - have you had a chance to run through that test yet? i think we'll find that your key wasn't added to the agent (and for whatever reason you aren't getting prompted to add it). i'm working on the lower level transport issues, and want to make sure you haven't hit an unknown issue with how ssh is currently implemented.
github-actions (github-actions) commented