Welche SFTP-Clients sollten Systemadministratoren wirklich kennen?

German Forum Mac
1

Ich organisiere gerade unser Server-Management-Toolkit neu und habe gemerkt, dass ich seit Jahren größtenteils auf denselben alten SFTP-Client setze. Ich möchte ein paar zuverlässige SFTP-Tools standardisieren, die sich gut für typische Sysadmin-Aufgaben wie Automatisierung, große Dateiübertragungen und sichere Schlüsselverwaltung eignen. Welche SFTP-Clients hältst du heute als Sysadmin für unverzichtbar, und warum genau diese im Vergleich zu anderen?

2

3 SFTP‑Clients, zu denen ich als Sysadmin immer wieder zurückkehre

Wenn du Sysadmin‑Arbeit machst und Dateien immer noch mit dem vorinstallierten Kram hin‑ und herschiebst, machst du dir das Leben unnötig schwer. Hier sind drei SFTP‑Clients, die meine Burnout‑Phasen, Jobwechsel und „Warum brennt dieser Server?“‑Momente überlebt haben.

Spoiler: Einer davon ist Commander One, und ja, den sollte man tatsächlich kennen.

1. Commander One (macOS)

Unter macOS sind die eingebauten Tools okay, wenn du im Terminal lebst, aber manchmal willst du einfach nur Sachen hin‑ und herziehen, ohne um 2 Uhr morgens „rate die scp‑Flags“ zu spielen.

Commander One ist im Grunde ein zweispaltiger Dateimanager, der zufällig auch SFTP spricht. Stell dir alte Norton/Total‑Commander‑Vibes vor, aber für macOS gebaut und nicht komplett in den 90ern stecken geblieben.

Dafür nutze ich es gern:

  • Lokale und entfernte Verzeichnisse nebeneinander vergleichen
  • Schnelle einmalige SFTP‑Sessions, ohne gleich eine IDE hochzufahren
  • Entfernte Logs durchsuchen, als wären es lokale Ordner

Ist es perfekt? Nein. Aber wenn du Mac benutzt und visuelle Tools für SFTP bevorzugst, ist es eines der wenigen, das sich nicht wie ein verlassenes Studentenprojekt von 2013 anfühlt.

2. WinSCP (Windows)

Wenn du jemals Windows‑Server oder Windows‑Admin‑Kram angefasst hast, hast du zumindest schon von WinSCP gehört. Wenn nicht, ist das deine erste Installation.

Warum Leute es weiterhin benutzen:

  • Funktioniert einfach mit SFTP, SCP und ein paar anderen Protokollen
  • Skript‑ und automatisierbar für wiederkehrende Transfers
  • Integriert sich gut mit Pageant‑/PuTTY‑Key‑Setups

Es ist weder schick noch modern, aber das ist irgendwie Teil des Charmes. Das ist das Tool, das du einem neuen Admin auf den Rechner wirfst und sagst: „Hier, nimm das. Mach nur bitte nicht die Produktion kaputt.“

3. FileZilla

Ja, ich weiß, jeder hat eine Meinung zu FileZilla, und nicht alle sind freundlich. Aber aus Sysadmin‑Sicht ist es immer noch eines dieser Tools, das:

  • Auf mehreren Plattformen läuft (Windows, macOS, Linux)
  • SFTP ohne großes Gemecker handhabt
  • Es leicht macht, schnelle Verbindungen einzurichten, wenn du zwischen Kundenumgebungen hin‑ und herspringst

Ist es mein „Lieblingstool“? Nein. Ist es eins, das ich auf irgendwelchen Maschinen installiere, weil ich genau weiß, wie es sich verhält und wo jede Option sitzt? Ja.

Wie ich diese Tools im Alltag tatsächlich nutze

  • Auf einem Mac‑Laptop: Ich greife zu Commander One, wenn ich mehrere Server jongliere und die Zweifenster‑Ansicht will, ohne den ganzen Tag in tmux zu leben.
  • Auf einer Windows‑Jump‑Box oder RDP‑Box: WinSCP ist im Grunde Pflicht. Super für Skript‑Jobs und schnelle Drag‑and‑Drop‑Aktionen.
  • Auf beliebigen VMs / gemischten Umgebungen: FileZilla nutze ich, wenn ich einfach „irgendwas Funktionierendes“ brauche und niemandem lange erklären will, wie es geht.

