SFTP Zugang über OpenSSH einrichten mit Qnap-NAS: Unterschied zwischen den Versionen

Aktuelle Version vom 6. November 2013, 21:17 Uhr

SFTP Zugang über OpenSSH einrichten mit Qnap-NAS

Dieser Artikel wurde getestet unter: Qnap TS-119

Dies ist nichts für Anfänger, es werden keinerlei Haftung für Datenverluste usw. übernommen!

Das ist schon ein größerer Eingriff und erfordert eine Menge Arbeit an Konfigurationen.
Der sich aber meiner Meinung nach Lohnt...

Inhaltsverzeichnis

1 SFTP Zugang über OpenSSH einrichten mit Qnap-NAS

Einleitung

In diesem Beispiel wird von einem Qnap ausgegangen die mit der neuen Firmware 3.x ausgestattet sind. Hier geht es darum ein SFTP Zugang über OpenSSH einzurichten.

Die Vorteile sind: chroot-jail (bestimmte Benutzer werden in einem Verzeichnis gefangen), die Tatsache, dass die Admin-Anmeldung unterbunden werden kann sowie die Authentifizierung der Benutzeranmeldung über Public-Private-Keys (Brute-Force-Angriffe sind damit ausgeschlossen).

Nehmt euch die Zeit und geht das ganze Langsam und mit dem Kopf durch,
ein kleiner Tippfehler irgendwo und das große Suchen geht los warum das nicht funktioniert.

Zurück zum Inhaltsverzeichnis:

Voraussetzung

Installation neuer Firmware sollte bekannt sein
Backup des Qnap sollte bestehen
Telnet bzw. SSH Zugang sollten bekannt und aktiviert sein
Editieren von Linux Konfigurations-dateien
Spass, Lust und eine Menge Zeit!
Umgang mittels Terminal (Linux) oder PuTTY (Windows) sollte bekannt sein
Umgang mit dem Editor vi
Umgang mit dem Midnight Commander mc
ein wenig sollte die Datenstruktur bekannt sein (z.B. wo die HDD eingebunden ist)

Zurück zum Inhaltsverzeichnis:

1. die benötigten IPKG Pakete installieren

Man meldet sich mittels Terminal (Linux) oder Putty (Windows) als admin bei der Qnap an
aktualisiert den IPKG-Repository und installiert sich folgende 2 Pakete:

ipkg update && ipkg install openssh coreutils

Den aktuelleren OpenSSH verwenden wir Später zur Verschlüsselung,
die coreutils beinhalten einige zusätzlich Befehle die nicht in der BusyBox enthalten sind.

Das ganze sollte in etwa so aussehen:

Zugriff und installation mit über SSH

Wenn man nur testen will, ob ein Paket vorhanden/installierbar ist,

dann ergänzt den install-Befehl um die option -test am Ende des gesamten Befehls:
Bsp: ipkg install openssh -test

Zurück zum Inhaltsverzeichnis:

2. Erstelle der neuen Benutzer

Chroot-Zugriff (das ist der Gefängnis-Benutzer, welcher in seinem Home-Verzeichnis gefangen werden soll).
Dies macht man am besten über die Web-Oberfläche siehe Benutzer erstellen.
Sind schon die Benutzer alle vorhanden die später Zugriff über SFTP erhalten sollen kann man mit dem nächsten Punkt fortfahren.

Dies benutze ich nicht, kann also kein Screenshot machen und nichts dazu erklären.
Vielleicht kann ja da ein anderer User aushelfen???

Zurück zum Inhaltsverzeichnis:

3. Erstellen der Home-Verzeichnisse

Jeder Benutzer (außer den eigenen) der später einen SFTP-Zugang erhalten soll benötigt
ein eigenen Home-Verzeichnis in welches er dann mittels Chroot gefangen wird und nur das
zu sehen bekommt was wir ihm im Home-Verzeichnis sehen lassen wollen.

Da die Interne Festplatte (zumindest bei mir) auf /share/HDA_DATA gemountet bzw. eingebunden ist
wollen wir hier unser Reales Homeverzeichnis anlegen.

wir gehen per Terminal auf die Box und wechseln auf die Festplatte:

cd /share/HDA_DATA
mkdir home
cd home

Hier erstellen für jeden User ein eigenes Homeverzeichnis und vergeben entsprechend die Rechte

mkdir monika
chmod 755 monika
chown admin monika
chgrp administrators monika

