dustin/sshca-cli/pipeline/head This commit looks goodDetails
The _sshca-cli-systemd_ package was intended for machines to
automatically get signed SSH host certificates on first boot. Having
the systemd unit files in an RPM package allowed them to be installed by
Anaconda, without needing custom post-install scripts or Ansible.
Unfortunately, various issues prevented this from actually working as
intended most of the time, and with the new webhook-based automatic
provisioning process, it's not really necessary. I'm thus removing the
sub-package that contained the unit files and moving them to the Ansible
configuration policy.
Now that there are several production workloads on the Raspberry Pi
cluster, we don't want intense jobs like this running on them. To
ensure this job runs on a dedicated node, we need to use a label
expression that matches the appropriate nodes.
dustin/sshca-cli/pipeline/head This commit looks goodDetails
The RPM build tools in Fedora 41 apparently require `gdb` but don't
declare that:
> find-debuginfo: starting
> Extracting debug info from 1 files
> gdb-add-index: Failed to find a useable GDB binary
dustin/sshca-cli/pipeline/head There was a failure building this commitDetails
Apparently, `dnf5` differs from `dnf` in that it does not ignore the
trailing `--` argument:
> Unknown argument "--" for command "install". Add "--help" for more
> information about the arguments.
dustin/sshca-cli/pipeline/head This commit looks goodDetails
Since the *openidconnect* dependency was added before the
`native-tls`/`rustls` features, it was hard coded to use native TLS.
This needs to be conditional based on the application's selected TLS
feature.
dustin/sshca-cli/pipeline/pr-master There was a failure building this commitDetails
dustin/sshca-cli/pipeline/head This commit looks goodDetails
An SSH certificate is useless on its own, as without the private key,
clients cannot sign servers' authentication requests. Since `sshca-cli
user login` creates a new key pair each time it is run, the private key
needs to be kept at least as long as the certificate is valid. To that
end, the command will now add both to the user's SSH agent. It
communicates with the agent via the UNIX stream socket specified by the
`SSH_AUTH_SOCK` environment variable.
Although there is a Rust crate, [ssh-agent-client-rs][0] that implements
the client side of the SSH agent protocol, it does not support adding
certificates to the agent. In fact, that functionality is not even
documented in the IETF draft specification for the protocol. Thus, I
had to figure it out by reading the code of the OpenSSH `ssh-add` tool,
and observing the messages passed between it and `ssh-agent`.
[0]: https://crates.io/crates/ssh-agent-client-rs
The `sshca-cli user login` command now requests a signed certificate
from the SSHCA server. Given a valid OpenID Connect identity token and
an SSH public key, the server will return a signed certificate, valid
for a predetermined (usually short) period of time. The principals
listed in the certificate are derived from the ID token.
dustin/sshca-cli/pipeline/head This commit looks goodDetails
In addition to building an RPM package for regular Fedora machines, we
now build a container image containing a statically-linked `sshca-cli`
executable.
The `rustls` feature will enable building with [rustls] instead of
OpenSSL. This will make it so the `sshca-cli` binary can be statically
linked, and thus distributable as a single file.
[rustls]: https://github.com/rustls/rustls
dustin/sshca-cli/pipeline/head This commit looks goodDetails
The cloud aarch64 build machine does not have enough resources to build
multiple versions at once. Requesting multiple CPUs ensures that only
one build pod is scheduled at a time. Since the node has 2 CPUs and
240m CPUs are taken by Longhorn, if we request 1500m CPUs, builds will
run sequentially.
The `sshca user login` command will eventually provide the command-line
interface for obtaining user SSH certificates. It initiates the OAuth2
login process, retreiving an OpenID Connect Identity Token from the
OpenID Server. This token will be submitted to the SSHCA server to
authorize a request to sign a certificate. For now, though, the token
is printed to standard output, e.g. to be used in a `curl` request.
The `get_sshca_server_url` function encapsulates the logic of
identifying the URL of the SSHCA server. For now, it only considers the
`SSHCA_SERVER` environment variable, but eventually, it will also
support other configuration methods like a configuration file. Moving
this to a separate function will allow other areas of the code to share
the same logic.
When running a debug build, the `sshca host sign` command will now check
the `SSHCA_CLI_DEBUG_TEST_MACHINE_ID` environment variable for the value
to use as the machine ID. This is useful during development and
testing, where the real machine ID is inaccessible or otherwise
unavailable.
The `SSHCA_CLI_DEBUG_TEST_MACHINE_ID` environment variable is *NOT* used
at all in release builds.
dustin/sshca-cli/pipeline/head This commit looks goodDetails
When this repository was split from the original *dustin/sshca*
repository, the CI pipeline was not imported. It wouldn't have mattered
if it had been, since it wouldn't have worked, anyway, given the path
changes.
The `/sys/firmware/devicetree/base/serial-number` pseudo-file has a
trailing null byte, which causes `Uuid::parse_srr` to fail. This makes
it impossible to authenticate Raspberry Pi devices to the server. The
trailing byte needs to be removed before attempting to parse the serial
number into a UUID to avoid this problem.
The *ssh-host-cert-sign@.service* unit does what it says on the tin:
requests a signed host certificate from an SSHCA server. It is a
template unit, whose instances correspond to SSH key types (RSA, ECDSA,
and Ed25519). The *ssh-host-certs.target* unit depends on the three
instances of the template unit, so they can all be activated together.
This target is only activated on the first boot of the system, to
initially request the certificates.
The *ssh-host-certs-renew.timer* unit periodically renews the SSH hosts
certificates. Its corresponding target unit depends on the three
instances of *ssh-host-cert-sign@.service*, so each certificate will be
renewed independently.
The *sshca-cli* RPM package can be used to install the SSHCA CLI client
on Fedora (and other RPM-based distributions). The `.spec` file was
originally generated using [rust2rpm], but several manual modifications
were required. Notably, the script does not generate `BuildRequres`
tags when run in "vendored" mode (i.e. third-party crate sources are
included in the source RPM package instead of packaged as separate
RPMS).
The CLI tool will be the primary method for interacting with the SSH CA
service. For now, it supports a single operation: `sshca-cli host
sign`, which requests a certificate to be signed by the CA service.`