Skip to content

Packaging for Fedora/CentOS/RHEL #24

@carlos-sarmiento

Description

@carlos-sarmiento

Is there an option to package/install this on Fedora and other RHEL based distros?

The old pam_ssh_agent_auth is getting deprecated in Fedora 42 and is already gone from CentOS 10 and RHEL 10.

Activity

nresare

nresare commented on Apr 10, 2025

@nresare
Owner

I would not be opposed to accepting an rpm packaging contribution, if anyone is willing. However, since I don't personally run any rpm-based distributions, I is pretty far down on my list of priorities to set up a test environment and figure out how to properly do rpm packaging these days

pbiering

pbiering commented on May 12, 2025

@pbiering
Contributor

I would be also strongly interested in, but unfortunatly, this was written in "Rust", and there is a statement: Fedora's packaging guidelines require it to be unbundled to package. Not 100% sure what this means, see also:

beldmit

beldmit commented on May 12, 2025

@beldmit

I think it means that you have to package each missing crate as a separate package. Don't know how many of them, BTW

neverpanic

neverpanic commented on May 12, 2025

@neverpanic

I would be also strongly interested in, but unfortunatly, this was written in "Rust", and there is a statement: Fedora's packaging guidelines require it to be unbundled to package. Not 100% sure what this means

