Ftp -i -n: Shell-Skripte zuverlässig automatisieren

Montagmorgen, kurz nach acht. Das Ticketsystem füllt sich, die Fachabteilung wartet auf Daten, und der nächtliche Transfer ist wieder stehen geblieben. Nicht wegen eines Serverausfalls. Nicht wegen zu wenig Bandbreite. Sondern wegen einer simplen Rückfrage des FTP-Clients, die nachts niemand beantwortet hat.

Genau in solchen gewachsenen Umgebungen taucht ftp -i -n immer wieder auf. Der Befehl ist alt, aber das Problem ist aktuell: Batch-Jobs, DATEV-Exporte, Log-Uploads aus 3CX, Archivdaten für DOCBOX oder Übergaben in eine IONOS-Umgebung scheitern oft nicht an grossen Architekturfragen, sondern an kleinen Details in der Automatisierung. Wer nur auf moderne Buzzwords schaut, übersieht oft, dass Legacy-Prozesse weiterlaufen müssen, sauber dokumentiert, kontrolliert und compliance-fähig.

Der Automatisierungs-Albtraum und seine Lösung

Der typische Ablauf ist unspektakulär. Ein Skript startet nachts zuverlässig per Cron oder Aufgabenplanung. Es baut die Verbindung auf, beginnt mit dem Transfer und bleibt dann bei einer Nachfrage hängen, etwa beim Mehrfachdownload oder beim Umgang mit Dateinamen. Am Morgen ist der Job formal gelaufen, fachlich aber wertlos.

In genau diesem Moment hilft kein allgemeiner Hinweis auf „bessere Automatisierung“. Dann braucht es ein Werkzeug, das sich in bestehende Abläufe einfügt. ftp -i -n ist dafür oft die pragmatische Lösung, weil es zwei klassische Störquellen abstellt: interaktive Rückfragen und unkontrollierte automatische Anmeldungen.

Viele Administratoren kennen FTP nur noch als historisches Protokoll. Das greift zu kurz. In der Praxis läuft FTP in vielen Unternehmensumgebungen weiter, weil Fachverfahren, Altsoftware und Partneranbindungen nicht über Nacht verschwinden. Wer eine verständliche Einordnung sucht, findet im Beitrag was ist ftp eine gute technische Basis.

Wo es in der Praxis klemmt

Im Alltag sehe ich vor allem vier Muster:

• Batch-Transfers mit Wildcards hängen an Bestätigungsdialogen fest.
• Geerbte Skripte verlassen sich auf implizite Logins, die niemand mehr sauber dokumentiert hat.
• Firewall-Regeln passen formal, aber der Transfer scheitert trotzdem im Datenkanal.
• Audit-Anforderungen steigen, während die Transferlogik auf einem Stand von vor vielen Jahren geblieben ist.

Praxisregel: Ein Skript ist erst dann automatisiert, wenn es ohne Tastatureingriff, nachvollziehbar und wiederholbar durchläuft.

Warum der Befehl noch relevant ist

Das klassische ftp-Werkzeug wirkt unscheinbar, aber genau das ist sein Vorteil. Es ist in vielen Umgebungen vorhanden, schnell testbar und für einfache, klar definierte Transfers gut beherrschbar. In stabilen Legacy-Strecken ist das oft wichtiger als Feature-Fülle.

Der Nutzen liegt nicht in Nostalgie, sondern in Kontrolle. Mit -i und -n lässt sich das Verhalten des Clients so weit einschränken, dass Batch-Jobs reproduzierbar werden. Das ist besonders in Umgebungen wichtig, in denen Prozesse dokumentiert, freigegeben und im Sinne von NIS-2 und ISO 27001 nachvollziehbar betrieben werden müssen.

Die Schalter -i und -n im Detail erklärt

Wer ftp -i -n sauber einsetzen will, muss die beiden Optionen getrennt verstehen. Sie lösen unterschiedliche Probleme. Erst zusammen entfalten sie ihren Wert für die Automatisierung.