Diese Rechte benötigen wir damit später auch die Chroot-Jail funktionieren kann.
Dies wiederholen wir mit jedem User der später einen SFTP-Zugang erhalten und Gefangen werden soll.

Als nächstes editieren wir auf der Qnap die /etc/passwd am besten mit vi

vi /etc/passwd

Original /etc/passwd

admin:x:0:0:administrators:/root:/bin/sh
guest:x:65534:65534:guest:/tmp:/bin/sh
egle:x:500:100:Linux User,,,:/:/bin/sh
monika:x:501:100:Linux User,,,:/:/bin/sh
rainer:x:502:100:Linux User,,,:/:/bin/sh

neue geänderte /etc/passwd

admin:x:0:0:administrators:/root:/bin/sh
guest:x:65534:65534:guest:/tmp:/bin/sh
egle:x:500:100:Linux User,,,:/home/egle:/bin/sh
monika:x:501:100:Linux User,,,:/home/monika:/bin/sh
rainer:x:502:100:Linux User,,,:/home/rainer:/bin/sh

diese ändern wir und Kontrollieren in Ruhe nochmals alles und speichern diese dann auch.

nun wechslen wir ins Home der root:

cd /home

und legen uns hier Symlinks an zu allen realen Home-Verzeichnisse der entsprechenden Benutzer an

ln -s /share/HDA_DATA/home/monika monika
ln -s /share/HDA_DATA/home/rainer rainer
ln -s /share/HDA_DATA/home/werner werner
ln -s /share/HDA_DATA/home/michael michael.....

Zurück zum Inhaltsverzeichnis:

4. sshd_config vorbereiten

Erstelle zuerst unter auf eurer Festplatte /share/HDA_DATA/ das Verzeichnis custom
und kopiert anschließend die sshd_config-Datei dahin!

mkdir /share/HDA_DATA/custom
cp /etc/ssh/sshd_config /share/HDA_DATA/custom/sshd_config

Nun wollen wir die neue sshd_config auf der HDD im custom Verzeichnis editieren

vi /share/HDA_DATA/custom/sshd_config

Nun sucht die folgende Stelle AllowUsers.
Anschließend ergänzt/ändert den darin enthaltenen Wert um admin und den Benutzernamen (z.B.).

AllowUsers admin egle monika rainer

Jetzt dürfen sich die hier eingetragenen Benutzer admin, egle, monika, rainer über SSH z.B. putty (für Windows) an der Qnap anmelden.

Zurück zum Inhaltsverzeichnis:

5. Ersetzen des ssh-daemons auf openssh-daemon

Jetzt mounten wir uns den /dev/mtdblock5 damit wir dort ein autorun.sh-Skrip erstellen können.

mount -t ext2 /dev/mtdblock5 /tmp/config
cd /tmp/config/
vi autorun.sh

In dieser autorun.sh fügen wir folgendes ein:

#!/bin/sh
# --------------------------
# SSH restarten
# --------------------------
#Replace QNAP's bogus SSHD daemon that won't allow users to login
#This is a three step process
#
#Step 1. Stop current daemon
#Step 2. Replace with ours
#step 3. Restart our daemon
SSH=/usr/sbin/sshd
/sbin/daemon_mgr sshd stop $SSH
/usr/bin/killall sshd
rm -f /var/lock/subsys/sshd
cp /share/HDA_DATA/custom/sshd_config /etc/ssh/sshd_config
SSH_PORT=`/sbin/getcfg LOGIN "SSH Port" -d 22`
/sbin/daemon_mgr sshd start "$SSH -f /etc/ssh/sshd_config -p $SSH_PORT"

jetzt speichern wir die autorun.sh ab und dann wollen wir das Skript noch ausführbar machen und alles Demontieren.

chmod +x autorun.sh
cd /
umount /dev/mtdblock5

Zurück zum Inhaltsverzeichnis:

6. alten SSHD auf den neuen ändern

cp /mnt/ext/usr/sbin/sshd /mnt/ext/usr/sbin/org.sshd
rm /mnt/ext/usr/sbin/sshd
cp /opt/sbin/sshd /mnt/ext/usr/sbin/sshd

Nun starten wir die Box neu mit dem Reboot Befehl

reboot

Nach dem Neustart verwendet man SSH oder füer Windows-User am besten Putty für die Test,
ob man sich nun mit dem Usernamen und Passwort der User auch per SSH einloggen kann.

Wenn alles richtig funktioniert - können wir weiter machen.
Ansonsten fängt hier schon mal die erste Fehlersuche an!

