SSH CA cert feature SAT-28038

[lhellebr]

No description provided.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• In register_host, lce and cv are treated as objects with .id attributes but are initialized from cli_factory helpers (which usually return dict-like data); consider consistently using either dict keys or attributes (e.g. lce['id'] / cv['id']) to avoid type/attribute mismatches.
• The three test_positive_ssh_ca_* tests share substantial setup and assertion logic (CA creation, host registration, invocation, and log checks); consider extracting common helpers/fixtures to reduce duplication and make intent clearer.
• When constructing InstallerCommand for foreman_proxy_plugin_remote_execution_script_ssh_host_ca_public_key, you wrap the certificate value in extra quotes (f'"{host_ca_cert}"'); consider passing the raw value and letting InstallerCommand handle quoting to avoid subtle shell-escaping issues.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `register_host`, `lce` and `cv` are treated as objects with `.id` attributes but are initialized from `cli_factory` helpers (which usually return dict-like data); consider consistently using either dict keys or attributes (e.g. `lce['id']` / `cv['id']`) to avoid type/attribute mismatches.
- The three `test_positive_ssh_ca_*` tests share substantial setup and assertion logic (CA creation, host registration, invocation, and log checks); consider extracting common helpers/fixtures to reduce duplication and make intent clearer.
- When constructing `InstallerCommand` for `foreman_proxy_plugin_remote_execution_script_ssh_host_ca_public_key`, you wrap the certificate value in extra quotes (`f'"{host_ca_cert}"'`); consider passing the raw value and letting `InstallerCommand` handle quoting to avoid subtle shell-escaping issues.

## Individual Comments

### Comment 1
<location> `tests/foreman/destructive/test_remoteexecution.py:249-148` </location>
<code_context>
+    )
+
+
+def log_compare(satellite, host):
+    return host.execute(
+        f'[ $(( $(cat /root/saved_sshd_log) + 1 )) -eq $(journalctl -u sshd | grep {satellite.ip} | grep " CA " | wc -l) ]'
+    ).status
+
+
</code_context>

<issue_to_address>
**suggestion:** Clarify and/or assert more explicitly what `log_compare` is checking to avoid fragile log-count based assertions

This helper assumes `journalctl | grep {satellite.ip} | grep " CA " | wc -l` increases by exactly 1 between `log_save` and the job run, which is brittle: concurrent SSH activity in shared environments can match the same pattern, and log rotation/truncation can change counts independently of this test.

Please consider either matching a more specific pattern (e.g., including a unique test-run identifier) or parsing `journalctl` output and asserting that at least one new relevant line appears, rather than enforcing an exact count change. If you keep this approach, add a brief comment showing the expected `sshd` log line so the dependency is explicit.

Suggested implementation:

```python
def log_save(satellite, host):
    # We track sshd log entries for CA-based publickey auth from the satellite IP.
    # Expected log line (simplified example):
    #   "Accepted publickey for <user> from <satellite_ip> ... ssh2: RSA-CERT ID ... CA ..."
    host.execute(
        f'journalctl -u sshd | grep "{satellite.ip}" | grep "Accepted publickey" | grep " CA " | wc -l > /root/saved_sshd_log'
    )

```

```python
def log_compare(satellite, host):
    """Check that at least one new CA-based sshd log entry appears for the satellite since log_save().

    Compares the current count of sshd log lines matching:
        satellite.ip + "Accepted publickey" + " CA "
    with the count stored by log_save(). Returns the exit status of the check command
    (0 for success, non-zero for failure).
    """
    return host.execute(
        f'[ $(journalctl -u sshd | grep "{satellite.ip}" | grep "Accepted publickey" | grep " CA " | wc -l) -gt $(cat /root/saved_sshd_log) ]'
    ).status


from robottelo.config import get_credentials

```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[lhellebr]

Ready but:

1. feature not merged
2. can't run PRT or even local tests due to 1)

Feel free to review but do not merge yet.

[lhellebr]

TODO: provisioning coverage (possibly in a separate PR) once I get access to provisioning infra

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The test_execution helper returns the result of satellite.cli.JobInvocation.info, which in other tests is treated as a dict (result['success']), but in test_positive_ssh_ca_sat_only you assert result.status == 0; this inconsistency is likely a bug and should be aligned to a single, correct return type/usage.
• There is a lot of duplicated shell command and path logic (e.g., repeated ssh-keygen invocations, restorecon/chown/chgrp sequences, and path string munging with split('/')) across fixtures and tests; consider extracting small reusable helpers to reduce duplication and make the setup steps easier to read and maintain.
• Functions like log_compare return a bare .status integer and the tests then compare that to 0/!=0, which makes the intent a bit opaque; wrapping this in a boolean-returning helper (e.g., used_ca_authentication(host, sat) -> bool) would make the assertions more self-explanatory.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `test_execution` helper returns the result of `satellite.cli.JobInvocation.info`, which in other tests is treated as a dict (`result['success']`), but in `test_positive_ssh_ca_sat_only` you assert `result.status == 0`; this inconsistency is likely a bug and should be aligned to a single, correct return type/usage.
- There is a lot of duplicated shell command and path logic (e.g., repeated `ssh-keygen` invocations, `restorecon/chown/chgrp` sequences, and path string munging with `split('/')`) across fixtures and tests; consider extracting small reusable helpers to reduce duplication and make the setup steps easier to read and maintain.
- Functions like `log_compare` return a bare `.status` integer and the tests then compare that to 0/!=0, which makes the intent a bit opaque; wrapping this in a boolean-returning helper (e.g., `used_ca_authentication(host, sat) -> bool`) would make the assertions more self-explanatory.

## Individual Comments

### Comment 1
<location> `tests/foreman/destructive/test_remoteexecution.py:281` </location>
<code_context>
+    register_host(sat, host)
+    result = test_execution(sat, host)
+    # assert the run actually happened and it was authenticated using cert
+    assert result.status == 0
+    logger.debug(result)
+    assert log_compare(sat, host) == 0
</code_context>

<issue_to_address>
**issue (bug_risk):** JobInvocation result is treated as an object with `.status` but other tests use it as a dict, which is likely to break this test

Here `test_execution` returns `satellite.cli.JobInvocation.info(...)`, which is treated elsewhere in this file as a dict (`result['success'] == '1'`). Using `result.status` is inconsistent and may raise an `AttributeError` or behave incorrectly. Please align with the other tests and assert on the appropriate dict fields (e.g. `result['success']` and/or `result['overall']`) instead of `.status`.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): JobInvocation result is treated as an object with .status but other tests use it as a dict, which is likely to break this test

Here test_execution returns satellite.cli.JobInvocation.info(...), which is treated elsewhere in this file as a dict (result['success'] == '1'). Using result.status is inconsistent and may raise an AttributeError or behave incorrectly. Please align with the other tests and assert on the appropriate dict fields (e.g. result['success'] and/or result['overall']) instead of .status.