Viele Dinge kann man über das Webinterface der DS erledigen. Doch manchmal muss man mit root Rechten etwas an der Konsole fummeln und da gibt es nur zwei Möglichkeiten des Zugriffs:

• telnet (Port 23)
• ssh (Port 22)

telnet ist okay wenn man aus dem LAN auf den Server zugreifen will, denn es ist nicht verschlüsselt und damit werden Login Daten unverschlüsselt übermittelt. Für Zugriffe von außerhalb des LAN ist es jedoch aus Gründen der Sicherheit nicht zu empfehlen.

Da kommt dann ssh zum Zuge. Dieses Protokoll verlangt eine Verschlüsselung. Auf der DS wird dazu OpenSSH eingesetzt. Der entscheidende Vorteil liegt auf der Hand: Die gesamte Verbindung vom Aufbau bis zum Ende ist durchgehend verschlüsselt. Dabei bietet ssh die klassische Anmeldung mit Username und Passwort, aber auch die Methode via Username und Private Key. Der Vorteil der Private Key Methode ist es, dass es nicht mehr möglich ist mit Passwort auf die DS zuzugreifen und damit laufen alle Brute Force Attacken ins Leere.

• Zugriff auf die DS mit ssh oder telnet bereits aktiviert
• Zugriff auf die Shell mit root Rechten und Admin Passwort
• Umgang mit einem Konsoleneditor (z.B. vi oder nano)

Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.

Jeder Benutzer, der sich via Key authentifizieren darf muss bestimmte Dateien und Verzeichnisse in seinem Homeverzeichnis haben. Wie man Homeverzeichnisse erstellt steht im www beschrieben (kommt aber auch mit der nächsten Firmware von Synology) und daher gehe ich darauf nicht weiter ein. Im HOME Verzeichnis des Users muss zuerst ein verstecktes Verzeichnis ssh erstellt und die Rechte sehr restriktiv gesetzt werden

$ mkdir ~/.ssh
$ chmod 0700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chown -R EUER_BENUTZER ~/.ssh
$ chmod 0600 ~/.ssh/authorized_keys

Dabei steht ~/ für das Homeverzeichnis des gerade angemeldeten Benutzers. Dann muss die PubKey Auth in ssh aktiviert werden. Dazu in /etc/ssh/sshd_config das Kommentarzeichen (#) vor den folgenden Direktive entfernen

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Zum Erstellen der Schlüssel bietet sich ein Tool wie Putty bzw Putty KeyGen an. Dazu startet ihr Putty KeyGen und klickt mit den Standarteinstellungen auf Generate

Nach dem Klick müsst ihr den Mauszeiger eine gewisse Zeit über das Feld fahren lassen, damit genügend Zufallswerte für den Schlüssel entstehen

Am Schluss gebt ihr für den Private Key ein Passwort vor und klickt auf Save private key. Oben hat Putty netterweise den Eintrag der Public Keys für das 'authorized_keys'-File bereits erstellt. Den Code kann man in die Zwischenablage kopieren und dann in der Datei des jeweiligen Users so rein-pasten. Achtet Euch darauf, dass alles auf einer Zeile (ohne Zeilenumbrüche!!!) steht

Zum Schluss muss man jetzt also diesen Public Key String in die authorized_keys Datei des jeweiligen Users bringen. Wenn ihr ihn in der Zwischenablage habt und ein Tool wie Putty benutzt, dann kann man den Inhalt der Zwischenablage mittels eines Rechtsklicks an die Position des Cursors einfügen. Öffnet also die Datei in einem Editor Eurer Wahl (bei mir fast immer nano) und fügt den Inhalt ein

$ nano -w ~/.ssh/authorized_keys
<<Rechtsklick mit der Maus>>
<<ctrl+x für exit und y zum speichern>>

Als Backup Zugang für alle SSH Experimente bietet sich telnet an. Wie man diesen Zugang aktiviert steht hier im Wiki, drum gehe ich nicht näher darauf ein. Der Backup Zugang ist wichtig, 1) weil es sein kann, dass die ssh Verbindung beim Aufrufen des ssh Startscripts abreist und der Dämon dann nicht neugestartet wird und 2) weil eine Fehlkonfig in der sshd_conf oder authorized_keys Datei den Start des SSH Dämons komplett verhindern könnte. Also ist es besser ein telnet-Hintertürchen zu haben, falls was schief geht.

Zum Testen des Ganzen müsst ihr erstmal den ssh Daemon neustarten. Dazu loggt ihr Euch am Besten via telnet als root mit Admin Passwort auf der DS ein und ruft das entsprechende Startscript des Daemons auf

$ sh /usr/syno/etc.defaults/rc.d/S95sshd.sh restart

