Pritunl-zero ssh bastion allows to login as any user?

Pritunl Pritunl Zero
1

Hi folks,

Just finished configuring pritunl-zero, it’s feels nice, only wish I can think of right now is terraform a provider, for we could avail all the benefits of configuration-as-code paradigm.

I setup bastion as per getting started guide (tl;dr TrustedUserCAKeys and AuthorizedPrincipalsFile) and was able to log in. Sweet.

Quick question though, I seem to be able as any user on that host (including root when PermitRootLogin is set to yes).

Is this expected?..

2

Thinking…

It looks like certificate carries user identifiable information in the KeyID , only since its using an internal pritunl user id… therefore bastion should probably validate that bit somehow with the pritunl-zero server before letting user in?..

Is there an pritunl-zero API call an ssh bastion could make to validate user exists?

Could we maybe save Username as certificate KeyId and not Id, say:

+++ b/authority/authority.go
-               KeyId:           usr.Id.Hex(),
+               KeyId:           usr.Username,

that way user accounts on the ssh bastion could be populated according to company -wide naming convention (in our case firstname.lastname, validation would be straightforward, principal’s command would compare firstname.lastname with user’s email address).

3

I don’t think there is any option to associate a Linux user with a specific Pritunl Zero user.

Controlling access to different accounts can be one in the sshd_config using Match options. The example below would allow only the user account example to authenticate with Pritunl Zero. Multiple AuthorizedPrincipalsFile files can be created to match different Pritunl Zero roles to different users. These options should always be terminated with Match all to prevent options added below from being scoped to a user.

Match User example
    TrustedUserCAKeys /etc/ssh/trusted
    AuthorizedPrincipalsFile /etc/ssh/principals
Match all
4

Controlling access to different accounts can be one in the sshd_config using Match options. The example below would allow only the user account example to authenticate with Pritunl Zero. Multiple AuthorizedPrincipalsFile files can be created to match different Pritunl Zero roles to different users. These options should always be terminated with Match all to prevent options added below from being scoped to a user.

Interesting, thank you.

Please correct me if I’m wrong, I understand that AuthorizedPrincipals contains a list of roles, right?..

While roles themselves are defined by the pritunl-zero server (either manually or in case of SSO assigned automatically based on information received from the upstream provider) and encoded in certificate’s Principals.

How would multiple AuthorizedPrincipalsFile files help prevent Bob from logging as Alice, if they belong to the same group, end up with same principal?.. Wouldn’t it require one AuthorizedPrincipalsFile per user?..

I’m confused, if you please explain what you mean?..

5

I don’t think there is any option to associate
a Linux user with a specific Pritunl Zero user

If you see my previous post, please, if we encode username in the certificate or find a way to validate user id with pritunl-zero server, that would work, right?..

I mean I thought of:

  • giving the bastion read only access to mongodb to query for user Id; considered this a really bad idea
  • developing a service real quick that would run along with pritunl-zero query the database and validate accounts; consider this to defy entire idea of SSH certificates
  • patching pritunl-zero to encode needed information in the certificate; liked this idea the most

I’m now running on a patched version of pritunl-zero right now (encoding usr.Username instead of usr.Id and on the bastion use a command that validates not only principals but also matches KeyID with login username). It’s working pretty well.

Trouble is that I don’t really feel like maintaining my fork and hoping you could figure out even better way to deal with the trouble.

6

Oh, it’s not just us who believe this problem (inability to differentiate users) to be an opportunity for substantial improvement.

Other than that hiccup we like Pritunl Zero very much and are hoping Zach will figure out a better way… fingers crossed!.. :slight_smile:

7

The Key ID Format option has been added to the authority settings to change the key ID format to User ID, Username or Username ID. The username ID option will use the format userid:username.

key_id_format

8

Great, thank you so very much.

PS. For anyone’s interest, below an excerpt from our cloudinit.sh (Ubuntu Focal). In our environment rather simple thanks to consistent username convention (unix: firstname.lastname, email firstname.lastname@):

cat > /etc/ssh/sshd_config.d/pritunl-zero.conf << EOF
TrustedUserCAKeys /etc/ssh/pritunl_zero_trusted_user_ca_keys
AuthorizedPrincipalsCommandUser root
AuthorizedPrincipalsCommand /bin/bash -- /etc/ssh/pritunl_zero_authorized_principals_command %u %i
EOF

cat > /etc/ssh/pritunl_zero_trusted_user_ca_keys << EOF
ecdsa-sha2-nistp384 AAAA(..)==
EOF

cat > /etc/ssh/pritunl_zero_authorized_principals_command << EOF
#!/usr/bin/env bash

set -euo pipefail

function exit_authorized() {
  echo "sg-pritunl-engineering-development"
  echo "sg-pritunl-engineering-infrastructure"
  exit
}

username="\$1"
username_certificate="\$2"

if [[ "\$${username}" == "\$${username_certificate/@*}" ]]; then
  exit_authorized
fi