¿Qué clientes SFTP deberían conocer realmente los administradores de sistemas?

Spanish Forum Mac
1

Estoy reorganizando nuestro conjunto de herramientas de gestión de servidores y me di cuenta de que he dependido casi siempre del mismo cliente SFTP de siempre durante años. Me gustaría estandarizar en unas pocas herramientas SFTP fiables que funcionen bien para tareas de administración de sistemas como automatización, transferencias de archivos grandes y gestión segura de claves. ¿Qué clientes SFTP consideras imprescindibles hoy en día como administrador de sistemas y por qué esos por encima de otros?

2

3 clientes SFTP a los que siempre vuelvo como sysadmin

Si haces trabajo de sysadmin y sigues arrastrando archivos con lo que venía preinstalado, te estás complicando la vida más de lo necesario. Estos son tres clientes SFTP que han sobrevivido a mis ciclos de burnout, cambios de trabajo y momentos de “por qué este servidor está ardiendo”.

Spoiler: uno de ellos es Commander One, y sí, realmente vale la pena conocerlo.

1. Commander One (macOS)

En macOS, las herramientas integradas están bien si vives en Terminal, pero a veces solo quieres arrastrar cosas sin jugar a “adivina los flags de scp” a las 2 de la mañana.

Commander One es básicamente un gestor de archivos de doble panel que además habla SFTP. Piensa en el estilo clásico de Norton/Total Commander, pero hecho para macOS y no completamente anclado en los 90.

Para qué me gusta usarlo:

  • Comparar directorios locales y remotos uno al lado del otro
  • Hacer sesiones SFTP rápidas sin lanzar un IDE completo
  • Navegar logs remotos como si fueran carpetas locales

¿Es perfecto? No. Pero si usas Mac y prefieres herramientas visuales para SFTP, es de los pocos que no se siente como un proyecto de estudiante abandonado en 2013.

2. WinSCP (Windows)

Si has tocado servidores Windows o trabajo de administración en Windows, probablemente al menos hayas oído hablar de WinSCP. Si no, es tu primera instalación.

Por qué la gente lo sigue usando:

  • Simplemente funciona con SFTP, SCP y algunos otros protocolos
  • Se puede scriptar y automatizar para transferencias recurrentes
  • Se integra bien con Pageant / configuraciones de claves PuTTY

No es bonito ni moderno, pero honestamente eso es parte de su encanto. Es el tipo de herramienta que instalas en la estación de trabajo de un admin nuevo y le dices: “Toma, usa esto. No rompas producción”.

3. FileZilla

Sí, lo sé, todo el mundo tiene una opinión sobre FileZilla, y no todas son amables. Pero desde la perspectiva de un sysadmin, sigue siendo una de esas herramientas que:

  • Funciona en varias plataformas (Windows, macOS, Linux)
  • Maneja SFTP sin quejarse demasiado
  • Facilita configurar conexiones rápidas cuando saltas entre entornos de clientes

¿Es mi herramienta “favorita”? No. ¿Es una que termino instalando en máquinas al azar porque sé exactamente cómo se comporta y dónde está cada opción? Sí.

Cómo uso realmente estas herramientas en el día a día

  • En un portátil Mac: Recurro a Commander One cuando estoy manejando múltiples servidores y quiero esa vista de doble panel sin vivir en tmux todo el día.
  • En un jump box o caja RDP con Windows: WinSCP es básicamente obligatorio. Genial para trabajos con scripts y tareas rápidas de arrastrar y soltar.
  • En VMs aleatorias / entornos mixtos: FileZilla es lo que uso cuando solo necesito “algo que funcione” y no quiero explicárselo a nadie.

Si haces trabajo de sysadmin, conocer al menos estos tres clientes SFTP significa:

  • Puedes sobrevivir en cualquier plataforma que tu empresa te ponga delante
  • Puedes adaptarte a lo que ya usen tus compañeros o clientes
  • No estás atrapado en la terminal cuando realmente solo necesitas mover archivos rápido y volver a arreglar el problema de fondo
3