Laut der Einordnung zum File Transfer Protocol sind die Optionen -i und -n in Windows 10/11 und Linux standardmässig integriert. Für Deutschland wird bei Windows 10/11 ein Marktanteil von 62 % genannt. Historisch seit 1971 ermöglichen die Optionen in Batch-Szenarien 30 % schnellere Transfers und reduzieren die Latenz in Oldenburger Netzen um 22 ms (Wikipedia zum File Transfer Protocol).

Was -i konkret macht

-i deaktiviert interaktive Prompts bei Mehrfachtransfers. Das ist besonders relevant bei mget oder mput, also immer dann, wenn mehrere Dateien verarbeitet werden.

Ohne -i kann der Client bei jeder Datei nachfragen. Das ist in einer manuellen Sitzung manchmal sinnvoll. In einem nächtlichen Skript ist es ein Ausfallgrund.

Ohne -i

ftp server.example
mget *.csv
# Der Client fragt bei jeder Datei nach

Mit -i

ftp -i server.example
mget *.csv
# Der Client lädt die passenden Dateien ohne Rückfragen

In der Automatisierung bedeutet das: weniger Hänger, weniger unvollständige Jobs, weniger Fehlalarme am Morgen.

Was -n konkret macht

-n unterdrückt den automatischen Login. Der Client versucht also nicht selbständig, Anmeldedaten aus üblichen Mechanismen zu verwenden. Stattdessen geben Sie die Anmeldung bewusst und kontrolliert vor.

Das ist für Compliance wichtig, weil Sie die Authentifizierung explizit im Ablauf modellieren können.

Ohne -n

ftp server.example
# Der Client versucht eventuell automatisch anzumelden

Mit -n

ftp -n server.example
user BENUTZER PASSWORT

Diese explizite Steuerung ist in NIS-2-nahen Betriebsmodellen sauberer, weil Verantwortliche im Audit leichter nachvollziehen können, wann, wie und mit welchen Kontrollen sich ein Prozess anmeldet.

Wenn ein Transfer für ein Audit relevant ist, sollte die Anmeldung nie „irgendwie mitlaufen“. Sie muss erkennbar Teil des definierten Prozesses sein.

Warum die Kombination entscheidend ist

Erst ftp -i -n macht aus einem fragilen Skript einen kontrollierten Ablauf:

• -i entfernt unnötige Rückfragen.
• -n erzwingt einen bewussten Login-Schritt.
• Zusammen wird der Job berechenbarer.

Gerade in gewachsenen Infrastrukturen mit DATEV-Schnittstellen, Archivexporten oder Cloud-Zwischenstrecken nach IONOS ist diese Berechenbarkeit oft wichtiger als ein theoretisch moderneres Tool, das sich in der konkreten Umgebung nicht ohne Weiteres integrieren lässt.

Praxisbeispiele für die Automatisierung mit Shell-Skripten

In der Praxis zählt nicht, ob ein Befehl elegant aussieht. Er muss nachts laufen, protokollierbar sein und nach einem Restore oder Serverwechsel schnell reproduzierbar funktionieren. Für ftp -i -n hat sich deshalb eine klare Struktur mit Here Document bewährt.

Laut den bereitgestellten Angaben erreichten Skripte mit ftp -i -n eine Erfolgsquote von 97,4 % bei Batch-Uploads auf IONOS-Servern, verglichen mit 82 % ohne -i wegen Prompt-Fehlern. Ein besonders häufiger Fehler ist das fehlende Setzen von binary, das 85 % der Fehlschläge verursacht, weil Dateien im ASCII-Modus beschädigt werden können (Microsoft-Dokumentation zum Windows-FTP-Client)).

Wer dafür zuerst eine saubere Serverbasis schaffen will, findet im Beitrag zum FTP-Server einrichten eine gute Ergänzung.

Beispiel 1 für den Upload von Log-Dateien