It means that you will also have to package the dependencies (https://github.com/nresare/pam-ssh-agent/blob/main/Cargo.toml#L16-L24) before you can package this software, if they aren't packaged in Fedora yet.

Note that the posts you link to were written about https://github.com/z4yx/pam_rssh. It seems to be different implementation of the same idea, both written in Rust.

nresare

nresare commented on May 12, 2025

@nresare
Owner

Ok. I had a brief look at the packaging requirements, and it seems to me like most deps are already packaged (significantly rust-ssh-key), so this should be a pretty straight forward task. The one potential issue I sense from here is that there might be some work that needs to be done to either support old versions of dependencies or update those dependencies in Fedora

pbiering

pbiering commented on May 13, 2025

@pbiering
Contributor

For offline mode on F42 (and rawhide) following rust packages are missing

  • rust-pam-bindings+default-devel
  • rus-ssh-agent-client-rs+default-devel

I have now an initial spec file created which in online mode build successfully locally (should also work on COPR with Internet access enabled) - functionalwise to be tested still:

rpm -qlp pam_ssh_agent-0.5.1-1.fc42.x86_64.rpm
/usr/lib/.build-id
/usr/lib/.build-id/3b
/usr/lib/.build-id/3b/9cb870708f6af54576026645a2fc82e6a3290c
/usr/lib64/security/libpam_ssh_agent.so
/usr/share/doc/pam_ssh_agent
/usr/share/doc/pam_ssh_agent/README.md

Potentially missing rust dependencies need to be bundled in the source RPM until appearing in distro, are there already any hints around in other spec files?

AdmiralNemo

AdmiralNemo commented on May 13, 2025

@AdmiralNemo

Potentially missing rust dependencies need to be bundled in the source RPM until appearing in distro, are there already any hints around in other spec files?

Are you using rust2rpm? There's a section in a documentation that discusses how to "vendor" the dependencies in the RPM.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_vendored_dependencies

nresare

nresare commented on May 13, 2025

@nresare
Owner

Nice that you are making progress. ssh-agent-client-rs is my code, has a small set of dependencies, so it should be straightforward to package.

Please let me know if there are any changes that would be helpful to simplify packaging

pbiering

pbiering commented on May 13, 2025

@pbiering
Contributor

spec file for F42 is working, EL10 started, but got temporary stucked because of missing ssh-encoding, sure I found a solution next here...

https://github.com/pbiering/pam-ssh-agent/blob/rpm-specfile/contrib/pam_ssh_agent.spec

pbiering

pbiering commented on May 14, 2025

@pbiering
Contributor

Coming from Perl's CPAN "heaven", sucessfully sailed through Python's PyPI "purgatory", now entered the Rust's Crates "hell" :-(

Spec file enhanced, now able to build for F42, F43 and EL10 (ugly workarounds...but no other way to circumvent missing Rust dependencies)

https://github.com/pbiering/pam-ssh-agent/blob/rpm-specfile/contrib/pam_ssh_agent.spec

koji scratch builds for x86_64 are here until regular cleanup run:

successfully tested adding to /etc/pam.d/su and /etc/pam.d/sudo:
auth sufficient libpam_ssh_agent.so file=/root/.ssh/authorized_keys

A maintainer is required now for Fedora and EPEL incl. a new-package request.

BTW: what should happen with https://github.com/z4yx/pam_rssh - has one compared the implementation?

pbiering

pbiering commented on May 15, 2025

@pbiering
Contributor

Intermediate RPMs now are available for EL10/F42/F43 in my personal Fedora copr repository, currently based on my fork until this PR is merged.

https://copr.fedorainfracloud.org/coprs/pbiering/InternetServerExtensions/build/9046782/

See also
https://copr.fedorainfracloud.org/coprs/pbiering/InternetServerExtensions/

nresare

nresare commented on May 16, 2025

@nresare
Owner

Thank you for the contributions! Just a small set of comments on the PR.

When it comes to pam_rssh it does indeed seem like we have two independent implementations of pretty much the same functionality. I am obviously partial in favour of my variation, here are some differences:

  • pam_rssh leans on openssl and rust to c bindings whereas pam-ssh-agent leans on the ssh-key crate with rust native crypto
  • There is quite a bit of code that interacts with openssl in sign_verify.rs that doesn't seem to be covered by unit tests in pam_rssh, by contrast pam-ssh-agent is leaning on ssh-key for those interactions, a crate with comprehensive testing and a larger user base
  • Each of the variants lean on a custom implementation of the ssh-agent binary protocol. ssh-agent-client-rs that pam-ssh-agent uses has API documentation, pretty extensive unit testing and example binaries using the API whereas ssh-agent.rs that pam_rssh uses lacks documentation and examples and has a significantly lower unit test coverage
  • pam_rssh has some variable extrapolation support in the pam config parametrs that pam-ssh does not yet have. With this push however, I feel keen to finish my half baked implementation that I started a while ago
nresare

nresare commented on May 20, 2025

@nresare
Owner

Since I went through the exercise of comparing pam-ssh-agent to pam_rssh I felt like it would be good to plug the "feature gap" by implementing the little pieces still missing.

If someone following this issue uses variable extrapolation and could review/test my changes that would be most welcome, the PR is #26

nresare

nresare commented on May 24, 2025

@nresare
Owner

Ok, I confess, I got nerd sniped into wrapping my head around how upstream Fedora / EPEL encourages packaging and upstream contributions. These are my preliminary findings:

  • The 3 crates that are not packaged upstream at all, pam-bindings, ssh-agent-client-rs and pam-ssh-agent can be built with dynamically generated .spec files and minimal rust2rpm.toml configuration. I have created a new git repository containing just the minimal stuff needed to build the .src.rpms for those in https://github.com/nresare/rpm-packaging
  • For the EPEL Enterprise Linux 10 package build there is a whole tree of packaged crates that are simply unavailable in upstream. Interestingly, with one exception, these can be built by simply uploading the Fedora 42 .src.rpms to a COPR project in the right order and CentOS Stream 10 + EPEL + a COPR repo will provide the needed dependencies
  • I have done this in the https://copr.fedorainfracloud.org/coprs/noa/rust/ project, so there is a pam-ssh-agent package available by simply running dnf copr enable noa/rust on your Fedora 42 or CentOS Stream 10 + EPEL

I guess the next step now is to find some Fedora packaging sponsor that could review and approve those pacakges. Does anyone on this thread have any contacts in that space?

pbiering

pbiering commented on May 24, 2025

@pbiering
Contributor

I guess the next step now is to find some Fedora packaging sponsor that could review and approve those pacakges. Does anyone on this thread have any contacts in that space?

If you would maintain them by yourself, you can file New-Package request to Fedora and EPEL, once approved, you can push them.

I would start first with Fedora 42, once available there, then continue with EPEL. EL10 is rather new, so admins which asap need pam-ssh-agent here can survive with your COPR repo some weeks imho.

nresare

nresare commented on May 24, 2025

@nresare
Owner

Review request for pam-bindings: https://bugzilla.redhat.com/show_bug.cgi?id=2368361
Review request for ssh-agent-client-rs: https://bugzilla.redhat.com/show_bug.cgi?id=2368362

neverpanic

neverpanic commented on May 26, 2025

@neverpanic

pam-ssh-agent leans on the ssh-key crate with rust native crypto

That's unfortunate, because it means this crate cannot be made to use a FIPS-validated implementation of the cryptographic primitives, which therefore means it will likely not be included in RHEL, whereas pam_rssh relying on OpenSSL, could be.

I realize that's not your problem, and it it's probably fine to include it in Fedora anyway, but it can cause problems for distributions downstream of Fedora that have to care about FIPS compliance, such as RHEL or Amazon Linux.

nresare

nresare commented on May 28, 2025

@nresare
Owner

@neverpanic That is a factor I honestly had not thought about.

If that is a requirement, I could definitely write some code that would optionally call out to a different implementation for the signature validation. The needed functionality is a method to verify signatures of three different types.

It is a bit sad that FIPS compliance would force us to use a technically inferior solution. Googling about the topic of FIPS compliance, it seems we might see this for the ring crate at some point, but I do realise that that point is not now: https://briansmith.org/lets-build-a-fips-rust-crypto

nresare

nresare commented on May 31, 2025

@nresare
Owner

@neverpanic there is now #33, a feature that when enabled defers crypto operations to the system native openssl library.

I now feel more convinced than ever that openssl is not nice software 😄

carlos-sarmiento

carlos-sarmiento commented on Jun 1, 2025

@carlos-sarmiento
Author

Most of the changes happening here go way above my head, but wanted to say thanks @nresare for all your effort on making this happen

neverpanic

neverpanic commented on Jun 3, 2025

@neverpanic

@neverpanic there is now #33, a feature that when enabled defers crypto operations to the system native openssl library.

I now feel more convinced than ever that openssl is not nice software 😄

Wow, thank you! You didn't have to do this.
And yes, OpenSSL's API is not nice, that's well-known. It's marginally better with 3.x, but the rust openssl crate doesn't use 3.x APIs.

nresare

nresare commented on Aug 8, 2025

@nresare
Owner

Is there anyone on this thread that has some friends within the Fedora packaging community that might be able to encourage someone to have a look the review requests?

Review request for pam-bindings: https://bugzilla.redhat.com/show_bug.cgi?id=2368361
Review request for ssh-agent-client-rs: https://bugzilla.redhat.com/show_bug.cgi?id=2368362

pbiering

pbiering commented on Aug 8, 2025

@pbiering
Contributor

Is there anyone on this thread that has some friends within the Fedora packaging community that might be able to encourage someone to have a look the review requests?

Me not unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @neverpanic@nresare@AdmiralNemo@carlos-sarmiento@pbiering

        Issue actions