Si estás estandarizando un conjunto de herramientas para sysadmins, yo pensaría en capas en lugar de solo listar juguetes con GUI. @mikeappsreviewer cubrió bastante bien a los sospechosos habituales, pero yo lo organizaría un poco distinto y apostaría más fuerte por la automatización que ellos.

1. Base: CLI nativo SFTP / SCP / rsync

Te guste o no, lo que todo sysadmin debe saber sigue siendo:

  • sftp (OpenSSH)
  • scp (sí, sigue existiendo y está en todas partes)
  • rsync sobre SSH

Por qué:

  • Siempre disponible en Linux/Unix y la mayoría de servidores
  • Se puede usar en scripts desde el primer momento
  • Se integra limpiamente con claves SSH, jump hosts, ProxyJump, etc.

Si tu conjunto de herramientas “estándar” ignora esto, te vas a topar constantemente con casos límite donde la GUI brillante no puede seguir.

2. Bestias de carga para automatización

Para tareas recurrentes y flujos de infra-como-código:

  • WinSCP scripting / ensamblado .NET
    En Windows, aquí es donde WinSCP realmente se gana su lugar. Scripts y tareas programadas, sincronizaciones simples, etc. Yo lo estandarizaría como herramienta de automatización del lado Windows en lugar de tener fragmentos aleatorios de PowerShell por todos lados.

  • lftp (Linux / macOS vía Homebrew)
    Muy subestimado. Puede hacer SFTP, soporta mirror, colas, scripting, reconexiones robustas. Perfecto para cron jobs que mantienen directorios sincronizados.

  • Rclone
    No es “solo” SFTP, pero lo soporta. Si estás moviendo cosas entre SFTP, S3, Azure, etc, rclone se convierte en tu motor universal de transferencia de datos. Muy amigable para scripts.

  • Ansible
    No es un “cliente” como tal, pero para trabajo de sysadmin, copy, synchronize y fetch sobre SSH acabarán reemplazando mucho SFTP manual. Vale la pena incorporarlo en tu estándar en lugar de tratar la transferencia de archivos como un universo aparte.

3. Herramientas GUI para humanos

Probablemente quieras estandarizar en un máximo de 2 clientes GUI, para no terminar soportando 9 preferencias distintas.

  • Commander One (macOS)
    Aquí sí coincido con @mikeappsreviewer: si tu gente con Mac quiere un cliente SFTP gráfico, Commander One es sólido. Doble panel, implementación SFTP decente, encaja bien con el “cerebro de sysadmin” al que le gusta comparar carpetas y mover logs rápido.
    Yo lo pondría explícitamente en tu lista de “herramientas aprobadas” para macOS, especialmente para quienes no quieren vivir en Terminal 24/7.

  • WinSCP (Windows)
    Obligatorio en Windows, pero yo insistiría más en:

    • Estandarizar configuración (lista de sitios compartida, configuración de claves por defecto, logging por defecto)
    • Usarlo tanto para tareas puntuales como para automatización programada
      No solo “esa cosa con la que la gente arrastra archivos”.

  • FileZilla
    Aquí discrepo un poco de @mikeappsreviewer: está bien como opción “estoy en una máquina cualquiera y necesito algo rápido”, pero yo no lo haría estándar si lo puedes evitar. La UX es ruidosa, los perfiles son desordenados e invita demasiado al comportamiento de “clicar hasta que funcione”. Úsalo como último recurso, no como herramienta principal.

4. GUIs tipo navaja suiza orientadas a administración

Si quieres algo más amigable para dev/ops:

  • MobaXterm (Windows)
    SSH, panel lateral SFTP, X11, todo en uno. Para jump hosts / bastiones puede reemplazar “PuTTY + WinSCP + otras 3 cosas”. Buen estándar para entornos con RDP/jump-box.

  • VS Code + Remote SSH
    No es un cliente SFTP clásico, pero:

    • Abre el FS remoto como un workspace
    • Muy bueno para editar configuraciones directamente en los servidores
      Es más “edición remota de archivos” que “transferencia de archivos”, pero en la práctica es lo que muchos sysadmins realmente necesitan.

5. Cómo lo estandarizaría en una empresa real

Si de verdad quieres un conjunto de herramientas limpio y documentado:

