n8n nodo SSH: comandos remotos y archivos en tus workflows
El n8n nodo SSH conecta un workflow de n8n self-hosted con cualquier servidor Linux remoto para ejecutar comandos shell, capturar stdout/stderr y transferir archivos, sin depender de un pipeline CI externo. Según la guía publicada el 3 de julio de 2026, con las tres operaciones del nodo podés hacer deploys, reiniciar servicios, bajar logs y sincronizar archivos directamente desde tu automatización.
Si alguna vez armaste un deploy a mano por SSH, sabés lo que es entrar al server, tirar el git pull, reiniciar el servicio y rezar. La idea acá es meter todo eso adentro de n8n.
En 30 segundos
- Tres operaciones: ejecutar comando remoto, bajar un archivo del server (pull) y subir uno al server (push), todas con la misma credencial SSH.
- Dos tipos de auth: por contraseña (rápido, menos seguro) o por clave privada (recomendado en producción).
- Gotcha del formato: n8n espera la clave en formato OpenSSH; si la generaste con PuTTYgen (BEGIN RSA PRIVATE KEY), tenés que convertirla.
- Output útil: cada comando devuelve stdout, stderr y exit code, así podés validar si salió bien antes de seguir.
- Sin CI externo: deploys, restarts y backups quedan dentro del mismo workflow visual.
El nodo SSH de n8n es un nodo core que abre una conexión SSH contra un servidor remoto para correr comandos y mover archivos desde un workflow. Pertenece a n8n, la plataforma de automatización open source, y funciona en instalaciones self-hosted. Usa una única credencial (usuario más contraseña o clave privada) para las tres operaciones disponibles: ejecutar comando, descargar archivo y subir archivo.
¿Para qué sirve el nodo SSH de n8n en la práctica?
Ponele que tenés una app corriendo en un VPS y cada vez que mergeás a main querés que se actualice sola. Con el nodo SSH lo resolvés sin montar un Jenkins ni un GitHub Action que toque tu server.
Los casos típicos que menciona la fuente:
- Deploys automáticos: corrés
git pull, instalás dependencias y reiniciás el proceso. - Reinicio de servicios: un
systemctl restart nginxdisparado por un evento. - Pull de logs: te traés un archivo de log del server para procesarlo dentro del workflow.
- Sync de archivos: subís configs o backups a una ruta específica del remoto.
Todo esto sobre infraestructura que vos controlás. Si estás por levantar el VPS o el hosting donde va a correr n8n, en donweb.com tenés opciones en Argentina para arrancar.
¿Cómo configurar las credenciales SSH en n8n?
El camino es Credentials → New → SSH. Ahí elegís entre las dos formas de autenticarte. Para más detalles técnicos, mirá integrar n8n con bases de datos externas.
Opción A: autenticación por contraseña
Completás host (IP o hostname), puerto, usuario SSH y contraseña. Funciona, pero la propia guía lo aclara sin vueltas: la auth por contraseña es menos segura y conviene dejarla para pruebas.
Opción B: autenticación por clave privada (recomendada)
Generás el par de claves si no lo tenés (ssh-keygen -t ed25519), copiás la pública a ~/.ssh/authorized_keys en el server remoto y pegás el contenido completo de la clave privada en la credencial de n8n, incluyendo las líneas -----BEGIN...-----END. Si tu clave tiene passphrase, la agregás en su campo.
Acá viene el detalle que rompe a más de uno: n8n espera la clave en formato OpenSSH. ¿Generaste una RSA vieja con PuTTYgen que arranca con BEGIN RSA PRIVATE KEY? La tenés que convertir a OpenSSH antes, o la credencial no valida.
¿Cómo ejecutar comandos remotos con n8n?
La operación de comando corre cualquier string de shell en el server y te devuelve el resultado. En el campo del comando ponés algo como systemctl restart nginx y listo. Más contexto en request HTTP para APIs externas.
Lo bueno es el output estructurado. El nodo te da tres campos que podés usar en los pasos siguientes del workflow.
| Campo | Qué contiene | Para qué lo usás |
|---|---|---|
| stdout | Salida estándar del comando | Leer el resultado (ej: el output de un git pull) |
| stderr | Salida de errores | Detectar warnings o fallas que no cortan la ejecución |
| exit code | Código de salida (0 = éxito) | Validar con un IF si el comando salió bien antes de seguir |
El exit code es tu red de seguridad. Si es distinto de 0, algo falló, y podés cortar el flujo o disparar una alerta en vez de seguir como si nada.
¿Cómo transferir archivos entre n8n y el servidor?
Hay dos operaciones y es fácil confundirlas:
- Pull (descargar): trae un archivo del server remoto hacia el workflow como binary data. Ideal para bajar el log del día y procesarlo.
- Push (subir): manda binary data del workflow hacia una ruta específica del server. Sirve para subir una config o dejar un backup.
La regla mental es simple: pull baja, push sube. Suena obvio hasta que a las tres de la mañana invertís los dos y sobrescribís el archivo equivocado.
¿Por qué usar clave privada en lugar de contraseña?
La contraseña viaja y se puede adivinar por fuerza bruta. La clave privada es criptográficamente más fuerte y no transmitís un secreto reutilizable en cada conexión. Para producción, la guía es clara: clave privada. Esto se conecta con lo que analizamos en enviar notificaciones a Slack.
El setup mínimo es este: generás el par con ssh-keygen -t ed25519, copiás la pública a ~/.ssh/authorized_keys del remoto y ajustás permisos con chmod 700 ~/.ssh y chmod 600 ~/.ssh/authorized_keys. Si SSH ve permisos demasiado abiertos, ignora la clave y no te conecta, aunque todo lo demás esté perfecto.
Errores comunes al usar SSH en n8n
- Clave en formato equivocado: pegar una clave PuTTYgen (BEGIN RSA PRIVATE KEY) en vez de OpenSSH. Convertila primero según la doc oficial del nodo SSH.
- Permisos flojos en ~/.ssh: sin el
chmodcorrecto, el server rechaza la clave sin decirte por qué. Revisá 700 en la carpeta y 600 en authorized_keys. - Confundir pull con push: terminás bajando cuando querías subir. Leé dos veces qué operación elegiste.
- No mirar stderr ni exit code: das por exitoso un comando que en realidad falló. Sumá un IF que chequee exit code 0.
- Host key sin verificar: la primera conexión a un host nuevo puede frenarse por la verificación de host key. Configurala de entrada para que el workflow no quede colgado.
Ejemplos de flujos con SSH en n8n
Deploy con webhook. Un webhook de GitHub dispara el workflow, el nodo SSH corre git pull && npm install && systemctl restart app en producción, y al final mandás una notificación a Slack con el resultado del stdout.
Backup programado. Un trigger cada 24 horas hace pull de /var/log/app.log, procesás el archivo dentro del workflow, hacés push del resultado a otra ruta y cerrás con un email de reporte. Todo sin tocar el server a mano.
Health check. Cada 5 minutos ejecutás systemctl is-active nginx postgres en tus servers, y si el exit code no es 0, disparás una alerta y un auto-restart antes de que se entere el usuario. Relacionado: instalar n8n con Docker.
Preguntas Frecuentes
¿Qué es el nodo SSH de n8n?
Es un nodo core de n8n que abre una conexión SSH con un servidor Linux remoto para ejecutar comandos shell y transferir archivos desde un workflow. Soporta tres operaciones: correr un comando, descargar un archivo (pull) y subir un archivo (push), todas con la misma credencial.
¿Cómo ejecuto un comando en un servidor remoto con n8n?
Agregás el nodo SSH con la operación de comando, cargás la credencial y escribís el string de shell en el campo de comando, por ejemplo systemctl restart nginx. El nodo devuelve stdout, stderr y exit code para que valides el resultado en los pasos siguientes.
¿Qué formato de clave privada acepta n8n?
n8n espera la clave privada en formato OpenSSH. Si generaste una RSA con PuTTYgen que empieza con -----BEGIN RSA PRIVATE KEY-----, tenés que convertirla a OpenSSH antes de pegarla, o la credencial no va a validar.
¿Cuál es la diferencia entre auth por contraseña y por clave privada?
La auth por contraseña es más simple pero vulnerable a fuerza bruta y transmite un secreto reutilizable. La auth por clave privada es criptográficamente más segura y es la recomendada para producción, porque no envía una contraseña en cada conexión.
¿Necesito n8n self-hosted para usar el nodo SSH?
Sí, el caso de uso descripto en la guía apunta a n8n self-hosted, donde el nodo SSH corre comandos y mueve archivos contra tus propios servidores Linux sin depender de un pipeline CI externo.
Conclusión
El nodo SSH convierte a n8n en una herramienta de operaciones, no solo de integración entre APIs. Con las tres operaciones (comando, pull y push) armás deploys, backups y health checks visuales sin montar un CI aparte. Dos cosas para no tropezar: usá clave privada en formato OpenSSH para producción, y chequeá siempre el exit code antes de dar por bueno un comando. Si arrancás, hacelo primero contra un server de prueba, mirá el stderr con calma y recién ahí llevalo a producción.