Wenn du als Sysadmin arbeitest, bedeutet es, diese drei SFTP‑Clients zu kennen:

  • Du überlebst auf jeder Plattform, die dein Arbeitgeber dir vor die Füße wirft
  • Du kannst dich an das anpassen, was Kollegen oder Kunden bereits nutzen
  • Du hängst nicht im Terminal fest, wenn du eigentlich nur schnell Dateien verschieben und dann wieder das eigentliche Problem lösen musst
3

Wenn du ein Toolkit für Sysadmins standardisieren willst, würde ich eher in Schichten denken als einfach eine Liste von GUI-Tools aufzustellen. @mikeappsreviewer hat die üblichen Verdächtigen ziemlich gut abgedeckt, aber ich würde das etwas anders strukturieren und deutlich stärker auf Automatisierung setzen als er.

1. Basis: Native CLI SFTP / SCP / rsync

Ob man es mag oder nicht, das, was jeder Sysadmin unbedingt können muss, ist nach wie vor:

  • sftp (OpenSSH)
  • scp (ja, immer noch im Einsatz, überall)
  • rsync über SSH

Warum:

  • Immer verfügbar auf Linux/Unix und den meisten Servern
  • Von Haus aus skriptfähig
  • Integriert sich sauber mit SSH-Keys, Jump Hosts, ProxyJump usw.

Wenn dein „Standard“-Toolkit diese Sachen ignoriert, wirst du ständig an Randfälle stoßen, bei denen das schicke GUI-Tool nicht mehr mitkommt.

2. Automatisierungs-Arbeitspferde

Für wiederkehrende Aufgaben und Infrastructure-as-Code-Workflows:

  • WinSCP Scripting / .NET Assembly
    Unter Windows ist das der Bereich, in dem WinSCP wirklich glänzt. Scripting und Task-Scheduler-Jobs, einfache Syncs usw. Ich würde das als Standard für Windows-seitige Automatisierung etablieren, statt überall zufällige PowerShell-Snippets zu haben.

  • lftp (Linux / macOS über Homebrew)
    Stark unterschätzt. Kann SFTP, unterstützt Mirror-Funktionen, Queues, Scripting, robuste Reconnects. Ideal für Cronjobs, die Verzeichnisse synchron halten.

  • Rclone
    Nicht „nur“ SFTP, aber unterstützt es. Wenn du Daten zwischen SFTP, S3, Azure usw. bewegst, wird rclone zum universellen Datentransporter. Sehr skriptfreundlich.

  • Ansible
    Kein „Client“ im klassischen Sinn, aber für Sysadmin-Arbeit werden copy, synchronize und fetch über SSH irgendwann einen großen Teil manueller SFTP-Vorgänge ablösen. Sollte in deinem Standard verankert sein, statt Dateitransfer als eigene Welt zu behandeln.

3. GUI-Tools für Menschen

Du willst wahrscheinlich höchstens 2 GUI-Clients standardisieren, damit du nicht 9 verschiedene Vorlieben supporten musst.

  • Commander One (macOS)
    Hier stimme ich tatsächlich mit @mikeappsreviewer überein: Wenn deine Mac-Leute einen grafischen SFTP-Client wollen, ist Commander One solide. Doppelpaneel, ordentliche SFTP-Implementierung, passt gut zum „Sysadmin-Gehirn“, das Ordner vergleichen und Logs schnell hin- und herschieben will.
    Ich würde es explizit in die Liste der „freigegebenen Tools“ für macOS aufnehmen, besonders für Leute, die nicht 24/7 im Terminal leben wollen.

  • WinSCP (Windows)
    Unter Windows quasi Pflicht, aber ich würde stärker darauf achten:

    • Konfiguration zu standardisieren (gemeinsame Site-Liste, Standard-Key-Setup, Standard-Logging)
    • Es sowohl für Ad-hoc-Einsätze als auch für geplante Automatisierung zu nutzen
      Nicht nur „das Ding, mit dem Leute Dateien rüberziehen“.

  • FileZilla
    Hier gehe ich etwas von @mikeappsreviewer weg: Es ist okay als „Ich sitze an irgendeiner Kiste und brauche schnell was“-Option, aber ich würde es nach Möglichkeit nicht zum Standard machen. Das UX ist laut, Profile sind unaufgeräumt, und es fördert zu sehr das „Rumklicken, bis es irgendwie läuft“. Als Fallback nutzen, nicht als Kernwerkzeug.