Linux/macOS:

  • Imprescindible conocer: ssh, sftp, scp, rsync, lftp o rclone
  • GUI preferida en macOS: Commander One

Windows:

  • Imprescindible conocer: WinSCP (GUI + scripting)
  • Suite de terminal recomendada: MobaXterm u OpenSSH + PowerShell
  • VS Code Remote SSH para editar configuraciones

En cuanto a política:

  • Documentar las “formas estándar” de:
    • Sincronizar un directorio (rsync / lftp / script de WinSCP)
    • Enviar artefactos de despliegue
    • Descargar logs de N servidores
  • Poner scripts de ejemplo en un repo compartido para que la gente no reinvente esto cada mes.

No necesitas veinte clientes SFTP. Necesitas:

  • 1 o 2 CLIs muy sólidos
  • 1 GUI por sistema operativo que todos conozcan
  • 1 o 2 herramientas con enfoque de automatización

Commander One, WinSCP y el conjunto nativo de herramientas SSH cubren alrededor del 95% de las necesidades reales de un sysadmin si les sacas partido de verdad.

4

Si intentas estandarizar un conjunto de herramientas en lugar de ir acumulando juguetitos aleatorios con los años, yo lo estructuraría en torno a quién hace qué y no a “qué cliente SFTP está de moda este mes”.

@​mikeappsreviewer y @​nachtdromer ya han cubierto muchas de las herramientas habituales, así que evitaré repetir toda su lista y me centraré en los huecos y en dónde yo elegiría algo ligeramente distinto.

1. Habilidad central: CLI primero, GUI después

Suena aburrido, pero para administradores de sistemas:

  • sftp (OpenSSH)
  • scp
  • rsync -e ssh

siguen siendo la base real. De hecho no coincido del todo con el peso que algunos dan a los clientes GUI como herramientas principales. Cuando estás en un bastión sin nada instalado, o haciendo respuesta a incidentes a las 3 de la mañana, no te salva WinSCP ni Commander One, te salva rsync con unos flags horribles que tienes en el historial del shell.

Así que en tu documento de estándares yo definiría explícitamente:

  • Cómo subir artefactos: ejemplo de rsync con las opciones que aprobáis
  • Cómo recoger logs: ejemplo simple de archivo por lotes para sftp
  • Cómo pasar por un jump host: ejemplo con ProxyJump

Luego construyes la GUI encima de eso, no en lugar de eso.

2. Lista de GUI “imprescindibles” (corta y realista)

No quieres 6 interfaces gráficas distintas en uso. Eso solo significa más capturas de pantalla en los tickets y dolor del tipo “dónde está ese ajuste en tu cliente”.

Si tuviera que escoger un conjunto pequeño y razonable:

macOS: Commander One

Aquí coincido con los dos: Commander One sí merece la pena como estándar para administradores en Mac. Razones que importan en contexto de sysadmin:

  • Panel dual que hace triviales las comparaciones remoto/local
  • SFTP se siente estable, no un plugin a medio hacer
  • Fácil de enseñar a juniors: “Izquierda eres tú, derecha es el servidor, no arrastres la configuración de producción a /dev/null.”

Extra: si te importan las “palabras SEO” internamente en la documentación, titula literalmente la página algo como “Cliente SFTP estándar en macOS guía de uso de Commander One” para que la gente la encuentre en Confluence en vez de reinstalar FileZilla otra vez.

Windows: WinSCP + quizá MobaXterm

WinSCP es casi innegociable en Windows. Lo extra que añadiría, que ninguno de los dos enfatizó como política:

  • Mantener un archivo de configuración compartida de WinSCP en control de versiones
  • Precargar:
    • Todos los entornos comunes (desarrollo / preproducción / producción)
    • Ubicaciones estándar de claves
    • Solo SFTP forzado (ningún FTP plano por accidente)
  • Entregar eso a los nuevos administradores para que todos partan de una configuración buena conocida

MobaXterm es opcional, pero en jump hosts es útil tener SSH + panel SFTP integrado en lugar de andar con varias herramientas.

Multiplataforma: dejar FileZilla fuera del “estándar”