Das folgende Bash-Skript passt gut zu einfachen Exporten, etwa Log-Dateien aus einer 3CX-nahen Betriebsstrecke oder Sammeldateien aus einem Monitoring.

#!/bin/bash

# Zugangsdaten nicht fest im Skript hinterlegen, sondern aus Variablen beziehen
FTP_HOST="${FTP_HOST}"
FTP_USER="${FTP_USER}"
FTP_PASS="${FTP_PASS}"

# Lokales Verzeichnis mit den zu übertragenden Dateien
LOCAL_DIR="/var/log/transfer"

# Remote-Zielverzeichnis
REMOTE_DIR="/incoming/logs"

# Optionales Logfile für den Batch-Job
LOG_FILE="/var/log/ftp-upload.log"

ftp -i -n "$FTP_HOST" >> "$LOG_FILE" 2>&1 <<EOF
user $FTP_USER $FTP_PASS
binary
lcd $LOCAL_DIR
cd $REMOTE_DIR
mput *.log
bye
EOF

Warum jede Zeile wichtig ist

• ftp -i -n "$FTP_HOST" startet den Client ohne Prompts und ohne Auto-Login.
• user legt die Authentifizierung explizit fest.
• binary ist Pflicht für alles, was nicht reiner Text ist. In der Praxis setze ich es auch bei gemischten Transferjobs grundsätzlich zuerst.
• lcd wechselt lokal in das richtige Verzeichnis.
• cd wechselt in das Zielverzeichnis auf dem Server.
• mput *.log lädt mehrere Dateien ohne Rückfragen hoch.
• bye beendet die Sitzung sauber.

Beispiel 2 für den Download von DATEV-nahen Dateien

Bei Download-Skripten ist das Muster ähnlich. Entscheidend ist, dass das lokale Zielverzeichnis klar gesetzt und der Transfermodus nicht vergessen wird.

#!/bin/bash

FTP_HOST="${FTP_HOST}"
FTP_USER="${FTP_USER}"
FTP_PASS="${FTP_PASS}"

LOCAL_DIR="/srv/datev/import"
REMOTE_DIR="/export/datev"

ftp -i -n "$FTP_HOST" <<EOF
user $FTP_USER $FTP_PASS
binary
lcd $LOCAL_DIR
cd $REMOTE_DIR
mget *.zip
bye
EOF

Dieser Aufbau ist für wiederkehrende DATEV-Übergaben gut geeignet, solange die Gegenstelle weiterhin nur FTP anbietet und die Daten nicht über ein sichereres Protokoll migriert wurden.

Wichtig im Betrieb: Hinterlegen Sie Zugangsdaten nicht hart im Skript. Nutzen Sie Umgebungsvariablen, einen Secret-Store oder einen durch Berechtigungen abgesicherten Aufrufkontext.

Eine robustere Variante mit passivem Modus

Sobald Firewalls oder NAT-Strecken beteiligt sind, wird der passive Modus oft notwendig.

#!/bin/bash

FTP_HOST="${FTP_HOST}"
FTP_USER="${FTP_USER}"
FTP_PASS="${FTP_PASS}"
LOCAL_DIR="/srv/archive/export"

ftp -i -n "$FTP_HOST" <<EOF
user $FTP_USER $FTP_PASS
passive
binary
lcd $LOCAL_DIR
prompt
mput *.zip
bye
EOF

Hier lohnt ein kurzer Hinweis: prompt wird in vielen Tutorials genannt, ist für vollautomatische Jobs aber meist nicht nötig, wenn bereits -i gesetzt ist. Ich lasse die Zeile nur dann im Skript, wenn ich den Ablauf zwischen interaktivem Test und Batch-Betrieb bewusst angleichen will.

Was in Audits positiv auffällt

Prüfer und interne Revisoren wollen selten einen „schönen“ FTP-Job sehen. Sie wollen einen kontrollierten Job sehen. Diese Punkte helfen:

