#Private git repos with SSH not working, ssh-agent is configured

1 messages · Page 1 of 1 (latest)

grim spade
#

I'm trying to setup a private dagger module monorepo, and when I pushed the repository then try to call it, I always get permission

I've made sure the ssh-agent is up and running, and SSH_AUTH_SOCK is set, and the key is added with ssh-add, if I run normal ssh -T HOSTNAME I get logged in, if I add vvv for verbosity I can see that it's authenticating with agent forwarding

...
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-req@openssh.com confirm 0
...

Now another thing is if I go back to v0.9 cookbooks and take one of the private repository examples, it doesn't work there either
https://archive.docs.dagger.io/0.9/cookbook#access-private-git-repository

Even if I try to use a "public" repository under the private instance using ssh and remove the socket part, I keep getting could not read from remote repository error
if I change the above cookbook to use https instead and remove ssh agent part with it works

So is there any way where I can get more logs from dagger's ssh connection attempt?

Filesystem

#

Private git repos with SSH not working, ssh-agent is configured

grim spade
#

few updates

  1. turns out the instance had issues with ssh connections, lucky timing
  2. the old style dagger code with mounting ssh socket worked, but only after I also added the known hosts string
  3. dagger -m is still giving me issues

But one thing I noticed is that in the logs it writes
Error: failed to get configured module: failed to get module ref kind: input: moduleSource resolve: failed to resolve git src to commit: failed to load cache key: error fetching default branch for repository ssh://xxxxx@instance/project.git

However our instance uses non default ssh port, could that cause an issue?
And does dagger module side of code know how to scan the host for known keys?

radiant obsidian
#

@pseudo needle

pseudo needle
grim spade
#

it's in this fashion
ssh://git@private-gitlab-instance.com:non-default-port/group/project.git

grim spade
#

yeah I think it is a port issue, to confirm this, I took the example above, and just removed the key from the agent, this time I get failed to fetch remote ssh://git@private-gitlab-instance.com:non-default-port/group/project.git
fatal: could not read from remote repository

here in the error I can see the port

now if i run with dagger -m it seems to use the default port no matter what, since I would get a similar message "failed to fetch remote" but this time the non-default-port is not mentioned anywhere

pseudo needle
#

Hey it is the port you're right

#

We don't parse it properly at the ref level atm 🙏 Adding that to my todo

#

Last thing: what is the format of this known hosts string, please ?

#

Bumping this priority on my todo, might have some cycles to check during this weekend 🙏

grim spade
#

for known hosts string format i ran ssh-keyscan -p non-default-port private-gitlab-instance.com
then took the one with rsa key type, i'm not sure if there's a way to add multiple known hosts
[private-gitlab-instance.com]:non-default-port ssh-rsa bunch_of_base64_stuff_for_keys

i figured the format after searching for references for it and ended up in some test case about it

grim spade
#

Hi, are there any updates in this regard?

pseudo needle
# grim spade Hi, are there any updates in this regard?

Hey @grim spade,
I isolated the issue and made a repro this weekend ; didn't have the time to finish it this weekend. Probably won't be able this week as I'm focusing on merging the PAT support, but can resume this weekend 👼