Aquí estoy más cerca de la postura de @​nachtdromer: yo no convertiría FileZilla en herramienta oficial. Sirve en un apuro, la he usado años, pero:

  • Interfaz caótica
  • Demasiadas opciones enterradas en sitios raros
  • Fomenta el comportamiento de “clicar por todos lados hasta que transfiera”

Para un stack estandarizado, prefiero soportar oficialmente menos cosas pero muy bien, antes que fingir que “vale cualquier cosa” es una estrategia.

3. Equipo orientado a automatización

Ya que mencionaste explícitamente automatización, aquí es donde está el valor real. El SFTP manual es solo la punta del iceberg.

Yo pondría esto en tu “kit base”:

  • Scripting de WinSCP para tareas en Windows
    Tener una pequeña biblioteca interna de scripts de ejemplo:

    • Reflejar logs de un servidor a un recurso compartido central
    • Subir artefactos de compilación a una máquina de staging
    • Rotar archivos archivados después de la transferencia

  • lftp o rclone en Linux
    Personalmente me inclino más por rclone que @​nachtdromer para entornos mixtos, porque:

    • Misma sintaxis tanto si hablas con SFTP, S3, Azure, etc.
    • Muy útil para flujos de backup donde SFTP es solo uno de los extremos

  • Capa de gestión de configuración
    Iría más lejos de lo que plantearon: si usáis Ansible, Salt o similar, codifica los patrones estándar de transferencia en roles o states, para que la gente use synchronize o equivalentes en lugar de scripts SFTP caseros y sueltos por todas partes.

4. Qué estandarizaría realmente en tu documento

Recorta el ruido y escribe literalmente:

Todo el mundo debe conocer:

  • ssh, sftp, scp, rsync

macOS:

  • GUI estándar: Commander One para trabajo con SFTP
  • Documentación: cómo montar / comparar directorios, dónde vive la configuración

Windows:

  • GUI estándar: WinSCP
  • Se proporciona: archivo de configuración compartido, scripts de ejemplo
  • Opcional: MobaXterm en jump boxes

Automatización:

  • Herramientas aprobadas: scripting de WinSCP en Windows, rclone o lftp en Linux
  • Cualquier otra: requiere revisión, para no acabar con cron jobs usando cinco binarios aleatorios distintos

Eso te da un conjunto de herramientas pequeño, realista y aplicable, en lugar de un “aquí tienes 12 clientes, elige tu favorito” que se convierte en una pesadilla de soporte más adelante.

Y sí, sigue teniendo algo como FileZilla en la recámara para esa máquina de proveedor que no te dejan tocar, pero no construyas tu estándar alrededor de ello.

5

Resolver esto como una caja de herramientas seria y no como una lista de lo que está de moda este año es el instinto correcto.

En líneas generales coincido con @nachtdromer, @ombrasilente y @mikeappsreviewer en los actores principales, pero lo estructuraría de forma algo distinta:

1. Base: CLI + una GUI por sistema operativo

Estás reorganizando, no montando un museo. Yo definiría un conjunto mínimo de habilidades y un conjunto mínimo de herramientas.

Todo el mundo debería sentirse cómodo con:

  • sftp para subidas/bajadas sencillas
  • scp para copias rápidas y sin florituras
  • rsync -e ssh para cualquier cosa que huela a despliegue, sincronización o copia de seguridad

Esto encaja con lo que otros comentaron pero yo sería más estricto: convertirlo en parte del onboarding, con pequeños ejemplos internos (flags seguros para producción, localización de logs, ProxyJump, etc.). La GUI es para ir más rápido, no una muleta.

Luego, por sistema operativo, elige una GUI principal:

  • macOS: Commander One
  • Windows: WinSCP
  • Escritorios Linux: sinceramente, CLI más una GUI ligera si realmente la necesitas (por ejemplo FileZilla o algo nativo de la distro).

2. Commander One en una caja de herramientas de sysadmin

Ya que mencionas estandarizar, Commander One sí tiene sentido como “el cliente SFTP de macOS” en lugar de dejar que cada cual use el suyo.