• Klare Trennung von Konfiguration und Skriptlogik
• Expliziter Transfermodus mit binary
• Sauberes Beenden der Sitzung
• Protokollierung in ein Logfile
• Keine versteckten Auto-Login-Abhängigkeiten

Gerade in ISO-27001-nahen Prozessen ist diese Form von Einfachheit ein Vorteil. Ein kurzes, lesbares Skript lässt sich leichter prüfen als ein historisch gewachsener Wrapper mit mehreren Seiteneffekten.

Sicherheit und Compliance in NIS-2 und ISO 27001 Umgebungen

ftp -i -n kann einen instabilen Dateitransfer stabilisieren. Es macht den Transfer aber nicht automatisch sicher. Das ist die zentrale Grenze, die in vielen technischen Anleitungen fehlt.

Für Unternehmen mit NIS-2-Pflichten oder einem Informationssicherheits-Management nach ISO 27001 reicht betriebliche Bequemlichkeit nicht aus. Prozesse müssen nicht nur funktionieren, sondern auch das Risiko angemessen senken. Laut BSI-Lagebericht 2025 gab es in Deutschland über 12.000 Cyberangriffe auf FTP-Server in KMU, wobei 68 % ungesicherte Legacy-Protokolle betrafen. Gleichzeitig zeigt eine Umfrage des ITQ-Instituts aus 2025, dass 74 % der IT-Leiter im Oldenburger Münsterland keine FTP-Sicherheitsaudits durchführen (BSI-Lageberichte).

Was ftp -i -n für die Sicherheit leistet und was nicht

-n ist sinnvoll, weil es einen automatischen Login unterbindet. Das reduziert Risiken, die aus unkontrollierten Anmeldeabläufen entstehen. -i hilft, Fehlbedienungen und hängende Jobs zu vermeiden.

Beide Optionen verschlüsseln aber nichts. Benutzername, Passwort und Daten bleiben bei klassischem FTP ein Thema, das aus Compliance-Sicht kritisch ist.

Warum NIS-2 und ISO 27001 genauer hinschauen

In NIS-2- und ISO-27001-Umgebungen zählen mehrere Fragen:

• Ist die Authentifizierung kontrolliert?
• Sind Übertragungswege angemessen geschützt?
• Lässt sich der Prozess auditieren und dokumentieren?
• Sind Altverfahren als Risiko bekannt und kompensiert?

Wenn ein Unternehmen personenbezogene, finanzielle oder betriebsrelevante Daten über unverschlüsseltes FTP verschiebt, entsteht sofort Klärungsbedarf. Das gilt besonders bei Cloud-Migrationen, DATEV-Daten, Backup-Dateien oder Archivexporten.

Ein funktionierender FTP-Job kann aus Betriebssicht gut sein und aus Compliance-Sicht trotzdem unzureichend.

Vergleich der Dateiübertragungsprotokolle

Merkmal	FTP (File Transfer Protocol)	FTPS (FTP over SSL/TLS)	SFTP (SSH File Transfer Protocol)
Verschlüsselung	Standardmässig unverschlüsselt	Verschlüsselt über SSL/TLS	Verschlüsselt über SSH
Port-Nutzung	Klassisch Steuer- und Datenkanal	Weiterhin FTP-typische Logik mit zusätzlicher Absicherung	Ein einzelner verschlüsselter Kanal
Authentifizierung	Benutzername und Passwort, klassisch FTP-basiert	Benutzername und Passwort mit TLS-Absicherung	SSH-basiert, oft einfacher sauber abzusichern
Firewall-Handhabung	Häufig fehleranfällig	Komplexer als SFTP	Meist einfacher zu betreiben
Eignung für Legacy-Integration	Hoch	Hoch bis mittel	Mittel, abhängig von Altanwendungen
Eignung für NIS-2 und ISO 27001	Nur mit klaren Ausnahmen und Kompensationsmassnahmen	Oft sinnvoller Übergang	In vielen Fällen die bessere Zielarchitektur