Damit sollte der Daemon neugestartet sein und auf Anfragen warten Zum Testen der PubKey Anmeldung verwendet ihr am besten wieder Putty. Erstellt bei Putty und Hostname eine Verbindung in der Art 'user@IP_DER_DS' und BEVOR ihr auf Verbinden klickt stellt ihr noch den Schlüssel für die Verbindung in Putty unter SSH–>Auth. Dort klickt ihr auf Browse und gebt den Pfad zum Privaten Schlüssel an. Wenn das gemacht ist, klickt ihr auf Connect und die Shell sollte den Username aus dem Hostnamen übernehmen. Dann sollte eine Abfrage nach dem Passwort des Private Key kommen.
Das ist keine Abfrage der DS sondern von Putty. Das Passwort des Private Key wird natürlich nicht an die DS übermittelt sondern dient nur der lokalen Kontrolle des Schlüssels auf dem Client.
Auch der „Wert“ des privaten Schlüssels wird niemals an den Server übermittelt. Mit dem Schlüssel „verschlüsselt“ der Client eine dem Server bekannte Zeichenfolge und schickt sie an den Server. Wenn dann der Server mit dem öffentlichen Schlüssel aus authorized_keys diese Zeichenfolge wieder entschlüsseln kann dann weiss er, dass der Client den gewünschten privaten Schlüssel kennen muss.

Wenn die Key Authentifizierung geklappt hat, dann sollte man SSH noch dahingehend anpassen, dass der Daemon nur Anmeldungen via Private Key akzeptiert und die normale Anmeldung mit Username und Passwort verweigert. Erst dann sind Brute Force Attacken ausgeschlossen. Dazu müsst ihr in der 'sshd_config' eine weitere Konfig Var setzen und den SSH Daemon nochmals via telnet neustarten

PasswordAuthentication no

Obige Konfig verhindert, dass der SSH Daemon Passworte akzeptiert. Wenn ein Client versucht sich zu ssh zu verbinden ohne einen Schlüssel(also mit Passwort)/oder einen falschen Schlüssel zu haben, dann wird der ssh Daemon das mit einem REJECT beantworten und der ssh Client wird melden, dass keine unterstützten Authentifizierungsmethoden vom Daemon angeboten würden.

Wenn man zu faul ist das Passwort des Private Keys bei der Anmeldung angeben zu müssen, kann man ein Tool wie Paegant (ist beim Putty zip File dabei) benutzen. Dort lädt man den Private Key und gibt zur Authentifizierung des Passwort an. Wenn man jetzt in Putty eine Verbindung auf 'user@IP_DER_DS' öffnet landet man ohne weiteres direkt auf der Shell. Denn Putty arbeitet mit Peagant zusammen und holt sich die Schlüssel von dort. Damit wird es für Putty überflüssig nach dem PW zu fragen, hat Peagant ja bereits gemacht.

SSH und authorized_keys sind sehr mächtig. Es gibt z.B. die Möglichkeit den Aufruf eines externen Programms in authorized_keys zu machen. Diese wirddann bei jeder Anmeldung des Benutzers ausgeführt. Das kann sehr sehr hilfreich sein bei Verbindungen anderer Anwendungen, die man via ssh tunneln will. Als Beispiel nenne ich svn: Hier kann man in authorized_keys svn im Tunnel Modus aufrufen. Und so via PrivateKey Auth und ssh auf ein Subversionsystem zugreifen kann, d.h. jedemals wenn der betreffende User authentifiziert wurde wird die SSH Verbindung zum lokalen Subversion Server getunnelt. Die Eleganz dieses Verfahrens zeigt sich bei Subversion sehr deutlich: Man braucht nur einen svn Benutzer für ALLE Zugrffe. Durch den verwendeten Schlüssel wird in authorized_keys festgestellt mit welchen Parametern (v.a. der Subversion Root damit wird der User in diesem Verzeichnis eingesperrt) der svnserve gestartet werden soll. Man kann also damit für jeden Benutzer je nach verwendetem Schlüssel unterschiedliche Aktionen ausführen lassen. Zusätzlich kann man in authorized_keys die Parameter der ssh Verbindung setzen (z.B. no-pty oder no-port-forwarding) und damit die globalen Werte auch der 'sshd_config' überschreiben. So wäre es z.B. auch möglich Backup Jobs immer bei Anmeldung eines bestimmten Benutzers auszuführen

An svn lässt sich das Zusammenspiel mit ssh sehr schön zeigen, wie oben erwähnt. So könnte eine authorized_keys ausschauen, um svnserve im Tunnelmodus zu starten:

command="/opt/bin/svnserve -t -r /volume1/svn/repos/private --tunnel-user=svn",no-port-forwarding,no-agent-forwarding,no-pty  ssh-rsa PUBLIC_KEY1_VALUE COMMENT
command="/opt/bin/svnserve -t -r /volume1/svn/repos/public --tunnel-user=svn",no-port-forwarding,no-agent-forwarding,no-pty ssh-rsa PUBLIC_KEY2_VALUE COMMENT

Bei jeder Authentifizierung via ssh wird der Daemon in der dem User gehörenden Datei nach dem passenden Public Key suchen und den entsprechenden Command ausführen. Im obigen Beispiel ist der KEY1 der für private Zugriffe und KEY2 jener für öffentiche Zugriffe. Der Parameter -t ruft svnserve im Tunnelmodus auf und legt mit -r das Chroot Directory für den User fest. Zusätzlich wird über –tunnel-user der lokale Benutzer für den Zugriff auf svn definiert. Der Aufbau ist also sehr einfach:

command="COMMAND PARAMETER[,]PARAMETER[,]PARAMETER",SSH_PARAMETER,SSH_PARAMETER,SSH_PARAMETER KEY_TYPE KEY_VALUE COMMENT