teemtee
Adding validation for allowed SSH options or implementing safeguards against dangerous options
Related code:
https://github.com/teemtee/tmt/blob/dc9b82eb03ff47250c0f22f11ef89e31aba1dd23/tmt/steps/provision/init.py#L2327-L2338
Description: The current implementation of the ssh_option field within the provision step allows users to define arbitrary SSH options (passed directly to the ssh -o flag) within the FMF test plan metadata.
As noted by @LecrisUT during review #4275 , exposing raw SSH configuration via FMF is "very iffy" as it introduces potential security and design risks, including:
Security Vulnerability: Allowing arbitrary options could enable users to bypass security settings, potentially allowing remote code execution or unauthorized key usage if the FMF file is processed from an untrusted source. For example, options related to proxy commands or key file paths could be exploited.
Design Flaw (Separation of Concerns): Low-level protocol settings like ssh-option typically belong in system-level configuration (~/.ssh/config) or as command-line arguments, not embedded in portable test plan metadata (FMF).
This issue is a follow-up to address this fundamental design and security concern.
Proposed Action Items: 1.We need to implement safeguards to ensure the feature is secure and responsibly exposed to users. Restrict Allowed Options: Implement a whitelist of known-safe and necessary SSH options that can be defined in FMF (e.g., UserKnownHostsFile, StrictHostKeyChecking, Port). 2.Implement Blacklist/Safeguard: Block inherently dangerous options (e.g., those related to dynamic host configuration or command execution).
My main concern is not that we allow specific ssh options. If they want to pass them via the CLI, it is fine if they pass whatever.
The conern is that those are being hard-coded in the fmf file, which can be problematic on the testing-farm side because testing-farm should control those completely and on the secrets leaking side.
What I think we should discuss, and particularly with the users like @HouMinXi is if you really need to include any ssh-options in the fmf file. Could we instead offer more friendly interface to pass it via the CLI? What are the context that you need to override ssh options in general. Also if you could ping other interested parties of this discussion it would be appreciated
Hello @LecrisUT
Almost of our test scripts will use below ssh options
-o UserKnownHostsFile=/dev/null
-o StrictHostKeyChecking=no
-o StrictHostKeyChecking=accept-new
-o ConnectTimeout=3
These parameters are mainly to ensure a stable connection to the SSH server during the test, thereby reducing false failures caused by SSH connection issues.
Hmm, and you use them in the fmf file because otherwise the cli could get too complicated to invoke? Maybe we can expose allowing to pass a whole ssh-config file instead, although that would also require a cli option. The file could of course be setup locally and you wouldn't need to setup anything else. I wonder if there is any other interface that we could provide to simplify this.
Hello @LecrisUT
#Hmm, and you use them in the fmf file because otherwise the cli could get too complicated to invoke?
To be honest, one of the most important things is that we do not intend to make the TMT CLI extremely verbose. That's why I recommend YAML anchor and environment-file to define tmt plan.
Just like you say, if tmt can provide an interface to support such as an environment file to define ssh-config or source ssh-config from a specified file, I think that would also be a pretty good solution.
What about the ~/.ssh/config? If you do not want to pollute your common config file, we could maybe read from something under TMT_CONFIG_DIR=~/.config/tmt instead? @skycastlelily wdyt about pivoting #4291 to instead provide an ssh-config-file option with a default TBD according to the discussion here?
Hello @LecrisUT I think read from something under TMT_CONFIG_DIR=~/.config/tmt is a good option.
Just a clarification, what is your expectation on testing-farm. Do you expect to be allowed to edit the shh-options when running on testing-farm? Or do you only need it for running locally/in your own CI?