uber's ssh certificate pam module

Add a simple Github actions workflow to prove and demonstrate how to build this module. This could be the base for automated releases, for now it only runs the make command.

Notable things for running with modern Go versions:

GO111MODULE=auto is required (see: https://go.dev/blog/go116-module-changes)

• Add CI workflow

Add basic CI workflow to test and build

• Add libpam0g-dev

Add required package libpam0g-dev to CI

One of the options for an SSH certificate is force-command (https://man.openbsd.org/ssh-keygen.1#force-command).

Would it be possible to limit the command that a user is able to execute with sudo if the force-command is set in the SSH certificate?

This would be super useful to be able to issue a certificate for a user with sudo permissions for one particular command without knowing the command in advance (otherwise you could user the sudoers file).

Is this possible in the PAM? Do you have access to the command that is to be run? I'm happy to contribute this feature with a little guidance in the right direction :)

In x/ssh/crypto a breaking change was introduced by pmoody in commit 527d12e53572562de9fd348d50e1ee4096803cec. This implements the needed fix within pam_ussh.go to support the upstream go change.

This resolves #5.

Centos 6 using latest go in repository:

# make test
mkdir -p /lib/security/pam-ussh/.go/src
GOPATH=/lib/security/pam-ussh/.go go get golang.org/x/crypto/ssh
GOPATH=/lib/security/pam-ussh/.go go get golang.org/x/crypto/ssh/agent
GOPATH=/lib/security/pam-ussh/.go go get github.com/stretchr/testify/require
GOPATH=/lib/security/pam-ussh/.go go test -cover
# _/lib/security/pam-ussh
/tmp/go-build020625526/_/lib/security/pam-ussh/_test/_obj_test/pam_ussh.go:128: unknown ssh.CertChecker field 'IsAuthority' in struct literal
FAIL	_/lib/security/pam-ussh [build failed]
make: *** [test] Error 2

Hey there and first a big thanks for providing this project. We try around with certificate based authentication at the moment and this seams to be the perfect fit to enable sudo via certs without having passwordless sudo. Before using it in production I have some concerns on the health of the project as there is no release and some open PRs.

So just a simple question: Is this project still alive and maintained?

Thanks :-)

In case of multiple principals in a certificate, cert.ValidPrincipals[0] will create a log with first principal name which has no relation with the authentication. It creates misleading logs. It assumes first principal will always be the username, which might not be the case.

Instead, the username should be logged explicitly that was authenticated.

Fixes bug reported by penguinsaretasty.

If pam-ussh is presented a certificate signed by another authority for the current user, pam-ussh will accept the forgery and return a successful authentication.

Apparently, pam-ussh itself and its recently added euid switching were designed with primarily, or even exclusively, sudo in mind. With sudo, the user controlling the SSH_AUTH_SOCK env var and the user being authenticated are the same, so it's reasonable to switch to that user's euid for accessing the socket (of the user's choice).

Now imagine having the module stacked for su instead. The target user may be e.g. root (this is different from sudo's case), but the env var is under the invoking user's control (just like with sudo). Thus, the invoking user may make pam-ussh access a pathname that is not normally accessible by the user directly. The "pam-ussh: check cert against the pam username" commit hopefully defeats the obvious attack on authentication (although this depends on external/setup detail), but it doesn't deal with the issue of pathname probing (with pam-ussh becoming an oracle, potentially providing 1-bit responses via side-channels), nor with potential side-effects of being able to connect to (even though not talk over) arbitrary Unix domain sockets (not necessarily those of any ssh-agent, bypassing Unix permissions on parent directories and the sockets themselves).

Maybe the README should be re-worded some further, stating that the module is only meant for use with sudo, and any other use may be unsafe? I don't find use e.g. along with su reasonable anyway.

This might be obvious after one starts debugging... but the the pam-ussh only works if the client uses agent-forwarding.

Thanks for this PAM module! I'm trying to integrate it https://github.com/openstack/tatu (SSH as a Service for OpenStack).

Make optional requiring that certs contain a principal matching the local username.

For backward compatibility, disabling the check of a local-username-principal is opt-in, as doing the opposite would make existing configurations more open on upgrade.

Resolves #15.

Modified pam_jwt.go to allow x509 compatible issuer, fixed by using strings.SplitN instead of strings.Split:

func pamAuthenticate(username string, authToken string, argv []string) (string,
        var verifyUser bool = true
 
        for _, arg := range argv {
-               opt := strings.Split(arg, "=")
+               opt := strings.SplitN(arg, "=", 2)
                switch opt[0] {
                case "secret":
                        secret = opt[1]

Hi,

I was trying to find cpe_uri associated with this package in NIST/NVD so that COS (https://cloud.google.com/container-optimized-os/docs) can track security vulnerabilities associated with it. However, based on the search there was no cpe_uri associated. From the past security vulnerabilities, I could find https://hackerone.com/reports/204802 security vulnerability but there was no CVE Number assigned for that in that bug.

Could you help in providing information as what cpe_uri can be used by downstream users to track security vulnerability in this package from NIST/NVD?

This PR adds a configuration option to execute a separate command to get a list of authorized principals. It is similar to the AuthorizedPrincipalsCommand option for sshd.

Some of the added tests rely on #21 which will need to be merged first or the tests may have to change depending on the result of that PR.

This PR removes the requirement that a username must appear within a certificate's list of principals so long as an explicit set of valid principals is defined. This change was made so that the call to c.CheckCert on line 166 will verify the certificate, but explicitly exclude checking principals because pam-ussh verifies principals later in the code.

This change is related to #15.