Tipp: wenn man beim ssh aufruf ein -v hinten dranhängt bekommt man auch klare Ausgaben:

egle@AMD64-X2-6000:~$ ssh monika@192.168.0.5 -v
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.0.5 [192.168.0.5] port 22.
debug1: Connection established.
debug1: identity file /home/egle/.ssh/identity type 1
<snip>
debug1: Next authentication method: password
monika@192.168.0.5's password:

Zurück zum Inhaltsverzeichnis:

7. Die Chroot-Umgebung einrichten

So wenn man nun soweit ist das man mit seinen erstellten Benutzer sich
per SSH und SFTP an der Qnap anmelden kann.
Habt Ihr evtl. bemerkt das die Benutzer alle auf dem kompletten System zugriff haben, das wollen wir nun ändern.

Die Chroot-Umgebung wird innerhalb der sshd_config festgelegt (in einer sog. Direktive).
Hinzu kommt die Notwendigkeit, den internen sftp von openSSH zu benutzen.
Andernfalls müssten wir sehr viele Dateien für die Erstellung der Umgebung in das User-Home kopieren.
Und das wollen wir nicht!.

nun öffnet man die sshd_config am besten wieder mit Vi aus der Konsole heraus.

vi /share/HDA_DATA/custom/sshd_config

suchen dort am Ende diesen Eintrag:

Subsystem       sftp    /usr/libexec/sftp-server

und ändern diesen so das wir dies dann haben:

#Subsystem       sftp    /usr/libexec/sftp-server
Subsystem    sftp    internal-sftp

mit dem Routezeichen deaktivieren wir die Zeile und schreiben unseren Eintrag einfach drunter. Danach gehen wir ans Ende wo wir dies finden:

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server

Hier fügen wir nun ans Ende für jeden User "neu" folgendes an:

Match User monika
      ForceCommand internal-sftp
      ChrootDirectory /home/monika
      AllowTcpForwarding no
      X11Forwarding no

Match User rainer
      ForceCommand internal-sftp
      ChrootDirectory /home/rainer
      AllowTcpForwarding no
      X11Forwarding no

Wenn alle Benutzer mit Ihrem eigenen Home-Verzeichnis eingetragen sind
speichert die sshd_config ab mittels:

Esc-Taste druecken
:wq! druecken

Und starten die Box neu mittels:

reboot

Nach dem Starten probieren wir aus ob man mit den verschiedenen Benutzer
sich per SFTP aauf die Qnap anmelden kann.

Die anmeldung sollte funktionieren und die Benutzer in Ihrem Homeverzeichnis gefangen sein, also nichts tun können. Wenn das so ist ist alles In Ordnung und wir können mit den nächsten Schritt weitermachen.

sollte die Anmeldung fehlschlagen, und im Webif bei den Systemmeldungen ein Re-Launch ssh erscheinen wird vermutlich in der sshd_config ein Schreibfehler vorhanden sein, oder einige Buchstaben bzw. Zeichen fehlen.

Zurück zum Inhaltsverzeichnis:

8. Home Inhalte zuweisen und montieren

Da unser Benutzer nun in Ihrem "leeren" Homeverzeichnis gefangen sind,
können wir diesen Bestimmte Bereiche zuweisen in denen diese Zugriff haben.

Durch die Chroot-Jail sind diese ja gefangen und sollen ja nicht sonst wo im System herum stöbern können.

Nur wenn wir ihnen nun ein weiteres Verzeichnis in Ihrem Homeverzeichnis anlegen und dieses mit den entsprechenden Rechten ausstatten geben wir den Benutzern einen "gewissen Freiraum".

Verzeichnisse erstellen und rechte einrichten:
ggf. mittels mount --bind bereits erstellte Verzeichnisse außerhalb der Jail einbinden (montieren)

cd /home/monika
mkdir Audio
mkdir Movie
mkdir Public
chown -R monika:freunde Audio
chown -R monika:freunde Movie
chown -R monika:freunde Public
chmod 755 Audio
chmod 755 Movie
chmod 755 Public

Danach können die entsprechende User mittels SFTP auf deren Verzeichnisse zugreifen und haben aber nur die Möglichkeit innerhalb von Audio, Media und Public sich zu bewegen und auch nur dort können Sie zugreifen.

Diese Verzeichnisse in meinem Beispiel beziehen sich auf Freigabeverzeichnisse im Webif unter der Zugriffskontrolle.