Wann FTP noch vertretbar ist

FTP ist heute nur noch in eng begrenzten Szenarien vertretbar. Etwa dann, wenn eine Altanwendung keine Alternative unterstützt, die Gegenstelle fest vorgegeben ist und zusätzliche Schutzmassnahmen das Risiko begrenzen.

Dann gehören mindestens diese Punkte dazu:

• Netzsegmentierung für die betroffene Strecke
• Strenge Firewall-Regeln
• Dokumentierte Ausnahmegenehmigung
• Protokollierung und regelmässige Überprüfung
• Migrationspfad zu FTPS oder SFTP

Wer sich tiefer mit dem Aufbau einer effektiven Sicherheitsarchitektur beschäftigt, erkennt schnell: Nicht das einzelne Werkzeug entscheidet, sondern das Zusammenspiel aus Segmentierung, Zugriffskontrolle, Monitoring und sauberer Risikoentscheidung.

Die sinnvolle Richtung für die Praxis

Für die meisten Unternehmen ist SFTP die bessere Zielarchitektur. FTPS bleibt sinnvoll, wenn vorhandene FTP-Prozesse weiter genutzt, aber in Richtung Verschlüsselung modernisiert werden sollen. Gerade in IONOS-nahen Betriebsmodellen ist dieser Zwischenschritt oft realistischer als ein harter Komplettumbau.

Wer bestehende Prozesse modernisieren will, sollte sich den technischen Unterbau für einen Ubuntu-FTPS-Server anschauen. Das ist in vielen Umgebungen der pragmatische Weg zwischen sofortiger Risikoreduktion und längerfristiger Protokollmigration.

Typische Fehlerquellen und bewährte Praxistipps

Der Befehl ist klein. Die Fehlerbilder sind es nicht. In der Praxis scheitert ftp -i -n selten an der Syntax, sondern fast immer an Umgebung, Modus oder Annahmen im Skript.

Laut einer DATEV-DE-Audit aus 2025 bei 1.500 KMU lag die Erfolgsrate von Skripten mit -i -n bei 94,2 %. Gleichzeitig gehen 31 % der Fehlschläge in anderen Szenarien auf unerkannte Verschlüsselung oder Port-21-Blockaden zurück. Als Praxistipp für NIS-2-Umgebungen werden passive zur Umgehung von Firewall-Problemen und hash zur Validierung der Übertragung genannt (Xceed zur FTP-Protokolleinführung).

Warum verbindet sich das Skript, überträgt aber keine Datei

Meist liegt das an der Trennung zwischen Steuer- und Datenkanal. Die Anmeldung klappt, der eigentliche Dateitransfer scheitert an der Firewall.

Lösung

ftp -i -n server.example <<EOF
user $FTP_USER $FTP_PASS
passive
binary
mget *.zip
bye
EOF

passive ist oft der schnellste Weg, wenn zwischen Client und Server Firewalls oder NAT beteiligt sind.

Warum sind ZIP- oder Backup-Dateien beschädigt

Das ist der Klassiker. Der Transfer lief formal durch, die Datei ist aber unbrauchbar. Ursache ist fast immer der falsche Modus.

Lösung

binary

Setzen Sie binary in jedem Skript bewusst früh. Bei Acronis-Archiven, Exportpaketen, PDFs oder komprimierten DATEV-Dateien ist das nicht optional.

Merksatz aus dem Betrieb: Wenn eine Datei mehr ist als schlichter Text, gehört binary an den Anfang der Sitzung.

Warum hängt das Skript trotz -i immer noch

Dann liegt das Problem häufig nicht an Prompts, sondern an einem anderen interaktiven Verhalten. Zum Beispiel an fehlerhaften Zugangsdaten, nicht existierenden Verzeichnissen oder einer Gegenstelle, die anders antwortet als erwartet.

Checkliste

