Ssh mit Zertifikaten absichern

Aus Synology Wiki
Wechseln zu: Navigation, Suche

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 (wobei unter anderem Login-Daten unverschlüsselt übermittelt werden). Für Zugriffe von außerhalb des LAN ist es damit aus Sicherheitsgründen 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.

Setzt man die Private Key Methode ein, kann man OpenSSH auf der DiskStation so konfigurieren, dass es nicht mehr möglich ist mit Passwort auf die DS zuzugreifen. Damit laufen alle Brute Force Attacken ins Leere. Dieser Artikel erklärt, wie man die DiskStation und den Client konfigurieren kann, um sich (auch ausschließlich) mit einem Private Key auf der DiskStation anmelden zu können. Hier vorgestellte Clients sind einmal Windows mit Putty, und unixoide Betriebssysteme wie Mac OS X und Linux.

Vorarbeiten für SSH mit Schlüsseln

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. Sollte etwas schief gehen und telnet vorher nicht aktiviert worden sein, kann man das zwar bei neueren Versionen des DSM (> 4.0) sehr wahrscheinlich in der Weboberfläche nachholen, aber sicher ist sicher.

Voraussetzungen

  • 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)

Vorarbeiten auf der 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 (im DSM 4.1 geht das mit der offiziellen Weboberfläche) 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

Alternativ kann man auch einfach auf der DS unter dem Benutzer welcher ssh Keys verwenden will ein ssh localhost starten und die nachfolgende Frage nach dem Key mit yes beantworten, dann einfach abbrechen. Dabei wird automatisch das .ssh Verzeichnis mit den korrekten Rechten erzeugt. Das ganze sollte in etwas so aussehen:

$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Password: 