Nun müssen wir die entsprechenden Freigabenverzeichnisse aus dem Webif noch in die Homeverzeichnisse "montieren". Hierzu müssen wir wieder unsere "autorun.sh" aufrufen und wie folgt die entsprechenden Verzeichnisse "einbinden".

Um den mount --bind zu benutzen muss erst die autorun.sh gemountet werden:

mount -t ext2 /dev/mtdblock5 /tmp/config

Nun kann in /tmp/config die autorun.sh editiert werden. Dies schreiben wir dann einfach ans Ende der autorun.sh:

# Für monika
mount --bind /share/HDA_DATA/Qnap/Media/Audio /home/monika/Audio
mount --bind /share/HDA_DATA/Qnap/Media/Video /home/monika/Movie
mount --bind /share/HDA_DATA/Public /home/monika/Public

# Für rainer
mount --bind /share/HDA_DATA/Qnap/Media/Audio  /home/rainer/Audio
mount --bind /share/HDA_DATA/Qnap/Media/Video /home/rainer/Movie
mount --bind /share/HDA_DATA/Public /home/rainer/Public

Danach dann das ganze wieder unmounten mittels:

cd /
umount /dev/mtdblock5

und wieder die Box neu Starten mittels "reboot".

Testet nun den Userzurgiff per SFTP.
Wenn alles richtig gemacht wurde sollte dieses nun mittels angaben des Benutzer-Passwortes voller Zufriedenheit funktionieren.

Damit wäre das Kapitel SFTP einrichten abgeschlossen und wir können uns der Thematik der Public-Private-Key Authentifizierung widmen. Damit wir dadurch auch gegen Brute-Force-Angriffe geschützt sind!

Zurück zum Inhaltsverzeichnis:

9. Public-Private-Key Authentifizierung

Bei dieser Art der Authentifizierung wird der Benutzer mit einem privaten Schluessel, den er immer verwenden muss, authentifiziert.

D.h., der Benutzer ist im Besitz seines private key, welcher als einziger schuetzenswert ist. Verliert er ihn, so muss ein neuer Schluessel erstellt werden. Der Schluessel sollte nie per Email versandt werden!

Wie man normalerweise solch einen Public-Private-Key erstellt,
ist eigentlich ein eigenes Thema (gerade für Windows-Anwender) und sollte separat gelesen werden.

http://www.howtoforge.de/howto/key-basierte-ssh-logins-mit-putty/

Da wir hier aber auf unserem Qnap den OpenSSH installiert haben,
können wir dies natürlich auch direkt auf der Box machen. aber immer schön der Reihe nach.

Auf dem Server liegen im Verzeichnis .ssh (oder ~.ssh) in der Datei authorized_keys die öffentlichen (public) Schlüssel, welche eine Art Pendant für den private key des jeweiligen Benutzers darstellen. Ein public key pro Zeile - Zeilenumbrüche innerhalb des Schlüssels sind nicht erlaubt.

Diese Art der Authentifizierung ist die sicherste, weil Brute Force Angriffe ausgeschlossen sind. Besitzt also der Angreifer nicht den richtigen privaten Schluessel, so wird er sofort abgewiesen.

Das bedeutet wir müssen erstmal in jedem Benutzer-Homeverzeichnis ein Verzeichnis .ssh und darin die Datei authorized_keys mit den entsprechenden Rechten erstellen.

Die Berechtigungen sollten so aussehen:
owner ist admin
group ist administrators
chmod 755

Auf jeden Fall benötigt der Benutzer nur Leserechte auf das Verzeichnis und die Datei.

Also lösen wir dies so:

cd /home/monika
mkdir .ssh
chown -R admin:administrators .ssh
chmod 755 .ssh

Dann erstellen wir uns die authorized_keys:

cd .ssh
touch authorized_keys

Und vergeben die richtigen Rechte

chown -R admin:administrators authorized_keys
chmod 744 authorized_keys

Nun erzeugen wir uns unsere Schlüssel:

ssh-keygen -b 2048 -t rsa -C monika-ssh-key

Bei der Abfrage wo wir den Schlüssel speichern wollen entscheiden wir
uns für das entsprechende Benutzerverzeichnis/.ssh das ganze sieht das so aus:

Enter file in which to save the key (/root/.ssh/id_rsa): /home/monika/.ssh/id_rsa

Bei der Abfrage der passphrase könntet Ihr die Private-Key-Datei noch mit einem Passwort schützen. Somit wäre sichergestellt das selbst wenn diese in fremde Finger gelangen würde derjenige damit nichts anfangen kann. Wollt Ihr kein Passwort vergeben drückt da einfach die Enter bzw- Return -Taste.

