salt: gitfs(pygit2): gitea deploy keys fail

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

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Comments: 19 (1 by maintainers)

Most upvoted comments

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

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