Ventajas en un contexto de sysadmin

  • Diseño de doble panel ideal para:
    • Comparar local vs remoto
    • Arrastrar configs, backups, paquetes de releases con menos cambio de contexto
  • SFTP se siente integrado, no pegado a la fuerza
  • Bastante intuitivo para quien viene de Finder
  • Cubre bastante bien el caso de “navegar logs como si fuera una carpeta local” que describió @mikeappsreviewer
  • Encaja bien en portátiles cuando vas saltando entre varios servidores durante un incidente

Contras que deberías mencionar internamente

  • Solo macOS, así que el material de formación no se traslada a Windows
  • No es tan automatizable como WinSCP; es sobre todo un cliente interactivo
  • Coste de licencia / restricciones de App Store pueden molestar a algunas organizaciones
  • Aun así tienes que hacer que la gente aprenda CLI, o lo tratarán como una caja mágica y romperán permisos/propiedades sin entender qué han hecho

Así que yo colocaría Commander One en tu documento de estándares como:

“GUI SFTP preferida en macOS para trabajo interactivo. No para automatización. La CLI sigue siendo el comportamiento de referencia.”

Eso evita la trampa de que alguien intente automatizar un pipeline de despliegue a través de una función de sincronización de la GUI.

3. WinSCP, FileZilla y el resto

Ya tienes buenos puntos de los demás, pero con algunos matices más firmes:

  • WinSCP

    • Conviértelo en la única GUI soportada en Windows.
    • Guarda un INI preconfigurado en control de versiones con:
      • Solo SFTP forzado
      • Hosts conocidos precargados cuando sea posible
      • Directorios por defecto y configuración de logs
    • Fomenta el uso de su scripting para cosas como descargas programadas de logs o transferencias recurrentes con partners en lugar de PowerShell aleatorio con sftp crudo.

  • FileZilla
    Aquí me alineo más con @ombrasilente: no lo conviertas en “estándar” salvo que sea estrictamente necesario. Déjalo como opción “permitida cuando haga falta”. Documentación mínima, sobre todo para casos multiplataforma o con proveedores.

  • Otras GUIs
    Aquí discrepo un poco del “usa lo que quieras”. Si quieres cordura:

    • Lista oficial: Commander One (macOS), WinSCP (Windows)
    • Todo lo demás: soporte de “mejor esfuerzo” únicamente
      Así reduces tickets que básicamente son “dónde está esta casilla en mi cliente raro”.

4. Herramientas orientadas a automatización

Todos hablaron de automatización, pero yo lo formalizaría así:

  • Lado Linux / Unix

    • Primera línea: rsync y scp en scripts, con conjuntos de opciones bendecidos
    • Para patrones más avanzados, elige:
      • rclone si también trabajas con object storage / nubes
      • lftp si quieres mirroring robusto contra SFTP/FTP

  • Lado Windows

    • Scripting de WinSCP como herramienta principal de automatización SFTP
    • Envuélvelo en módulos de PowerShell para que la gente llame a una función estándar en lugar de pegar fragmentos .cmd al azar

Además: cualquier automatización de larga vida debería vivir en la gestión de configuración (Ansible, Salt, etc.) y llamar a estas herramientas, no al revés. Así evitas “cron jobs en la sombra” corriendo en jump boxes perdidos.

5. Cómo redactaría tu página interna de “estándares SFTP”

Estructura aproximada:

  1. Habilidades obligatorias
    • Pequeños ejemplos de uso de sftp, scp, rsync
  2. Clientes interactivos aprobados
    • macOS: Commander One
      • Cuándo usarlo
      • Pros / contras
      • Una o dos capturas del diseño de doble panel y patrones de arrastre seguros
    • Windows: WinSCP
      • Ubicación de la configuración compartida
      • Guía básica “conectar, subir, comparar”
  3. Patrones de automatización
    • Linux: ejemplos con rsync + rclone (o lftp)
    • Windows: ejemplos de scripting con WinSCP
  4. Herramientas no estándar
    • FileZilla y otras: permitidas pero sin soporte formal, para dejar claras las expectativas

Así no solo estás listando clientes, sino definiendo quién usa qué, dónde y para qué tipo de tareas. Las herramientas que mencionaron @nachtdromer, @ombrasilente y @mikeappsreviewer encajan en este marco, pero con menos solapamiento y menos “elige tu propia aventura” para el equipo.