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
andgitfs_pubkey
keys infileserver.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:
- Install gitea
- Create a private repository
- Add salt’s public key as a “Deploy Key” (giving it read-only access to that repository only)
Salt:
- Set up salt as per above.
- Launch
salt-master
. - Observe the error.
- Perform the modifications mentioned above (minimal changes to switch to GitPython).
- Launch
salt-master
- 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)
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)