Salt: gitfs(pygit2): gitea deploy keys fail

[CosmicToast]

Description of Issue

If salt's credentials have no global permissions on the server, but do have permissions to clone a specific directory, it will fail to authenticate.
An equivalent setup using GitPython has no such issues.

Setup

/etc/salt/master.d/fileserver.conf:

file_roots:
  base:
    - /srv/salt

gitfs_remotes:
  - git@server:namespace/repository.git

gitfs_privkey: /etc/salt/ssh
gitfs_pubkey: /etc/salt/ssh.pub

The above setup causes the following failure:

DATE [salt.utils.gitfs :1734][ERROR   ][PID] Error occurred fetching gitfs remote 'git@server:namespace/repository.git': Failed to authenticate SSH session: Callback returned error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/utils/gitfs.py", line 1712, in _fetch
    fetch_results = origin.fetch(**fetch_kwargs)
  File "/usr/lib/python2.7/dist-packages/pygit2/remote.py", line 405, in fetch
    check_error(err)
  File "/usr/lib/python2.7/dist-packages/pygit2/errors.py", line 64, in check_error
    raise GitError(message)
GitError: Failed to authenticate SSH session: Callback returned error

The following steps resolve the problem:

• uninstall pygit2 (making sure GitPython is installed)
• copy /etc/salt/ssh to ~/.ssh/id_rsa and /etc/salt/ssh.pub to ~/.ssh/id_rsa.pub
• comment gitfs_privkey and gitfs_pubkey keys in fileserver.conf

Note that the keys, repository, etc remain unchanged.
Similarly, loading the key into an ssh-agent and using the command line git clones successfully as well.

With that setup, gitfs is added (and is usable) successfully.

Steps to Reproduce Issue

Gitea:

1. Install gitea
2. Create a private repository
3. Add salt's public key as a "Deploy Key" (giving it read-only access to that repository only)

Salt:

1. Set up salt as per above.
2. Launch salt-master.
3. Observe the error.
4. Perform the modifications mentioned above (minimal changes to switch to GitPython).
5. Launch salt-master
6. Observe the lack of an error

Versions Report

Salt Version:
           Salt: 2019.2.0

Dependency Versions:
           cffi: Not Installed
       cherrypy: unknown
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.8
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: 0.26.0
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.26.2
         Python: 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: Ubuntu 18.04 bionic
         locale: UTF-8
        machine: x86_64
        release: 4.15.0-50-generic
         system: Linux
        version: Ubuntu 18.04 bionic

[lae]

This happens with GitHub read-only deploy keys as well. (the workaround using gitpython works)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[lae]

not stale

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[Darkentik]

This happens with GitHub read-only deploy keys as well. (the workaround using gitpython works)

Hey, we have same error
"File "/usr/lib/python3/dist-packages/salt/utils/gitfs.py", line 1745, in _fetch | fetch_results = origin.fetch(**fetch_kwargs)".

Can you tell what workaround with gitpython should work?
We are using debian buster with saltstack 2019.2.3+ds-1 and python 3.7.3-1.

Thanks a lot!

[lae]

@Darkentik the workaround referenced there is the one documented in the first post.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[CosmicToast]

Still not stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[CosmicToast]

This issue is not stale. Why did the bot mark it as such again after another hour?

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[windowsrefund]

Still seeing this on 3000-1. The GitPython work-around is less than ideal though since attributes like privkey and pubkey are not supported. This makes interacting with multiple repos a PITA since hackery would be needed to assign keys to fake URLs by way of ~/.ssh/config

Surprised this issue isn't getting any love

[windowsrefund]

Worth noting is the fact that git_pillar_provider (buried deep in the docs) should be set to gitpython when using the work-around and attempting to read pillar data from git

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[CosmicToast]

still not stale

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.