Runner job, SSH executor failing

Hi there.

I’m trying to add a test pipeline to my gitlab runner, but it keeps failing at the “SSH executor” step.

I’ve added the private key as a SSH_PRIVATE_KEY variable, and it’s not protected, so the branch should be able to see it.

The pipeline yml is an example I found in the gitlab docs

  stage: build
    - echo "Hello, $GITLAB_USER_LOGIN!"

  stage: test
    - echo "This job tests something"

  stage: test
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

  stage: deploy
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

no matter what I’ve tried, I always get this output

any help on how I can debug this?
It seems to me that the job doesn’t use the private key at all.

I’ve tested the private key manually, and I do get access to the runner.

Hi @antouank
You have issue with your GitLab Runner SSH executor configuration.
Check your config.toml and make sure the values are correct. Especially the user and password fields.

thanks @balonik

I’ll check the config.

The fact that the message says ... attempted method [none password] doesn’t it mean that it doesn’t try the publickey method?
So it doesn’t see the variable?
That was my thought. Is that something the config.toml configures?

AFAIK that variable is not used by GitLab Runner SSH executor. You need to specify password/identity_file in config.toml

thanks for the tip.

I specified the path to the private key and I can see the publickey method now.
But, it’s still failing.

Preparing the "ssh" executor
Using SSH executor...
ERROR: Preparation failed: ssh command Connect() error: ssh Dial() error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password publickey], no supported methods remain
Will be retried in 3s ...

What’s confusing to me is how the ssh pairs work here.
In the runner, I specify the private key of pair A let’s say.
In gitlab CI variables, do I need to specify the private key of a pair B? And put its public part in the authorized_keys in the runner?
Or something else?
Any help on that would be much appreciated.

You don’t need to specify anything in the CI variables regarding SSH Key pairs.

You have SSH Runner so the authentication works like this:
GitLab <-> GitLab Runner : runner registration token
GitLab Runner <-> host specified in config.toml : password or identity_file configured in config.toml. Identity file (private part) needs to be stored on host where GitLab Runner process is running and accessible to GitLab Runner process. Public part of the SSH Key pair in authorized_keys on host.

If you get error authenticating to host I suggest to look at host to identify why the login fails. The user might be locked, .ssh directory doesn’t have right permissions or authorzied_keys file doesn’t have right permissions. Or anything else depending on your setup.

1 Like

I think we misunderstood completely how ssh executor works.
That clarified it.

I think we’ll try a docker executor instead, since ssh-ing to the same machine is not useful to us.
( I was under the impression that gitlab will ssh into the runner to execute commands )

thanks for the help, much appreciated :+1:

If you want to run commands on a local machine where GitLab Runner is installed, you need the shell executor.

ok, that’s another option.

wouldn’t docker isolate things a bit more?
so different commits/project can use different images / versions of software.

Yes, Docker executor is definitely better for isolation projects/jobs and you don’t need x versions of software on a host.

Unless you really need shell executor or it is dedicated GitLab Runner for specific purpose I don’t recommend it.


I think docker fits better. And simpler to build/discard images.

Having an issue there with a

ERROR: error during connect: Get http://docker:2375/v1.40/info: dial tcp: lookup docker on server misbehaving

But I don’t want to get off-topic in this thread. I’ll try to google it a bit more :slight_smile: