Open FineTralfazz opened 2 years ago
Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey. Please be sure to review our Code of Conduct. Also, check out some of our community resources including:
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!
Does it work without the @openssh.com
or is this some non-standard implementation that needs it?
It's not clear why the regex is written like that. I'd use something like
^(((?P<options>\S+)\s)?(?P<enc>\S+)\s)?(?P<key>[0-9A-Za-z/+=]+)(\s(?P<comment>.+))?$
I just tested and it only works with the @openssh.com suffix. This is a key type that was added about two years ago to support U2F/FIDO keys (more info here) and my guess is that the current implementation in OpenSSH-specific rather than part of a standard, so they added a suffix to denote that.
It looks like providing a source
with multiple keys has bugs of its own, as it calls set_auth_key_from_file
with the whole file for every line, depending on whether there are options.
This should have been fixed along with #59429 by #60128
It seems that this does still not work as of v3005, at least for sk-ssh-ed25519@openssh.com
It also fails with - names
instead of - source
. In the names-code-branch the same regexes are use again, but without @.
next to the \w
.
Note that the duplicate #64723 issue mentions a couple points where a fix could be applied, including a couple suggested regexp changes
I tried to reproduce the problem with the content provided by @FineTralfazz and the missing key now appears in the file. is already this fixed? or not how can I reproduce it?
Description When using a key with a type containing
@
or.
the regex doesn't correctly capture the key, so it doesn't end up on the target.Setup SLS file:
Contents of
salt://configs/authorized_keys
:The file that gets dropped on the target hosts:
Steps to Reproduce the behavior ^ Use that SLS and authorized_keys file.
Expected behavior The whole file is added to the target hosts.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.) ``` Salt Version: Salt: 3004 Dependency Versions: cffi: Not Installed cherrypy: Not Installed dateutil: 2.7.3 docker-py: Not Installed gitdb: 2.0.6 gitpython: 3.0.7 Jinja2: 2.10.1 libgit2: Not Installed M2Crypto: Not Installed Mako: Not Installed msgpack: 0.6.2 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: Not Installed pycrypto: Not Installed pycryptodome: 3.6.1 pygit2: Not Installed Python: 3.8.10 (default, Sep 28 2021, 16:10:42) python-gnupg: 0.4.5 PyYAML: 5.3.1 PyZMQ: 18.1.1 smmap: 2.0.5 timelib: Not Installed Tornado: 4.5.3 ZMQ: 4.3.2 System Versions: dist: ubuntu 20.04 focal locale: utf-8 machine: x86_64 release: 5.4.0-88-generic system: Linux version: Ubuntu 20.04 focal ```Additional context I played around with the regex in
ssh_auth.py
and I think changing it to^(.*?)\s?((?:sk-)?(?:ssh\-|ecds)[@\.\w-]+\s.+)$
would fix the problem. But I'm not familiar enough with the codebase to confidently submit a PR, so I'm hoping an active contributor can confirm and fix it.