4. Admin-orientierte Schweizer-Taschenmesser-GUIs

Wenn du etwas Dev/Ops-freundlicheres willst:

  • MobaXterm (Windows)
    SSH, SFTP-Sidebar, X11, alles in einem. Für Jump Hosts / Bastion Hosts kann das „PuTTY + WinSCP + 3 andere Dinge“ ersetzen. Ein guter Standard für RDP/Jump-Box-Umgebungen.

  • VS Code + Remote SSH
    Kein klassischer SFTP-Client, aber:

    • Öffnet das Remote-Dateisystem wie ein Workspace
    • Hervorragend, um Konfigurationen direkt auf Servern zu bearbeiten
      Es ist eher „Remote-Dateieditierung“ als „Dateitransfer“, aber in der Praxis ist genau das das, was viele Sysadmins tatsächlich brauchen.

5. Wie ich das in einem echten Betrieb standardisieren würde

Wenn du wirklich ein sauberes, dokumentiertes Toolkit willst:

Linux/macOS:

  • Muss man können: ssh, sftp, scp, rsync, lftp oder rclone
  • Bevorzugtes macOS-GUI: Commander One

Windows:

  • Muss man können: WinSCP (GUI + Scripting)
  • Empfohlenes Terminal-Paket: MobaXterm oder OpenSSH + PowerShell
  • VS Code Remote SSH für Config-Editing

Auf der Policy-Ebene:

  • „Standard-Wege“ dokumentieren, wie man:
    • Ein Verzeichnis synchronisiert (rsync / lftp / WinSCP-Script)
    • Deploy-Artefakte verteilt
    • Logs von N Servern einsammelt
  • Beispielskripte in ein gemeinsames Repository legen, damit das nicht jeden Monat neu erfunden wird.

Du brauchst nicht zwanzig SFTP-Clients. Du brauchst:

  • 1 oder 2 absolut robuste CLIs
  • 1 GUI pro OS, die alle kennen
  • 1 oder 2 Tools mit Automatisierungsfokus

Commander One, WinSCP und das native SSH-Toolset decken etwa 95 % der realen Sysadmin-Anforderungen ab, wenn man sie konsequent nutzt.

4

Wenn du versuchst, ein standardisiertes Toolkit aufzubauen statt über Jahre zufällig Werkzeuge zu sammeln, würde ich es eher um wer macht was herum strukturieren als um „welcher SFTP Client ist diesen Monat angesagt“.

@​mikeappsreviewer und @​nachtdromer haben schon viele der üblichen Tools genannt, deshalb wiederhole ich ihre Liste nicht komplett und konzentriere mich auf Lücken bzw. Punkte, an denen ich mich leicht anders entscheiden würde.

1. Kernkompetenz: CLI zuerst, GUI danach

Das klingt langweilig, aber für Sysadmins sind

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

immer noch die echte Basis. Ich bin auch nicht ganz einverstanden damit, wie viel Gewicht manche Leute GUI Clients als primäre Tools geben. Wenn du auf einem Bastion Host ohne zusätzliche Software sitzt oder um 3 Uhr morgens Incident Response machst, rettet dich nicht WinSCP oder Commander One, sondern rsync mit ein paar hässlichen Flags in deiner Shell History.