Dabei steht ~/ für das Homeverzeichnis des gerade angemeldeten Benutzers. Dann muss die PubKey Auth in ssh aktiviert werden. In der Regel ist es dazu nicht nötig, /etc/ssh/sshd_config zu bearbeiten (Stand OpenSSH_5.8p1-hpn13v11, DSM 4.1), denn die dort auskommentierten Schlüssel geben die default-Einstellung an. Wer sich damit besser fühlt, kann aber das Kommentarzeichen (#) vor den folgenden Direktiven entfernen

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Schlüssel erstellen

Nun muss ein Schlüsselpaar erzeugt werden. Hier unterscheiden sich die Clients.

Windows

Erstellen eines Public-Private Key Pairs

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

Erstellen eines Public-Private Key Pairs

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

Erstellen eines Public-Private Key Pairs

Am Schluss gebt ihr für den Private Key ein Passwort vor und klickt auf Save PrivateKey. 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

Mac OS X, Unix

Unter unixoiden Betriebssystemen mit installiertem OpenSSH kann man das Kommandozeilenprogramm ssh-keygen zur Schlüsselgenerierung benutzen. Bei Mac OS X kann man dazu das Programm Terminal (im Order /Programme/Dienstprogramme) ausführen und in der Shell den Befehl eingeben. ssh-keygen fragt nach einem Speicherort (voreingestellt ist ~/.ssh/id_rsa) und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix .pub erhält.

Nachdem Erstellen der Public Keys muss man noch die Rechte der beiden Dateien ändern, da man sie sonst nicht auf die DS kopieren kann. (regulär werden die Public Keys mit 0644 angelegt, was aber zu wenig restriktiv ist) Andernfalls würde man die Fehlermeldung: Permissions 0644 for '/Users/USERNAME/.ssh/id_rsa' are too open. bekommen

$ chmod 0600 ~/.ssh/id_rsa*

Public Key auf der DS eintragen

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>>

Mac OS X, Unix

Die Methode mit der Zwischenablage funktioniert auch hier, aber es ist viel eleganter, eine Pipe zur Übertragung des Public Key zu benutzen.

$ cat ~/.ssh/id_rsa.pub |ssh BenutzerName@NameOderIPderDiskStation "cat >> .ssh/authorized_keys"
<<Passwort-Abfrage>>

Wichtig ist, den Public Key zu kopieren, erkennbar am Suffix .pub. Dabei müssen BenutzerName und NameOderIPderDiskStation (und gegebenenfalls ~/.ssh/id_rsa.pub) durch die passenden Werte ersetzt werden. Benutzer von Linux können stattdessen auch ein Auge auf den Befehl ssh-copy-id werfen.

Alternativ kann man auch scp benutzen. Der Public Key muss dann aber auf der DiskStation manuell eingetragen werden.

$ scp ~/.ssh/id_rsa.pub BenutzerName@NameOderIPderDiskStation:/Pfad/zum/Home/
$ ssh Benutzer@NameOderIPderDiskStation
<<Passwort-Abfrage>>
$ cat id_rsa.pub >> .ssh/authorized_keys

Hier ist neben den oben genannten auch /Pfad/zum/Home/ durch den richtigen Wert zu ersetzen (den passenden Wert kann man durch Eingabe von pwd direkt nach dem Einloggen auf der DiskStation herauskriegen).

Backup Zugang für alle Fälle

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.

Testlauf

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: Vor der DSM-Version 5.0

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

Ab der DSM-Version 5.0

$ synoservicectl --reload sshd

Alternativ kann in der Weboberfläche auch ssh ab- und wieder angewählt werden (jeweils auch übernehmen!). Damit sollte der Daemon neugestartet sein und auf Anfragen warten.

Windows

Zum Testen der PubKey Anmeldung verwendet ihr am besten wieder Putty. Erstellt bei Putty und Hostname eine Verbindung in der Art BenutzerName@NameOderIPderDiskStation 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.

Mac OS X, Unix

Hier kann man auf der Kommandozeile ssh BenutzerName@NameOderIPderDiskStation -i [Pfad zum Private Key] ausführen. Ist der Private Key an der Standardstelle ~/.ssh/id_rsa, kann der Parameter -i samt Pfad auch entfallen. Beim ersten Ausführen kommt eine Passwortabfrage für den Private Key. Die Frage nach dem Passwort kommt nicht von der DS, sondern von Putty bzw. dem lokalen ssh. 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

Finale Anpassungen

Anmeldung mit Passwort ausschalten

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 /etc/ssh/sshd_config eine weitere Konfig Var setzen und den SSH Daemon nochmals 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.

Passwort des Private Key speichern

Wenn man zu faul ist, bei jeder Verbindung zur DiskStation das Passwort des Private Key angeben zu müssen, gibt es Mittel und Wege.

Windows

Hier 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 BenutzerName@NameOderIPderDiskStation ö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.

Mac OS X

Apple hat OpenSSH so erweitert, daß das Passwort des Private Key im benutzereigenen Schlüsselbund gespeichert werden kann (dieser ist mit dem Programm Schlüsselbundverwaltung im Ordner /Programme/Dienstprogramme einseh- und veränderbar). Dazu führt man im Terminal

$ ssh-add -K [Pfad zum Private Key]

aus. Ist der Private Key in ~/.ssh/id_rsa, kann die Pfadangabe entfallen. Das dann einzugebende Passwort des Private Key wird im Schlüsselbund Anmeldung gesichert und ist damit nach jedem Benutzer-Login ohne weitere Passwortabfrage verfügbar.

Hintergrund

Das Private/Public-Key Verfahren wurde in den späten 50-iger Jahren von Kryptografen des englischen Militärs entwickelt. Durch die damals herrschende Geheimhaltung wurde diese Entwicklung nicht publik und so galten dann die Herrn Diffie und Hellman in den 70-iger Jahren als Entdecker von Public Key. Sie lösten mit "ihrer" Erfindung die zwei grundlegendsten Probleme der Kryptografie:

  • Schlüsselverteilungsproblem
  • Schlüsselaustauschproblem

Schlüsselaustauschproblem

Das grundlegende Problem hierbei ist: Wie können sich Alice und Bob auf ein Geheimnis einigen (Schlüssel) über ein unsicheres Medium? Ohne dass Carl mit den Informationen etwas anfangen könnte? Dieses Problem bereitete Generationen von Kryptografen schlaflose Nächte. Hellman konzentrierte sich auf dieses Problem und sah folgende Einwegfunktion als optimal an:
Yx (mod P) = N
Alice und Bob sprechen miteiander erst die Werte für Y (7) und P (11) ab. Diese sind nicht geheim und Carl darf diese kennen. Solange P grösser als Y ist, sind eigentlich alle Zahlen erlaubt.

AliceBob
Stufe 1wählt einen Wert für x (3) Das ist der geheime Teilwählt einen Wert für x (6) Das ist der geheime Teil
Stufe 273(mod 11)= 343(mod 11)= 276(mod 11)= 117649(mod 11)= 4
Stufe 3Senden des Resultats an BobSenden des Resultats an Alice
AustauschNormalerweise ist das der kritische Moment beim Austausch von sensitiven Informationen. Carl kann die jeweiligen Resultate abfangen. Es ist jedoch gerade der Clou dieser Idee, dass diese Informationen nicht ausreichen, weil sie eben nicht der Schlüssel sind. Carl kann damit überhaupt nichts anfangen, wie wir gleich sehen werden
Stufe 4wendet Bob's Resultat mit ihrem geheimen x an
43(mod 11)=64(mod 11)=9
wendet Alice's Resultat mit seinem geheimen x an
26(mod 11)=64(mod 11)=9
SchlüsselWie durch ein Wunder kommen Alice und Bob auf die gleiche Zahl, ohne diese Information ausgetauscht zu haben!! Das ist der Schlüssel für die sichere Kommunikation zwischen Alice und Bob

Es gibt in den meisten Büchern zum Thema asymmetrische Verschlüsselung das schöne Beispiel:

Alice lebt im Land Korruptien und will eine Kiste an Bob senden. Sie weiss, dass Eve bei der Post arbeitet und auch dass bei der Post nur Eve's arbeiten. Also muss sie die Kiste resp den Inhalt für Bob schützen können. Also legt sie eine Kette darum und schliesst diese mit einem Schloss zu dem nur sie den Schlüssel hat.
Dann schickt sie die Kiste auf die Reise zu Bob. Der wiederum hängt ein weiteres Schloss an (auch da hat nur er den Schlüssel) und schickt die Kiste wieder zu Alice. Diese entfernt ihr eigenes Schloss und schickt die Kiste wieder zu Bob. Der kann sein Schloss dann entfernen und die Kiste öffnen.

Um im obigen Beispiel zu bleiben haben Diffie-Hellman dafür gesorgt, dass alle Bewohner von Korruptien, die geheime Meldungen austauschen wollen, ihr Schloss öffentlich zugänglich machen können. Dann kann Alice direkt das Schloss von Bob verwenden und der Round-Trip wird vermieden.
Auch dieser Vergleich wird dem Public-Key Verfahren nicht ganz gerecht. Denn um bei einem Vorhängeschloss zum Schlüssel zu kommen (zumindest zu einer Kopie) ist kein grosser Aufwand nötig. Im Public-Key Verfahren wird dieser Weg durch die Verwendung von modularer Arithmetik, Einwegfunktionen und sehr sehr grossen Primzahlen deutlichst erschwert.

Aber wichtig ist auch sich immer vor Augen zu halten, dass es mit Brute-Force Attacken auf den öffentlichen Schlüssel durch Durchprobieren aller Möglichkeiten bei JEDER Schlüssellänge immer irgendwann gelingen wird den Privaten Schlüssel zu "errechnen" (das ist mathematische Gewissheit). Kann sein, dass es jede Sekunde durch einen Zufallstreffer soweit ist. Die Sicherheit bei Public-Key beruht darauf, dass es bis heute als unmöglich gilt, dass die beiden Faktoren eines Produkts aus zwei Primzahlen anders als mit Primfaktorzerlegung gefunden werden können. Und die Zeit die nötig ist zur Faktorisierung der Primfaktoren steigt exponetial zur Schlüssellänge. Sollte es also jemandem gelingen diesen Weg der Faktorisierung zu umgehen (und sei es auch der komplizierteste Algorithmus den die Welt je gesehen hat), dann sind wir verschlüsselungsmässig wieder in der Steinzeit und tauschen Schlüssel wieder persönlich aus.

Im Gegensatz dazu bieten entsprechende symmetrische Verfahren die mathematische Gewissheit, dass sie nicht gebrochen werden können. Denn durch das durchprobieren aller Schlüssel bei solchen Verfahren entstehen mit Sicherheit mehrere sinnvolle Klartexte

Mit dem Originalschlüssel ergibt sich aus der Chiffre etwas komplett anderes als mit einem anderen Schlüssel und der gleichen Chiffe (verschlüsselter Text)

Schlüssel:  P L M O E Z Q K J Z L R T E A V C R C B Y
Klartext:   a t t a c k t h e v a l l e y a t d a w n
Chiffre:    P E F O G J J R N U L C E I Y V V U C X L
 
Jetzt probiert der Kryptoanlytiker folgenden Schlüssel
 
Schlüssel:  M A A K T G Q K J N D R T I F D B H K T S
Klartxt:    d e f e n d t h e h i l l a t s u n s e t
Chiffre:    P E F O G J J R N U L C E I Y V V U C X L

Schlüsselverteilungsproblem

Hellman konzentrierte sich auf das Schlüssel-Tausch-Problem (obige Tabelle) und Diffie suchte nach einer völlig neuen Lösung der Schlüssel-Verteilung. Bis anhin war es so, dass die verwendeten Schlüssel der symmetrischen Verschlüsselung physisch überbracht werden mussten. Dazu wurden Kuriere eingesetzt, was natürlich sehr risikoreich war. z.B. mussten Banken tausende von Schlüsseln an Filialen und Kunden ausliefern und diese aus Sicherheitsgründen immer wieder zu erneuern. Wenn einer der Schlüssel kompromitiert wurde, dann mussten wieder neue Schlüssel an die Betroffenen ausgeliefert werden. Eine Übertragung der Schlüssel via Telefon (unsicheres Medium) kam nicht in Frage, da bei symmetrischen Verschlüsselungen der Schlüssel nicht nur zum Ver-sondern auch zum Entschlüsseln gebraucht wird. Carl könnte die Schlüssel sonst mithören und die Kommunikation zwischen Alice und Bob entschlüsseln. Auch könnte er den Kurier, der den Schlüssel von Alice zu Bob bringt, überfallen und ihm den Koffer klauen oder den Schlüssel unbemerkt kopieren!

Und genau hier kommt die volle Eleganz eines Public-Key-Verfahrens zum Tragen. Nicht nur, dass Alice und Bob sich auf einen Schlüssel einigen können ohne diesen austauschen zu müssen, die asymmetrische Methode und ihre zwei Schlüssel sorgt dafür, dass Alice ihren Public Key der ganzen Welt via ein unsicheres Medium (damals Telefon, heute Internet) bekanntmachen kann. Sie muss nicht befürchten, dass jemand mit diesem Schlüssel an sie gerichtete Meldungen entschlüsseln kann Alice und Bob können ihre öffentlichen Schlüssel der ganzen Welt zugänglich machen, damit ihnen diese verschlüsselte Mitteilungen senden können. Dazu werden vorzugsweise öffentliche Key-Server eingesetzt.

Diffie und Hellman lösten damit zwei der grössten Probleme der Kryptografie auf einen Schlag und legten den Grundstein für praktisch alle heute eingesetzten Kryptosysteme. Sie sorgten dafür, dass sich Alice und Bob auf ein Geheimnis einigen können ohne diese Information wirklich zu senden (Schlüssel-Austausch-Problem) und dafür, dass ein Schlüssel völlig risikolos öffentlich zugänglich gemacht werden kann (Schlüssel-Verteilungs-Problem). Die Sicherheit aller bisherigen Kryptosysteme kam an einem oder beiden dieser Probleme an die Grenzen

Zum Schluss

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

Beispiel svn

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

Von DiskStation zu DiskStation

Will man sich mit ssh von einer DiskStation auf einer anderen einloggen und dabei Schlüsselpaare einsetzen, kann man diese Anleitung befolgen. Hierbei muss man dann jeweils den Unix-Teil der Konfiguration ausführen.