Is it possible to use SSH for Infrastructure from a CI container?

Zero Trust Access
1

What is the name of the domain?

velixo.com

What is the issue you’re encountering

Cloudflare SSH proxy rejects the non_identity SSH logins from a CI container

What are the steps to reproduce the issue?

I am using GitHub - Boostport/setup-cloudflare-warp: Access Cloudflare Zero-Trust applications in GitHub Actions Workflows to connect to our Zero Trust organisation from within a CI pipeline. Then, I need to do some ssh-based operations.

The target server (an EC2 instance that is connected to a tunnel) is secured by an Infrastructure application with the following access policy: Azure Group list (for interactive user sessions) OR email: [email protected]

When I sign in to Zero Trust locally from my machine using my Azure AD account, I can establish an SSH connection to the server successfully.

However, from the CI environment, the following happens:

– Device is enrolled successfully ([email protected]) and a Zero Trust connection is established
– However, the SSH connection is rejected by the Cloudflare proxy at the application level

I managed to achieve a scenario where SSH -vvv logs are identical on both my machine and in the CI environment, except that in a CI environment, I receive back packet 51 (authentication failed) instead of packet 52. I’m using the same origin server Linux username in both cases, same as the one configured in the Infrastructure application. The check box that allows signing in under the email prefix does not make any difference.

Can Infrastructure applications be used from CI containers? Are there any special recipes here that are not mentioned in the documentation?

2

Hi pkabir! Thanks for your patience with our reply. Access for Infrastructure doesn’t have formal support for service tokens yet, but there is a way you can enable your desired flow today. There was an issue in the flow you identified, but it’s since been fixed so you are now able to authenticate using your service token by doing the following:

  • Make sure your service token is using the auth_client_id.

  • Include the email that is generated alongside your service token as an allowed user in your infrastructure application policy. The email in your case would be [email protected]. Please note that this will enable all service tokens generated from your account access to SSH to your configured targets. We aren’t able to limit access per token at this time.