In deinem Standards Dokument würde ich daher explizit definieren:

  • Wie Artefakte gepusht werden: rsync Beispiel mit von euch freigegebenen Optionen
  • Wie Logs gezogen werden: einfaches sftp Batchfile Beispiel
  • Wie man über einen Jump Host geht: ProxyJump Beispiel

Darauf baust du die GUI auf, nicht andersherum.

2. GUI „Must know“ Liste (kurz und realistisch)

Du willst keine 6 verschiedenen GUIs im Einsatz haben. Das bedeutet nur mehr Screenshots in Tickets und den Schmerz von „wo ist diese Einstellung in deinem Client?“.

Wenn ich ein kleines, sinnvolles Set wählen müsste:

macOS: Commander One

Hier stimme ich mit beiden überein: Commander One lohnt sich tatsächlich als Standard für Mac Admins. Gründe, die im Sysadmin Kontext zählen:

  • Dual Pane macht Remote/Local Vergleiche trivial
  • SFTP wirkt stabil, nicht wie ein halbgarer Zusatz
  • Schnelle Einarbeitung für Juniors: „Links bist du, rechts ist der Server, zieh bitte keine Produktivkonfiguration nach /dev/null.“

Bonus: wenn ihr intern in euren Dokus auf „SEO Wörter“ achtet, nennt die Seite buchstäblich so etwas wie „Standard macOS SFTP Client Commander One Einsatz Leitfaden“, damit Leute sie in Confluence auch wirklich finden, statt wieder FileZilla zu installieren.

Windows: WinSCP + eventuell MobaXterm

WinSCP ist unter Windows fast nicht verhandelbar. Das zusätzliche, das ich als Policy noch betonen würde:

  • Eine gemeinsame WinSCP Konfigurationsdatei in der Versionsverwaltung pflegen
  • Vorab eintragen:
    • Alle üblichen Umgebungen (Dev / Stage / Prod)
    • Standard Speicherorte für Keys
    • Erzwinge SFTP only (keine versehentlichen Plain FTP Verbindungen)
  • Diese Datei an neue Admins ausgeben, damit alle von einer bekannten, guten Konfiguration starten

MobaXterm ist optional, aber auf Jump Hosts ist es angenehm, integriertes SSH + SFTP Sidebar zu haben statt mehrere Tools zu jonglieren.

Cross Plattform: FileZilla nicht mehr als „Standard“

Hier bin ich näher bei @​nachtdromer: Ich würde FileZilla nicht mehr als offiziell freigegebenes Tool führen. Es ist im Notfall okay, ich habe es jahrelang benutzt, aber:

  • UI Chaos
  • Zu viele Einstellungen an seltsamen Stellen versteckt
  • Fördert zufälliges „rumklicken bis es irgendwie überträgt“ Verhalten

Für einen standardisierten Stack unterstütze ich lieber weniger Tools richtig gut, als mir einzureden, dass „alles ist erlaubt“ eine Strategie wäre.

3. Automationsfokussierte Werkzeuge

Da du explizit Automatisierung erwähnt hast, liegt hier der eigentliche Wert. Manuelles SFTP ist nur die Spitze des Eisbergs.

Ich würde Folgendes in deine „Toolkit Basis“ aufnehmen:

  • WinSCP Scripting für Windows Jobs
    Haltet eine kleine interne Bibliothek mit Beispielscripten bereit:

    • Logs von einem Server auf ein zentrales Share spiegeln
    • Build Artefakte auf eine Staging Maschine hochladen
    • Archivdateien nach dem Transfer rotieren

  • lftp oder rclone auf Linux
    Persönlich tendiere ich stärker zu rclone als @​nachtdromer für gemischte Umgebungen, weil:

    • Gleiche Syntax, egal ob du mit SFTP, S3, Azure usw. sprichst
    • Sehr praktisch für Backup Workflows, in denen SFTP nur eine Seite ist

  • Konfigurationsmanagement Ebene
    Ich würde weitergehen als sie: wenn ihr Ansible / Salt / ähnliches nutzt, kodifiziert Standard Transfermuster in Rollen oder States, damit Leute synchronize oder ähnliche Bausteine verwenden, statt überall eigene SFTP Scripte zusammen zu basteln.

