🐛 Problems with auth via service token

[Dmitrium12]

Describe the bug I'm setting up a tunnel to my server to access ssh via zero trust. It is necessary to be able to log in without additional authentication, and for this I created a secret token. Keys were ignored and sent me to the confirmation page. Here is the config I used:

Host domain
  ProxyCommand cloudflared access ssh --service-token-id example.access --service-token-secret example1234 --logfile "/home/ddd/log/cloudlog.txt" --log-level debug --hostname domain
  User root
  IdentityFile ~/.ssh/id_rsa

To Reproduce Steps to reproduce the behavior:

1. configure access keys
2. Add config to .ssh/config
3. proxy redirects you to browser and force you to log in via selected authorization method

Expected behavior automatic connection to the server via ssh without entering authorization data.

Environment and versions

• OS: Fedora Linux 39 (Workstation Edition)

• Architecture: AMD

• Version: cloudflared version 2023.10.0 (built 2023-10-31-1234 UTC)

• OS: Microsoft Windows 11 Pro (10.0.22621 build 22621)

• Architecture: AMD

• Version: cloudflared version 2023.10.0 (built 2023-10-31-1231 UTC)

Logs and errors {"level":"debug","time":"2023-11-09T10:58:05Z","message":"Websocket request: GET / HTTP/1.1\r\nHost: domain\r\nCf-Access-Client-Id: example.access\r\nCf-Access-Client-Secret: example1234\r\nUser-Agent: cloudflared/2023.10.0\r\n\r\n"}

[TechnicalObject]

Hello, it is possible to get around this by setting linux env variables TUNNEL_SERVICE_TOKEN_ID and TUNNEL_SERVICE_TOKEN_SECRET to their respective values, then it should be possible to call cloudflared access ssh without the --service-token-id and --service-token-secret options.

[Dmitrium12]

@TechnicalObject I attempted to utilize environment variables, but it still necessitates logging in through sevis.

[ILLISIS]

I also tried this for tcp in terminal with the same issue

cloudflared access tcp --hostname something.example.com --url localhost:9980 --service-token-id xxxxxxxxxxxxxxx.access --service-token-secret xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[nathanjnorris]

I am also seeing this behavior. Do you need to pass the header as well? e.g. --id 'CF-Access-Client-Id: example.access'

[nathanjnorris]

I am also seeing this behavior. Do you need to pass the header as well? e.g. --id 'CF-Access-Client-Id: example.access'

Got past this error. You need to make sure your access policies allow for Service Auth:

From the Cloudflare docs: You can now use the service token in your Access policies and device enrollment rules. When creating these policies, select the Service Auth action to ensure that the identity provider login screen is not required for end users. https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/

[ILLISIS]

I once again tried this with the latest version of cloudflared and was unsuccessful. I have ensured that service token authentication is the top rule in both the application and even the device enrollment rules.

The Cloudflare Access applcation works fine when accessing it via the public hostname, even the websockets. I have disabled SBFM and checked the WAF logs - it is not being blocked there. I can see auth is successful in the Access logs.

command: cloudflared access tcp --hostname something.example.com --url localhost:9980 --service-token-id xxxxxxxxxxxxxxx.access --service-token-secret xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Error:

ERR failed to connect to origin error="websocket: bad handshake" originURL=https://something.example.com 2024-04-15T12:45:57Z DBG Websocket request: GET / HTTP/1.1 Host: something.example.com Cf-Access-Client-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.access Cf-Access-Client-Secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx User-Agent: cloudflared/2024.4.0

Effectively what I am attempting to do is allow an software application to access a Cloudflare Access protected application in order to connect to its API. What I also expect works, and this is my testing method, is running cloudflared to authenticate to the CF Applcation's web UI.