Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Inconsistent use of args in ssh_auth.managed #64442

Closed
4 of 9 tasks
rittycat opened this issue Jun 9, 2023 · 2 comments
Closed
4 of 9 tasks

[BUG] Inconsistent use of args in ssh_auth.managed #64442

rittycat opened this issue Jun 9, 2023 · 2 comments
Assignees
Labels
Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around State-Module

Comments

@rittycat
Copy link
Contributor

rittycat commented Jun 9, 2023

Description
ssh_auth.managed does not fully respect arguments such as config, fingerprint_hash_type, options, etc

In particular, it will happily use all of the args available when making sure that keys are present, always putting new keys into their correct places. However, when determining what keys to remove or modify, it won't, always using the default ~/.ssh/authorized_keys file, and other such default options for ssh.auth_keys and ssh_auth.absent calls

Setup
Standard setup in v3005 or v3006. Doesn't matter if it's a VM, on-prem or anything else. It is linux-only, however

Please be as specific as possible and give set-up details.

  • on-prem machine
  • VM (Virtualbox, KVM, etc. please specify)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD
  • classic packaging
  • onedir packaging
  • used bootstrap to install

Steps to Reproduce the behavior
I originally spotted this bug while using a different config file, so!

  • Have some keys in ~/.ssh/authorized_keys
  • Make a state with ssh_auth.managed and specify a different path for config. Use one or more different keys to those you added to the default file
  • Apply the state. You'll find your new file is created correctly, but the keys you added to ~/.ssh/authorized_keys have been removed
  • Swap the keys in the state with some others
  • Apply the state again. This time you'll find that the keys originally in the state were never removed, and new keys have only been appended

Expected behavior
All functions called by ssh_auth.managed should respect arguments provided where applicable

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report
N/A, exists in v3005 and v3006's code. Haven't checked other releases

Additional context
Add any other context about the problem here.

@rittycat rittycat added Bug broken, incorrect, or confusing behavior needs-triage labels Jun 9, 2023
@Ch3LL Ch3LL added this to the Sulfur v3006.2 milestone Jun 9, 2023
@Ch3LL Ch3LL self-assigned this Jun 9, 2023
@Ch3LL Ch3LL added severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around and removed needs-triage labels Jun 9, 2023
@davama
Copy link

davama commented Aug 16, 2023

Was testing this and noticed this too

/root/.ssh/authorized_keys3:
  ssh_auth.manage:
    - user: root
    - source: salt://ssh_keys/all/root_authorized_keys3
    - config: '%h/.ssh/authorized_keys3'
    - ssh_keys:
      - ''

the above state removes any keys i have in /root/.ssh/authorized_keys
currently on v3006.2

@Ch3LL
Copy link
Contributor

Ch3LL commented Aug 25, 2023

Closed by #65046

@Ch3LL Ch3LL closed this as completed Aug 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around State-Module
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants