Using SSH keys for remote jobs
Eventline supports several runners used to execute jobs in different environments. But in some cases, you may want to execute a job on a remote machine. You may want to use specific hardware such as a powerful GPU or a faster machine where Eventline is not deployed. Or maybe you need access to data stored somewhere else. Let us explore how to do that using SSH.
In this article, we will assume that you have already installed Eventline and Evcli. If this is not the case, refer to the tutorial first.
Generating and deploying a key
We start by generating a SSH key:
ssh-keygen -t ed25519 -C eventline -f ssh-example
We make sure to create an Ed25519 key
for both security and performances, add “eventline” as comment, and store the
key in a file named
The program asks for an optional password (do not set one) then generates the
private key into
ssh-example and the public key into
We then deploy the key on the remote server by adding the content of the
public key file to the
~/.ssh/authorized_keys file for the user you want to
Creating an identity
Head to the “Identities” page of Eventline, and click on the “Create identity”
button. Select the
generic connector and the
ssh_key type, and fill the
“Private key” and “Public key” fields:
Submit the form; the
ssh-example identity is now ready to use in your jobs.
Writing the job
We can now write a job. Open a file named
ssh-test.yaml and add the
name: "ssh-test" identities: - "ssh-example" environment: HOST: "example.com" steps: - code: | ssh-keyscan -H $HOST >>$HOME/.ssh/known_hosts ssh -i $EVENTLINE_DIR/identities/ssh-example/private_key $HOST uname -a
We are relying on the fact that Eventline creates files for each field of the identities included in the job.
Deploy the job using Evcli:
evcli deploy-job ssh-test.yaml
Execute the job either with Evcli or on the web interface:
uname command was successfully executed on the remote server.
The hardest part is done! You can now build upon it for more complex jobs.
For example, at Exograd, we use remote jobs to regularly scrub ZFS pools and run package audits.
You could also run tests and create software builds on a platform with a different architecture, or periodically execute a battery of tests on a production machine to make sure your everything is still running as intended.
Since jobs execute pure code, everything is possible.
As you can see, it is really simple to inject SSH keys into jobs and use them for remote execution.