4. Was ich in deinem Dokument tatsächlich standardisieren würde

Streich den Lärm und schreibe im Wortlaut ungefähr:

Jede Person muss beherrschen:

  • ssh, sftp, scp, rsync

macOS:

  • Standard GUI: Commander One für SFTP Arbeiten
  • Doku: wie man Verzeichnisse mountet / vergleicht, wo die Config liegt

Windows:

  • Standard GUI: WinSCP
  • Bereitgestellt: gemeinsame Konfigurationsdatei, Beispiel Scripte
  • Optional: MobaXterm auf Jump Hosts

Automatisierung:

  • Genehmigte Tools: WinSCP Scripting auf Windows, rclone oder lftp auf Linux
  • Alles andere: nur nach Review, damit ihr nicht mit Cronjobs endet, die fünf verschiedene zufällige Binaries verwenden

So bekommst du ein kleines, realistisches, durchsetzbares Toolkit, statt einer „hier sind 12 Clients, such dir deinen Favoriten aus“ Situation, die später zum Support Albtraum wird.

Und ja, behalte so etwas wie FileZilla für den einen Vendor Rechner in der Hinterhand, an den du nicht ran darfst, aber bau deinen Standard nicht darum herum.

5

Das Ganze eher wie einen pragmatischen Werkzeugkasten als wie eine „Was ist dieses Jahr angesagt“-Liste zu sortieren, ist genau der richtige Instinkt.

In den Kernpunkten stimme ich @nachtdromer, @ombrasilente und @mikeappsreviewer weitgehend zu, aber ich würde es etwas anders strukturieren:

1. Basis: CLI + ein GUI pro Betriebssystem

Ihr räumt auf, ihr baut kein Museum. Ich würde ein Mindest-Skillset und ein Mindest-Toolset definieren.

Womit alle vertraut sein sollten:

  • sftp für einfache Uploads / Downloads
  • scp für schnelle, unkomplizierte Kopien
  • rsync -e ssh für alles, was nach Deployment, Sync oder Backup aussieht

Das deckt sich mit dem, was andere gesagt haben, aber ich wäre strenger: Macht das zum festen Bestandteil des Onboardings, mit kurzen internen Beispielen (prod-sichere Flags, Log-Pfade, ProxyJump usw.). GUI ist für Geschwindigkeit da, nicht als Krücke.

Dann pro OS genau ein primäres GUI auswählen:

  • macOS: Commander One
  • Windows: WinSCP
  • Linux-Desktops: ehrlich gesagt CLI plus ein leichtgewichtiges GUI, wenn es wirklich sein muss (z. B. FileZilla oder etwas Distro-Eigenes).

2. Commander One im Sysadmin-Werkzeugkasten

Da du Standardisierung ansprichst, ergibt Commander One tatsächlich Sinn als „der macOS-SFTP-Client“, statt jeden machen zu lassen, was er will.

Vorteile im Sysadmin-Kontext

  • Zwei-Fenster-Layout ist ideal für:
    • Vergleich Lokal vs. Remote
    • Drag & Drop von Configs, Backups, Release-Bundles mit weniger Kontextwechsel
  • SFTP wirkt integriert, nicht drangetackert
  • Relativ intuitiv für Leute, die von Finder kommen
  • Deckt das „Logs wie lokale Ordner durchstöbern“-Szenario, das @mikeappsreviewer beschrieben hat, ziemlich gut ab
  • Gut geeignet auf Laptops, wenn man während eines Incidents dauernd zwischen mehreren Servern springt

Nachteile, die intern klar benannt werden sollten

  • Nur macOS, Schulungsmaterial ist nicht 1:1 auf Windows übertragbar
  • Nicht so gut skriptbar wie WinSCP; primär ein interaktiver Client
  • Lizenzkosten / App-Store-Eigenheiten können manche Unternehmen nerven
  • CLI müssen die Leute trotzdem lernen, sonst behandeln sie das Tool als Blackbox und verhunzen Rechte/Eigentümer, ohne zu verstehen, was passiert ist

