Remote SSH issue with Docker on Push: module 'pygit2.credentials' has no attribute 'GIT_CREDTYPE_SSH_KEY'

[tduval-unifylogic]

Hi! I am very interested in using the QuitStore!!

I have a git repository on a remote where I need to use id_rsa/ssh authentication and attemptign to perform a push and receive an attribute error: AttributeError: module 'pygit2.credentials' has no attribute 'GIT_CREDTYPE_SSH_KEY'

Not sure if this is a bug. I am assuming this is operator error where I am not configuring things properly for the container, and could use some help! I also figure there are others who have the same scenario and could benefit from a detailed explanation.

What has to be configured in order to get the ssh key to be recognized?

I have placed the following in the Dockerfile (and doing build before run) :

-- in builder section USER root RUN mkdir /root/.ssh/ RUN echo /Users/username/.ssh/id_rsa > /root/.ssh/id_rsa

-- in deploy section QUIT_SSH_KEY_HOME=/root/.ssh

Command used to start the container: docker run -d --name quitstore-esm -p 8080:8080 -v /path/to/repo:/data aksw/quitstore

[tduval-unifylogic]

@white-gecko

BTW, verified, there is a bug in the newest version of the code in git.py

GIT_CREDTYPE_SSH_KEY needs to be updated to GIT_CREDENTIAL_SSH_KEY and GIT_CREDTYPE_USERPASS_PLAINTEXT needs to be updated to GIT_CREDENTIAL_USERPASS_PLAINTEXT

Even though I am past this, I still need guidance on how to properly install id_rsa in docker container to get quitstore to work properly...thanks in advance!! we want to use the quit store in our semantic model curation product, so this is a big deal for us.

[white-gecko]

Are you up to having the key inside the container or are you using an auth agent?

Have you tried mounting your ssh agent path into the container and set the SSH_AGENT_SOCK in the container accordingly?

[tduval-unifylogic]

Yes, am actually moving key into container in Dockerfile. No, I haven’t tackled the second point and third points (good tip!)

Actually, given our need (to call QuitStore endpoints (including push, etc) from a microservice with managing changes to ontologies), I would really like to have the repo in the container rather than on the host.

We plan to host QuitStore as a service rather than the more ‘personal’ scenario it’s current configuration is designed for. Thinking repo ‘inside’ would eliminate the need for volume mapping/binding, reduce the complexity and increase flexibility of uses of the container?

Is this something you have tried? Any suggestions on how to configure for this scenario (besides git provisioning commands in Dockerfile)? Thinking outside the box, could dockering the binary/executable be an option to support our need?

BTW, I really enjoyed your paper on this subject. I had planned on building something similar for our product and it was great someone else saw the value of such a capability and brought it to life!

@white-gecko, any thoughts on this?

[xtsol-jcurtis]

@white-gecko

I've been working with @MartyStache on this issue and have discovered a bug related to defining the SSH_AUTH_SOCK in the dockerfile causing unreachable code in git.py.

Have a look at the conditional branch that handles whether the pygit2.KeypairFromAgent function or the pygit2.Keypair function is used: https://github.com/AKSW/QuitStore/blob/79dca0674c74aa21711d296b036fcb73dfd06257/quit/git.py#L819-L840

See the delcaration of the SSH_AUTH_SOCK environment variable in the Dockerfile code below: https://github.com/AKSW/QuitStore/blob/79dca0674c74aa21711d296b036fcb73dfd06257/Dockerfile#L68

I believe this environment variable definition should be left to the user that is running the docker container depending on the ssh authentication method they choose. Because SSH_AUTH_SOCK is defined in the container, the else statement that handles Keypair auth method is unreachable unless the environment variable is unset on container startup.

What is your preference on how new contributors create a pull request with a proposed solution?