Das Dateitransferprotokoll FTP ist nicht mehr zeitgemäss. Das liegt weniger daran, dass die RFC 959, die FTP beschreibt, aus dem Oktober 1985 datiert, sondern an einigen Designschwächen, die FTP für den Einsatz im Internet disqualifizieren.
Im Gegensatz zu vielen anderen TCP-Protokollen benötigt FTP zwei verschiedene offene Ports, um mit dem Client kommunizieren zu können. Dies sind der Command- und der Data-Port. Je nach verwendetem FTP-Modus (active oder passive) werden andere Port-Nummern verwendet, was die Konfiguration der Firewalls entweder auf Server- oder auf der Client-Seite stark erschwert. Beim Passive-Mode wird beispielsweise vom Client eine Verbindung zum Port 21 des Server geöffnet und eine FTP-Verbindung initialisiert. Das Kommando PASV veranlasst den Server dann dazu, einen beliebigen Port > 1024 auszuwählen und diesen dem Client mit dem Kommando PORT zurückzusenden. Der Client nimmt dann Verbindung zum mit PORT spezifizierten Port auf. Dies hat zur Folge, dass man bei der Firewall auf der Client-Seite eine grössere Anzahl Ports > 1024 offen halten muss, damit passives FTP funktioniert.
Während das Problem mit dem aktiven oder passiven FTP eher die Administratoren beschäftigt, dürfte der Datentransfer im Klartext vor allem den Anwendern Bauchschmerzen bereiten. Denn egal ob Daten oder Passwörter, alle Informationen rauschen bei FTP unverschlüsselt durch die Leitung und können problemlos mit Ethereal oder einem anderen Netzwerksniffer mitgelesen werden, was schlimmstenfalls unbefugten Personen Tür und Tor zum FTP-Server öffnen kann, welche dann unberechtigt Daten plazieren oder löschen können.
Um das Problem mit dem Datentransfer im Klartext zu begegnen, wurde im Oktober 1997 die RFC 2228 veröffentlicht, die FTPS (FTP Security Extensions) beschreibt. Es arbeitet genau wie FTP mit zwei TCP-Verbindungen, welche allerdings verschlüsselt sind. Doch FTPS ist nie über den Status einen Entwurfs hinausgekommen und wurde nur in sehr wenigen Servern und Clients implementiert.
Die einfachste Variante, einen verschlüsselten Dateitransfer zwischen einem Client und einem Server zu etablieren, sind die beiden mit der OpenSSH-Suite ausgelieferten Tools scp (Secure Copy) und sftp (Secure File Transfer Program). Ein SSH-Server wird mit jeder Linux- oder BSD-Distribution ausgeliefert und wird in vielen Fällen bereits zur Remote-Verwaltung der Maschinen genutzt. Selbst für Windows existieren OpenSSH-Implementierungen, die ohne eine Vollinstallation von Cygwin zurecht kommen. Die Daten werden dabei durch einen SSH-Tunnel transferiert, der mit einer starken Verschlüsselung geschützt wird (3DES oder AES). Auch ist es nicht möglich, anstatt Passwörtern verschlüsselte SSH-Keys zu benutzen, womit der Login noch sicherer wird. Auch existieren mittlerweile neben den Command-Line-Tools graphische Clients für die wichtigsten Betriebssysteme, die sich wie ihre FTP-Geschwister anwenden lassen.
Mindestens im ersten Moment darf man sich auch als Administrator freuen, denn SSH arbeitet mit nur einem einzigen Port (in der Regel 22) und stört darum auch nicht die Firewallkonfiguration. Allerdings benötigen scp und sftp einen User-Account und eine Login-Shell auf dem Zielrechner. Dies bedeutet, man kann sich auch mit einem beliebigen SSH-Client an der Maschine anmelden und beliebige Programme aufrufen sowie durchs Dateisystem surfen. Dies mag für Maschinen, auf die nur wenige Leute zugreifen, die man kennt, noch durchgehen, ist aber fürs Massenhosting untauglich.
Die einzige Lösung, um den Wirkungskreis der Benutzer einzuengen, ist das Aufsetzen einer chroot-Umgebung. Damit ein Benutzer während des Logins nicht das Etablieren des chroot-Jails abbrechen kann, muss man den SSH-Server dazu bringen, selber chroot() aufzurufen. Da OpenSSH dies aber nicht von Haus aus kann, muss man einen Patch (siehe Kasten) einspielen, der OpenSSH um diese Funktionalität erweitert. Damit koppelt man sich allerdings von den Security-Updates der jeweiligen Distribution ab, womit der Pflegeaufwand erhöht wird. Zudem ist bei eventuellen Sicherheitsproblemen von OpenSSH schnelles Handeln gefragt.
Eine Alternative, sofern man den Benutzern keinen Shellzugang einräumen will, stellt das kleine Tool scponly dar. Scponly stellt zwei verschiedene Login-Shells bereit, die den Aktionsradius der Benutzer einschränken: Die Shell scponly erlaubt nur das Ausführen der zum Betrieb von scp/sftp nötigen Kommandos. Die zweite Shell scponlyc etabliert einen chroot-Jail und begrenzt den Benutzer auf sein Home-Directory. Wieder ist es nur möglich, die zum Betrieb von scp/sftp benötigten Befehle auszuführen. Einen Remote-Login erlauben beide Shells nicht.