Ich würde Commander One in eurer Standard-Doku so positionieren:

„Bevorzugtes macOS-SFTP-GUI für interaktives Arbeiten. Nicht für Automation. CLI bleibt Referenzverhalten.“

So vermeidet ihr, dass jemand versucht, einen Deployment-Pipeline über eine GUI-Sync-Funktion zu automatisieren.

3. WinSCP, FileZilla und die anderen

Die anderen haben schon gute Punkte gebracht, ein paar zugespitzte Ergänzungen:

  • WinSCP

    • Zum einzigen offiziell unterstützten GUI unter Windows machen.
    • Eine vorkonfigurierte INI im Versionskontrollsystem ablegen mit:
      • Erzwingung von SFTP-only
      • Vorgefüllten Known-Hosts, wo möglich
      • Voreingestellten Standardverzeichnissen und Log-Optionen
    • Sein Scripting gezielt für Dinge wie geplante Log-Abzüge oder wiederkehrende Partner-Transfers pushen, statt wildem PowerShell + rohem sftp.

  • FileZilla
    Da bin ich näher bei @ombrasilente: Nicht zum „Standard“ machen, außer es geht wirklich nicht anders. Lieber als „wo nötig erlaubt“ einstufen. Minimal dokumentieren, primär für Cross-Plattform- / Vendor-Szenarien.

  • Andere GUI-Clients
    Hier weiche ich vom allgemeinen „nutzt halt, was ihr wollt“-Gefühl etwas ab. Wenn ihr halbwegs Ordnung wollt:

    • Offizielle Liste: Commander One (macOS), WinSCP (Windows)
    • Alles andere: nur „Best-Effort“-Support
      Das reduziert Tickets vom Typ „wo ist dieses eine Häkchen in meinem Exoten-Client“.

4. Tooling mit Fokus auf Automation

Alle haben über Automation gesprochen, ich würde es etwas klarer formalisieren:

  • Linux-/Unix-Seite

    • Erste Wahl: rsync und scp in Skripten, mit freigegebenen Options-Sets
    • Für komplexere Muster entweder:
      • rclone, wenn auch Object-Storage / Cloud eine Rolle spielt
      • lftp, wenn ihr robuste Spiegelungen gegen SFTP/FTP braucht

  • Windows-Seite

    • WinSCP-Scripting als primäres SFTP-Automationstool
    • In PowerShell-Module kapseln, sodass Leute Standardfunktionen aufrufen, statt irgendwelche .cmd-Schnipsel zu kopieren

Außerdem: Dauerhafte Automationen gehören in ein Konfigurationsmanagement (Ansible, Salt etc.) und rufen von dort die Tools auf, nicht umgekehrt. So vermeidet ihr „Schatten-Cronjobs“ auf zufälligen Jump-Hosts.

5. Wie ich eure interne „SFTP-Standards“-Seite schreiben würde

Grobe Struktur:

  1. Verpflichtende Skills
    • Kurze Beispiele für sftp, scp, rsync
  2. Freigegebene interaktive Clients
    • macOS: Commander One
      • Wofür es gedacht ist
      • Vor- und Nachteile
      • Ein, zwei Screenshots vom Zwei-Fenster-Layout und sicheren Drag-Mustern
    • Windows: WinSCP
      • Speicherort der gemeinsamen Config
      • Kurze Anleitung „Verbinden, Hochladen, Vergleichen“
  3. Automationsmuster
    • Linux: Beispiele für rsync + rclone (oder lftp)
    • Windows: Beispiele für WinSCP-Scripting
  4. Nichtstandard-Tools
    • FileZilla und andere: erlaubt, aber nicht offiziell unterstützt, um die Erwartungen klar zu halten

So listet ihr nicht einfach nur Clients auf, sondern definiert, wer was wo wofür benutzt. Die Tools von @nachtdromer, @ombrasilente und @mikeappsreviewer passen alle in diesen Rahmen, aber mit weniger Überschneidung und weniger „Such dir was aus“-Momenten für das Team.