Vor zwei Jahren wollte ich mehrere 100 MB an Fotos mit ein paar Freunden teilen, die sich nach einem gemeinsamen Urlaub angesammelt hatten. Damals waren Dropbox und \u00e4hnliche Dienste noch nicht ganz so pr\u00e4sent wie heute. Au\u00dferdem war es eine gute Gelegenheit mehr \u00fcber FTP- und SSH-Server zu lernen und manch bekennenden Windowsnutzer ordentlich zu verwirren: \"Ja, du musst ssh benutzen. Es gibt keine andere M\u00f6glichkeit um an die Fotos zu gelangen.\" haha \ud83d\ude08
\nZu dieser Zeit sollte es unbedingt ein sftp-Server sein, da ich f\u00fcr viele andere Aufgaben sowieso schon ssh einsetzte. Damit spart man sich das Einrichten eines zus\u00e4tzlichen ftp-Servers und erh\u00e4lt gleichzeitig noch eine sichere Methode zum Datenaustausch dazu.
\nDie folgende Anleitung beschreibt die Einrichtung eines ssh-Servers, der f\u00fcr eine Gruppe von Benutzern nur als sftp-Server zug\u00e4nglich sein soll. Alle User werden dabei in einer chroot-Umgebung eingesperrt und Shell-Zugriff verwehrt um die Sicherheit auf dem Server zu erh\u00f6hen. Als Beispiel dient mir der Benutzer mika und die Gruppe freunde. Das HowTo sollte mit jeder auf Debian basierenden Distribution funktionieren und sich mit jeder anderen nachvollziehen lassen.<\/p>\n
aptitude install ssh<\/p><\/blockquote>\n
Anlegen der f\u00fcr sftp berechtigten Nutzer und der Gruppe freunde<\/h3>\n
adduser mika
\naddgroup freunde
\nadduser mika freunde<\/p><\/blockquote>\nAbsichern des Chroot Verzeichnisses<\/h3>\n
chown root.root \/home\/mika<\/p><\/blockquote>\n
Mikas Heimverzeichnis sollte im Besitz von root sein, damit er effektiv darin eingesperrt ist und er standardm\u00e4\u00dfig keine Dateien auf dem Server hochladen kann. Da aber ein Datenaustausch auch manchmal in umgekehrter Richtung sinnvoll sein kann, gen\u00fcgt es, einen Ordner wie upload in diesem Verzeichnis zu erstellen und ihn Mika mit<\/p>\n
chown mika.mika \/home\/mika\/upload<\/p><\/blockquote>\n
zu \u00fcberantworten.<\/p>\n
Konfiguration von \/etc\/ssh\/sshd_config<\/h3>\n
Notwendige Sicherheitsvorkehrungen<\/h4>\n
\n
\n
- Port 42123<\/strong><\/li>\n<\/ul>\n<\/ul>\n
Der Standardport f\u00fcr SSH ist 22. Mit dieser Variablen l\u00e4sst sich der Listen Port z.B. auf 42123 f\u00fcr den Server \u00e4ndern. Das macht den Server zwar kein bisschen sicherer (security through obscurity), hilft aber unter Umst\u00e4nden die Existenz des ssh-Servers zu verschleiern.<\/p>\n
\n
\n
- PermitRootLogin no<\/strong><\/li>\n<\/ul>\n<\/ul>\n
Wenn ein Angreifer root werden m\u00f6chte, muss er mit dieser Einstellung mindestens noch das Passwort eines weiteren Users auf dem Server kennen.<\/p>\n
\n
\n
- PermitEmptyPasswords no<\/strong><\/li>\n<\/ul>\n<\/ul>\n
SSH-Nutzer ohne Passwort sind nat\u00fcrlich ein Unding. Obwohl ich mir gut vorstellen kann, dass man das als eine weitere M\u00f6glichkeit zu \"Was man mit alten Computern machen kann<\/a>\" hinzuf\u00fcgen k\u00f6nnte. Anstatt selbst zu lernen wie man in den eigenen alten Rechner einbricht, k\u00f6nnte man das doch auch andere tun lassen... \ud83d\ude09<\/p>\n
\n
\n
- Subsystem sftp internal-sftp<\/strong><\/li>\n<\/ul>\n<\/ul>\n
Das aktiviert sshds internen sftp-Service. Normalerweise verweist Subsystem sftp auf eine ausf\u00fchrbare Bin\u00e4rdatei wie z.B. \/usr\/lib\/openssh\/sftp-server<\/em>. Diese muss durch den internen Dienst ersetzt werden.
\nAm Ende der \/etc\/ssh\/sshd_config sollte dann folgender Match-Eintrag hinzugef\u00fcgt werden.<\/p>\nMatch group freunde\n ChrootDirectory \/home\/%u\n X11Forwarding no\n AllowTcpForwarding no\n ForceCommand internal-sftp\n<\/pre>\nDer Match-Block gilt nur f\u00fcr die Gruppe freunde und jeden Nutzer, der sich darin befindet. Mika kann sich deswegen nur per sftp mit dem Server verbinden und landet danach im festgelegten Chroot-Verzeichnis. Der Shell Zugriff mit ssh wird effektiv unterbunden. Das Chroot muss nicht zwangsl\u00e4ufig mit Mikas Homeverzeichnis \u00fcbereinstimmen und kann beliebig gew\u00e4hlt werden. Der Parameter %u<\/strong> wird durch den eingeloggten Nutzer ersetzt.<\/p>\n
Der erste Test<\/h3>\n
Jetzt ist es an der Zeit den OpenSSH-Server neuzustarten. Als SFTP-Klienten eignen sich sp\u00e4ter z.B. das Firefox Addon Fireftp, Filezilla, WinSCP f\u00fcr Windows oder ganz einfach das Kommandozeilenprogramm sftp.<\/p>\n
\/etc\/init.d\/ssh restart<\/p><\/blockquote>\n
Danach sollte der sftp-Zugriff f\u00fcr Mika am Beispielrechner 192.168.0.200 funktionieren.<\/p>\n
sftp -P 42123 mika@192.168.0.200<\/p><\/blockquote>\n
und der ssh-Zugriff verwehrt werden<\/p>\n
ssh -p 42123 mika@192.168.0.200<\/p><\/blockquote>\n
DynDNS.org<\/h3>\n
Es ist zwar sch\u00f6n, dass der Server nun in unserem internen Netzwerk funktioniert, aber irgendwie m\u00fcssen die Freunde von au\u00dferhalb darauf zugreifen k\u00f6nnen. Die meisten werden sicherlich eine dynamische IP vom Provider zugewiesen bekommen, weshalb es Sinn macht einen kostenlosen DNS-Dienst wie z.B. dyndns.org<\/a> zu benutzen, um eine leicht zu merkende URL wie z.B. 4freunde.dyndns.org<\/strong> zu erhalten.
\nNachdem man sich bei dyndns.org angemeldet hat, muss man dem Dienst auf irgendeine Art noch mitteilen wie die aktuelle IP-Adresse des Heimservers lautet. Dazu bietet sich z.B. ddclient<\/a> an. Bei der Installation wird man nach Login und Passwort bei dyndns.org gefragt und kann ansonsten die Standardeinstellungen verwenden.
\nSollte man eine Firewall einsetzen oder wie ich einen Router mit eingebauter Firewall haben, dann muss nur noch der SSH-Dienst mit Hilfe von PortForwarding an den Zielserver und Port 42123 weitergeleitet werden. Danach kann sich dann Mika von \u00fcberall auf der Welt mit<\/p>\nsftp -P 42123 mika@4freunde.dyndns.org<\/p><\/blockquote>\n
auf dem Heimserver einloggen.<\/p>\n
Last but not least - Denyhosts<\/h3>\n
Wenn man seinen Server eine Weile laufen l\u00e4sst und spa\u00dfeshalber mal die Datei \/var\/log\/auth.log<\/strong> \u00f6ffnet, fallen einem die regen Zugriffsversuche auf...die allesamt nicht von den Freunden stammen. Willkommen im Internet! John Doh und Nihao versuchen mit Brute-Force-Attacken in den ssh-Server einzubrechen. Eine wirksame Methode das zu unterbinden ist z.B. denyhosts<\/a> oder noch besser gleich den SSH-Port \u00e4ndern und auf SSH-Schl\u00fcssel<\/a> umstellen.
\nBei Debian konnte ich nach der Installation mit den Voreinstellungen sehr gut leben. Die Datei \/etc\/denyhosts.conf<\/strong> ist aber hervorragend kommentiert und l\u00e4sst sich leicht an die eigenen W\u00fcnsche anpassen. Das Programm registriert fehlgeschlagene Logins und setzt die IP Adresse des Angreifers nach einer festgelegten Anzahl von Versuchen in die Datei \/etc\/hosts.deny<\/strong>, womit jeder weitere Loginversuch verwehrt wird. Es gibt noch viele weitere M\u00f6glichkeiten einen Mi\u00dfbrauch zu verhindern. Ich fand damals diesen Heise-Artikel<\/a> zum Thema sehr lesenswert. Wenn man sehr restriktiv ist und vielleicht sogar die IP-Adresse der Freunde kennt, kann man auch alle Zugriffe mit Hilfe von \/etc\/hosts.allow<\/em> und \/etc\/hosts.deny<\/em> verbieten und nur ausgew\u00e4hlte IPs erlauben.
\nSSH ist ein ausgesprochen vielseitiges und n\u00fctzliches Werkzeug. Als Beweis, dass ich nicht der Einzige bin, der positive Erfahrungen mit ssh gemacht hat, hier mal ein Link zu keros Artikel \"sperr mich ein baby<\/a>\".<\/p>\nMeine Quellen<\/h3>\n