The n8n SSH node gives you ability to do pretty much anything you would do if you logged into a remote machine via a terminal session. Here are the steps I took when setting things up for my workflows:

  1. Create a new user.
  2. Create SSH keys for the new user.
  3. Create the script you want to enable in n8n.
  4. Configure the SSH key so only a specific script can be run.

Note that all of these steps are optional. You could just set up the node, create a new set of n8n credentials via username/password, and run any command from n8n. In my case, I run n8n on a virtual private server (VPS) so I wanted to restrict what it could do. If you’re running n8n in a home lab environment, you probably don’t need to be this restrictive.

Create a New User#

To better manage permissions, I created a new user without sudo privileges.

sudo adduser n8n-user --shell /bin/bash

Create SSH Keys#

Part of a basic security setup for a VPS is typically turning off the ability to SSH to the server via username/password. If you leave port 22 open to the public internet and take a look at the access log you’ll see why. It’s basically under constant attack by bots trying typical username and password combinations.

To create the keys:

# Switch to the new user
sudo su - n8n-user

# Generate the keys.  
# Use of a passphrase is optional.  n8n does allow you to enter it when creating the credentials
# When prompted, specify a custom name for the keys such as 'id_n8n_automation'
ssh-keygen -t ed25519 -C "n8n-automation"

Next, add the key to a “authorized_keys” file to enable it for SSH

# Write the public key to the authorized_keys file
cat ~/.ssh/id_n8n_automation.pub >> ~/.ssh/authorized_keys
# These commands restrict folder and file permissions to the owner (current user)
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

Finally, print out the private key (you’ll use this in the n8n credentials) and exit back to your normal user’s shell session.

cat ~/.ssh/id_ed25519
exit

Create the Script and Restrict the SSH Key#

This part is optional as greatly increases security but also greatly reduces what you can do in n8n. The idea is, you tie the SSH key to a single shell script. When an SSH session is initiated with the key, the script will execute and then the session is ended. There is no opportunity to do anything else.

  1. Create the script you want to run.
  2. Open the authorized_keys file
/home/n8n-user/.ssh/authorized_keys
  1. Locate the line for the key you want to restrict.
  2. Add the restriction before the key starts:
command="/home/n8n-user/script_to_run.sh",no-port-forwarding,no-x11-forwarding ssh-ed25519 AAAAC3...

The entire thing, command and public key, needs to be on one line. No line breaks allowed.

Add the SSH Node in n8n#

In your workflow, add a “SSH” node.

  1. Under “Credential to connect with” select “Create new credential”.
  2. Enter the IP address of the target server. If the target is the host machine for the n8n Docker instance, specify the Docker network’s gateway IP address.
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}} (Gateway: {{.Gateway}}){{end}}' <container_id_or_name>
  1. Specify the port. This is 22 unless you’ve changed it on the server.
  2. Paste in the private key from the “Create SSH Keys” section above.
  3. Enter the SSH key passphrase if you specified one during creation.
  4. Click Save.

Continue configuring the node.

  1. Resource = Command
  2. Operation = Execute
  3. Command = The shell command or script to run. If you restricted the SSH key to run a script, this value doesn’t really matter.
  4. Working Directory = The directory where the command should be executed.

Conclusion#

The SSH node gives you lots of flexibility when you integrate them into your workflows. Just be careful which user you use. Using a user with sudo access likely isn’t a good idea. It’s usually best to plan for the worst case scenario.