Connection closed by UNKNOWN port 65535

[Tanguille]

I am trying to use this action to trigger an ansible-playbook inside github actions. I read the documentation and inserted all secrets, even the optional ones. However I keep getting the error Connection closed by UNKNOWN port 65535 and nothing seems to happen on my ansible machine.

Do you have any idea how I could debug this further? Thanks in advance!

The action:

deploy:
    needs: [build_image, build_seed]
    runs-on: ubuntu-latest
    steps:
      - name: Run Ansible playbook on remote server
        with:
          host: ${{ secrets.ANSIBLE_SSH_HOST }}
          username: ${{ secrets.ANSIBLE_SSH_USERNAME }}
          private_key_filename: ${{ secrets.ANSIBLE_SSH_PRIVATE_KEY_FILENAME }}
          private_key_value: ${{ secrets.ANSIBLE_SSH_PRIVATE_KEY_VALUE }}
          port: ${{ secrets.ANSIBLE_SSH_PORT }}
          service_token_id: ${{ secrets.SERVICE_TOKEN_ID }}
          service_token_secret: ${{ secrets.SERVICE_TOKEN_SECRET }}
          commands: |
            cd devops
            ansible-playbook playbooks/rsmono/initial_setup.yaml -e env=cd --vault-password-file vars/.vault_pass.txt

[npgy]

Can you verify that you're able to ssh into the machine manually from the tunnel first?

Something to the effect of: cloudflared access ssh --hostname yourhost.com --url localhost:2225 which opens a port 2225 for you to ssh into ssh -i /path/to/key.pem yourusername@localhost -p 2225

[Tanguille]

That seems to work. I did that from my dev machine instead of the runner (which is running inside my LAN), is this what you intended me to test?

[npgy]

Yeah just wanted to check my sanity and make sure the tunnel itself was good. You mentioned your github actions runner is self-hosted and running inside your own LAN?

[Tanguille]

Indeed, could this be the issue? Since it uses the cloudflare tunnel I was expecting it to be fine.

[npgy]

I haven't tested this yet on a self-hosted runner, but I would imagine it should work just the same. Is your LAN on the same network as the target server you're SSHing into?

[Tanguille]

Yes. Is there any way to make the action more verbose as I'm not seeing much useful information in the logs?

[npgy]

Sure thing, just pushed a change to the develop branch to enable debug logging. If you run your action as and-fm/cloudflared-ssh-action@develop you should be able to run the debug version

[npgy]

I'll be adding the ability to enable this with an input as well so you and others can more easily enable/disable it

[Tanguille]

I tried this and get the following output:

Run and-fm/cloudflared-ssh-action@develop
  with:
    host: ***
    username: ***
    private_key_filename: ***
    private_key_value: ***
    port: ***
    service_token_id: ***
    service_token_secret: ***
    commands: cd devops
  ansible-playbook playbooks/rsmono/initial_setup.yaml -e env=cd --vault-password-file vars/.vault_pass.txt

/usr/bin/docker run --name c960e79d3d27f97da345af9fe04a5e05f56ef5_a27573 --label c960e7 --workdir /github/workspace --rm -e "REGISTRY" -e "IMAGE_NAME" -e "INPUT_HOST" -e "INPUT_USERNAME" -e "INPUT_PRIVATE_KEY_FILENAME" -e "INPUT_PRIVATE_KEY_VALUE" -e "INPUT_PORT" -e "INPUT_SERVICE_TOKEN_ID" -e "INPUT_SERVICE_TOKEN_SECRET" -e "INPUT_COMMANDS" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_RESULTS_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/***/work/_temp/_github_home":"/github/home" -v "/home/***/work/_temp/_github_workflow":"/github/workflow" -v "/home/***/work/_temp/_***_file_commands":"/github/file_commands" -v "/home/***/work/rsmono/rsmono":"/github/workspace" c960e7:9d3d27f97da345af9fe04a5e05f56ef5  "***" "***" "***" "***" "***" "cd devops
ansible-playbook playbooks/rsmono/initial_setup.yaml -e env=cd --vault-password-file vars/.vault_pass.txt
" "***" "***"
OpenSSH_9.7p1, OpenSSL 3.3.2 3 Sep 2024
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 1: Applying options for ***
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line ***: include /etc/ssh/ssh_config.d/*.conf matched no files
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/root/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2'
debug3: channel_clear_timeouts: clearing
debug1: Executing proxy command: exec cloudflared access ssh --hostname *** --id *** --secret ***
debug1: identity file /root/.ssh/*** type 3
debug1: identity file /root/.ssh/***-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.7
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

[npgy]

Interesting, I wonder if it's a networking issue, a problem with accessing a tunnel from the same machine that the tunnel is running on. That seems like a weird use case too, maybe you can explain why you want to do this instead of executing the commands on your server directly in the hosted runner? Or to debug further you can also try manually connecting through the tunnel as you did before on your dev machine but instead on the server.