Jetzt fügen wir den erstellten Schlüssel auch in die authorized_keys mit ein.

[/home/monika/.ssh] # cat id_rsa.pub >> authorized_keys

Dies wiederholen wir mit jedem angelegten Benutzer der Zugriff mittels SFTP erhalten soll.

Der Schlüssel id_rsa also Ohne das .pub am Ende ist der Private Schlüssel, dieser muss man an seine Benutzer weitergeben damit diese sich ja auch später Anmelden können. Linuxuser können diesen Direkt verwenden, Windowsuser müssen diesen erst mit Puttygen laden und dann als Putty-Key abspeichern damit diese den eben mit "Putty-Pendant" dann benutzen können.

Das bedeutet die Linuxuser nehmen diese (am besten beide) Schlüssel und kopieren sich diese in Ihr /home/.ssh Verzeichnis rein und geben dann aber auch nochmals die Rechte an chmod 744 authorized_keys.

Tipp: die Rechte innerhalb eines Verzeichnisses kann man auflisten mittels: ls -l -a

Zurück zum Inhaltsverzeichnis:

10. ssh_config auf Public-Private-Key

Wenn die Schlüssel fertig sind, muss nur noch die sshd_config etwas abgeändert werden.
Diese sollte in /share/HDA_DATA/custom wir wir hoffentlich nun wissen zu finden sein.

Sucht nach den folgenden Einträgen und passt diese wie hier aufgelistet ab:

LoginGraceTime 2m
#Anmeldezeit, entspricht 2 min.

PermitRootLogin no
#Root kann sich jetzt nicht mehr anmelden.
#Verwende einen normalen Benutzer und führe nach der Anmledung: sudo admin

MaxAuthTries 1
#ein anderer Wert macht bei Key-Authentication keinen Sinn

PubkeyAuthentication yes
#Ab jetzt geht nur noch Key-Authentication

AuthorizedKeysFile .ssh/authorized_keys

PasswordAuthentication no
#siehe PubkeyAuthentication

RSAAuthentication no

KerberosAuthentication no

GSSAPIAuthentication no

UsePAM no

MaxStartups 2
#Max. Anzahl an nicht authentifizierten Verbindungen.
#Bei Angriffen (welche jetzt eigentlich ausgeschlossen sind) ist dieser Wert besonders wertvoll

Abschlusserklärung:

Beachtet bitte, dass nach der Umstellung und dem Restart des Systems keine Ameldung durch den Benutzer admin möglich ist.
Das bedeutet also, dass man auch noch die Schlüssel fuer einen normalen Benutzer der nicht in einer Chroot-Jail gefangen wurde, z.B. der eigene Nickname erstellen muss, denn nur ueber diesen Benutzer kann man sich ab jetzt als admin anmelden.

Also...

1. Man meldet sich z.B. als EgLe an... und wird über den private key authentifiziert
2. Jetzt tippst man auf der Shell folgendes ein

su - admin

3. Erst jetzt kannst Du Dich als admin mit dem dazugehoerigen Kennwort authentifizieren.

Sollte man sich aus welchem Grund auch immer ausgesperrt haben, kann man über Telnet auf die Maschine drauf. Man kann den Telnet über die Weboberfläche einschalten. Allerdings solltest man den Telnet-Zugang ggf. abschalten - er ist unsicher (d.h. zumindest nicht über das Internet verwenden).

Noch etwas zum Portforwarding für den Zugriff über das Internet:

Stelle für Deinen Router Portforwarding ein. D.h. Dein Router soll nicht auf Port 22 reagieren. Schalte irgend eine hohe Portnummer ein (z.B. 47610) und leite diese auf Port 22 um. Damit sind schon mal die meisten script kiddies ausgeschlossen. Du wirst sehen, dass Dein Server mit all diesen Einstellungen sehr sicher ist. (Auch wenn man ihn noch etwas sicherer machen könnte - aber dies ist dann meist mit sehr viel Paranoia verbunden.)

So und nun viel Spass mit dem neuen recht sicheren Zugriff auf den Qnap.

Zurück zum Inhaltsverzeichnis:

Zurück zur Übersicht:Hilfe zum Hersteller Qnap oder Hauptseite

SFTP Zugang über OpenSSH einrichten mit Qnap-NAS: Unterschied zwischen den Versionen

Aktuelle Version vom 6. November 2013, 21:17 Uhr