• Benutzername prüfen und Testanmeldung manuell durchführen
• Remote-Verzeichnis verifizieren, bevor mput oder mget läuft
• Dateimuster prüfen, damit Wildcards wirklich Treffer liefern
• Fehlerausgabe loggen, statt sie zu verwerfen

Ein minimales Logging hilft sofort weiter:

ftp -i -n "$FTP_HOST" >> /var/log/ftp-job.log 2>&1 <<EOF
user $FTP_USER $FTP_PASS
binary
bye
EOF

Warum klappt es manuell, aber nicht im Scheduler

Dann fehlt oft der Kontext des Benutzerkontos. Umgebungsvariablen, Rechte auf lokale Verzeichnisse oder der Pfad zur Laufzeit unterscheiden sich zwischen Shell und Scheduler.

Lösung im Betrieb

• Absolute Pfade verwenden
• Benötigte Variablen explizit setzen
• Schreibrechte auf Log- und Zielverzeichnisse prüfen
• Skripte unter dem echten Dienstkonto testen

Wofür ist hash nützlich

hash zeigt den Fortschritt während des Transfers an. In stark reduzierten Skripten ist das nicht zwingend nötig. Für Diagnose und Nachvollziehbarkeit kann es aber hilfreich sein.

hash

Gerade bei grösseren Dateiübertragungen sehen Sie damit schneller, ob der Transfer tatsächlich läuft oder schon vorher ins Leere gefallen ist.

Fazit Gezielte automatisieren und die Weichen für die Zukunft stellen

ftp -i -n ist kein modernes Sicherheitskonzept. Es ist ein präzises Werkzeug für ein sehr konkretes Problem. Es verhindert hängende Batch-Jobs, macht Anmeldungen bewusster steuerbar und bringt Ordnung in Legacy-Abläufe, die in vielen Unternehmen noch lange nicht verschwunden sind.

Das erklärt auch, warum der Befehl weiter relevant bleibt. Laut den bereitgestellten Angaben ist ftp -i -n historisch im RFC 959 von 1985 standardisiert und wird heute noch auf etwa 2,1 Millionen Unternehmensservern in Deutschland eingesetzt. In der Praxis steigert der Einsatz die Effizienz bei Batch-Uploads für DATEV-Integrationen um 40 % und reduziert bei der Automatisierung von Acronis-Backups und 3CX-Aufgaben Ausfallzeiten um 25 % (OSTC FTP HOWTO).

Die eigentliche Fachentscheidung lautet deshalb nicht „FTP ja oder nein“. Die bessere Frage ist: Wo stabilisieren wir einen bestehenden Legacy-Prozess, und wo ist der Zeitpunkt für die Migration auf FTPS, SFTP oder einen cloud-nativen Transferdienst gekommen?

Für Altanwendungen kann ftp -i -n weiterhin sinnvoll sein, wenn der Einsatz eng begrenzt, technisch kontrolliert und sauber dokumentiert ist. Für neue Prozesse oder sensible Daten sollte die Richtung klar sein. Verschlüsselte Protokolle, besser auditierbare Zugriffe und weniger operative Sonderfälle.

Wer seine File-Transfer-Prozesse heute prüft, findet fast immer beides: kurzfristige Quick Wins in bestehenden Skripten und mittelfristigen Handlungsbedarf in der Sicherheitsarchitektur. Genau diese Kombination entscheidet darüber, ob ein Prozess nur läuft oder auch revisionssicher und zukunftsfähig betrieben werden kann.

---

Wenn Sie prüfen möchten, ob Ihre bestehenden FTP-, FTPS- oder SFTP-Prozesse technisch sauber, auditierbar und mit NIS-2 sowie ISO 27001 vereinbar sind, unterstützt Sie die Deeken.Technology GmbH bei Analyse, Härtung und Migration. Besonders in gewachsenen Infrastrukturen mit DATEV, IONOS, 3CX, DOCBOX oder Acronis lohnt sich ein strukturierter Blick auf Automatisierung, Sicherheitsniveau und Ablösung von Legacy-Protokollen.