Ich bin neu bei Linux.
Ich arbeite mit einem Redhat 5.5-Server und verwende ein Java-basiertes SFTP-Skript, mit dem mehrere Benutzer Textdateien auf einen Server hochladen können. Ich bin noch nicht entschieden, ob jeder Benutzer ein separates Verzeichnis haben wird oder ob ich eine Namenskonvention verwenden werde, die seine Kunden-ID enthält.
Die Dateien enthalten einige persönliche Informationen zu ihren LAN-Einstellungen, daher verwende ich lieber SFTP als FTP. Soweit ich weiß, ist SFTP verschlüsselt (außerdem habe ich eine Java-Klasse so konfiguriert, dass sie über SFTP hochlädt, daher wechsle ich lieber nicht das Protokoll, es sei denn, es gibt einen sehr guten Grund dafür).
Der Prototyp ist für ein System gedacht, das eine große Zahl von Kunden unterstützen soll, und die Vorstellung, ständig Clients über die Befehlszeile hinzuzufügen und zu entfernen, erscheint höchst unpraktisch. (Ich bin noch neu bei Linux und Redhat bzw. lerne gerade erst damit).
Was sind normale Konventionen, um mehreren Benutzern die Berechtigung zum Hochladen von Dateien per SFTP zu erteilen, wobei jeder Benutzer einen eindeutigen Benutzernamen und ein eindeutiges Kennwort hat?
Antwort1
Sie können dies tun, indem Sie Ihren externen SSHD als chrooted sftpd einrichten (verwenden Sie hierfür die Option sftpd-internal in sshd_config). Jeder Benutzer kann sein eigenes Chroot-Jail haben. In der authorized_key-Datei Ihrer Benutzer (keine Passwörter zulassen!) sollten Sie jedem öffentlichen Schlüssel die notwendigen Präfixe voranstellen, die den Shell-Zugriff verhindern. Ihr Chroot sollte außerdem nur die grundlegenden Einstellungen für den SFTP-Zugriff enthalten (keine Binärdateien, keine Bibliotheken, nur /dev/null, /dev/zero, /dev/random und /dev/urandom – soweit ich mich erinnere).
Antwort2
Was Sie beschreiben, ist möglich, aber wahrscheinlich nicht die beste Idee, insbesondere nicht, wenn Sie, wie Sie sagen, ein Linux-Neuling sind.
Wie Sie sagen, wird die Verwaltung von Dateiberechtigungen und Benutzern zu einem Albtraum, und SFTP erfordert SSH, das selbst alle möglichen Funktionen bereitstellen kann, wie etwa das Ausführen von Code auf dem Remote-Server und das Herunterladen von Dateien.
EsIstEs ist möglich, einen SFTP-Server mit einem Mindestmaß an Sicherheit zu konfigurieren, aber es gibt viele Fallstricke bei der Konfiguration. Im Internet gibt es viele irreführende Ratschläge zur Konfiguration von Nur-SFTP-Benutzern mit SSHd. Kurz gesagt, es istnichtEs reicht nicht aus, einfach ihre Login-Shell in eine ungültige Shell zu ändern, Sie müssen sich auch Gedanken darüber machen, ob sie Befehle aus der Ferne ausführen und die Shell umgehen können, und ob sie möglicherweise sensible Systemdateien außerhalb ihres Home-Verzeichnisses lesen können, sowie ob sie SSH-Tunneling verwenden können, um Firewalls zu umgehen. Sowie über alle anderen Funktionen, die mir vielleicht nicht spontan einfallen.
Und esIstEs ist möglich, die ganze Sache mit der Notwendigkeit, für jeden Kunden einen Benutzer anzulegen, zu umgehen, entweder indem man mit PAM ein bisschen Zauberei anwendet, um SSH gegenüber einer anderen Benutzerdatenbank authentifizieren zu lassen, oder indem man einfach ein einzelnes Benutzerkonto teilt (was ausreichen sollte, solange man nur BenutzerhochladenDateien).
Darüber hinaus lösen Sie auf irgendeine Weise ein grundlegendes Sicherheitsproblem, das SFTP in Ihrer Art von Anwendung mit vielen Remote-Benutzern hat, die überprüfen müssen, ob der Remote-Server derjenige ist, der er zu sein scheint. Es gibt keine Zertifizierungsstellen für SSH - die Methode, die SSH zum Schutz vor Man-in-the-Middle-Angriffen verwendet, besteht darin, einen Fingerabdruck der SSH-Serverschlüssel der Server zwischenzuspeichern, mit denen der Client eine Verbindung herstellt, und wenn der Schlüssel mit dem zuvor angezeigten Schlüssel übereinstimmt, ist alles in Ordnung. Allerdingswenn der Schlüssel nicht bekannt ist, da es sich um die erste Verbindung eines Clients handelt, muss der Benutzer bei SSH den Fingerabdruck manuell überprüfen. Es ist nicht vernünftig, von Ihren Clients zu erwarten, dass sie dies tatsächlich tun. So ziemlich jeder wird einfach auf „Ja“ klicken, weil er mit seinem Leben weitermachen möchte. Sie könnten den gültigen Host-Fingerabdruck möglicherweise mit Ihrer Anwendung verteilen, aber das scheint ein ziemlicher Albtraum zu sein.
Wenn Sie sich trotz der beschriebenen potenziellen Probleme für SFTP entscheiden, empfehle ich Ihnen, Folgendes zu untersuchen:RSSum Benutzer nur auf SFTP zu beschränken. Darüber hinaus sollten Sie alle Ihre SFTP-Benutzer in einem Chroot-Jail aufbewahren, wo sie weder in den Betrieb des Servers eingreifen noch auf Systemdateien zugreifen können. (Selbst dann könnte es einem Angreifer möglich sein, die Benutzer Ihres Systems aufzuzählen...) Außerdem müssen Sie sicherstellen, dass der SSHD so konfiguriert ist, dass SSH-Tunneling von Ihren SFTP-Benutzern verhindert wird.
...
Anstatt sich mit diesem Durcheinander herumzuschlagen, würde ich vorschlagen, ein anderes Protokoll zum Hochladen Ihrer Dateien in Betracht zu ziehen, das für Ihren Anwendungsfall viel besser geeignet scheint – warum ziehen Sie nicht in Betracht, die Dateien über HTTPS hochzuladen? Sie würden eine Art serverseitiges CGI-Skript oder ein Java-Servlet oder etwas Ähnliches benötigen, um die Dateien zu empfangen, etwas Nützliches damit zu tun und die Authentifizierung durchzuführen. Das serverseitige Skript könnte sich darum kümmern, die Dateien an einem nützlichen Ort zu speichern. Was das clientseitige Problem betrifft, ist das Hochladen einer Datei über HTTPS eine so häufige Sache, dass es mich erstaunen würde, wenn es nicht eine einsatzbereite API-Klasse gäbe, die Sie ganz einfach für diese Art des Datei-Uploads verwenden könnten.
Dies bedeutet natürlich, dass Sie zur Lösung Ihres Problems tatsächlich ein serverseitiges CGI-Skript schreiben müssten, aber ich vermute, dass Sie die eingehenden Dateien ohnehin irgendwie programmgesteuert verarbeiten wollten. Dies macht es tatsächlich einfacher, weil bei jeder neuen Datei Code für Sie aufgerufen wird.