Zum Thema gibt es einiges zu finden, manches übersichtlich, manches weniger, es gibt vollständige Anleitungen und weniger vollständige, genauer, unvollständige, mit denen es nicht klappt, und um einfach die Wahrscheinlichkeit zu erhöhen, auf einen Artikel zu stoßen, der _ALLES_ wichtige erwähnt, habe ich diesen hier erstellt. Damit also einfach einer mehr im Netz steht, der die Sachlage vollständig dokumentiert.

Los geht’s:

Sie wären nicht hier, wenn Sie Telnet für Ihre Remote-Logins verwenden wollten, nehme ich mal an. Sie verwenden SSH, wollen sich aber ohne Paßwort anmelden.

Okay, dem hat Synology einen Riegel vorgeschoben! Um den zur Seite zu schieben, loggen wir uns auf der Webverwaltungsoberfläche der Synology-Station ein, öffnen das Control Panel und klicken auf Terminal & SNMP.

Im ersten Tab, Terminal, aktivieren wir den Telnet-Dienst, und SSH werden Sie schon aktiviert haben, oder? Wenn nicht, dann tun Sie es jetzt.

Es wird oft gesagt, man solle den Default-Port 22 nicht verwenden und stattdessen irgendeine andere, hohe (vierstellige) Portnummer wählen. Was, bitte schön, soll das denn bringen? Security by obfuscation? Sorry, aber das finde ich lächerlich. (Ich habe es gerade extra recherchiert: Es gibt Admins, die ihre Server mit direktem Zugang zum Internet auf einen anderen Port setzen, aber das tun sie, um z. B. ihre Logfiles etwas kürzer zu halten. An Sicherheit bringt das keinerlei Gewinn. Und wer liest Logfiles schon persönlich? Am besten als Ausdruck auf Endlospapier vom Nadeldrucker?) Wer an Ihre Station so nahe herangekommen ist, der wird auch den Port ausfindig machen, auf dem der sshd antwortet. Aber es schadet nichts, wenn Sie einen anderen Port benutzen, nur sollten Sie das dokumentieren. Und Sie müssen dann bei jedem Login den Port mit angeben, sonst klappt’s nicht.

Warum jetzt die Telnet-Aktivierung? Ganz einfach: Weil Dinge, die schiefgehen können, schiefgehen. Und wenn wir uns jetzt aussperren, gucken wir unter Umständen dumm aus der Wäsche. Wenn Sie z. B. beim nächsten Schritt die SSH-Konfiguration zerschießen, werden Sie Schwierigkeiten haben, das zu reparieren. Also, lieber Telnet aktivieren, und später nicht vergessen, es wieder zu deaktivieren.

Wie schon angedeutet, jetzt müssen wir die SSH-Konfiguration ändern. Dazu loggen Sie sich auf der Station ein, egal wie, aber Sie benötigen ein Kommandozeilen-Prompt.

Geben Sie ein

sudo su

Jetzt sind Sie Bruce Allmächtig!

Machen Sie eine Sicherheitskopie der Datei /etc/ssh/sshd_config, denn die wollen wir nun bearbeiten.

Geben Sie ein:

vi /etc/ssh/sshd_config

Entfernen Sie die Raute vor diesen beiden Befehlen:

#RSAAuthentication yes
#PubkeyAuthentication yes

(Nachtrag: Ich habe gerade Tests auf einer zweiten Station gemacht. Auf dieser hat die Option PubkeyAuthentication yes ausgereicht! Testen Sie das ruhig, wenn Sie Zeit und Lust haben. Man lernt nie aus… )

Speichern Sie und starten Sie den sshd neu:

synoservicectl --reload sshd

Jetzt stimmt die SSH-Konfiguration auf der Serverseite. Aber jetzt müssen Sie für Ordnung in Ihrer Verzeichnisstruktur sorgen: Für einen Account, in den man sich per SSH ohne Paßwort einloggen kann, fordert die SSH, daß:

1. Das  Home-Directory mit chmod 700 auf die richtige Berechtigungsstufe gesetzt wurde.
2. Das .ssh-Verzeichnis eine Stufe tiefer ebenso.
3. Die Schlüsselfiles, zumindest das des privaten Schlüssels, sollten ebenfalls mit chmod 700 entsprechend geschützt sein.

Wenn z. B. das Home-Dir auf den Vorsteinstellungen von Synology bleibt, haben Sie keine Chance!

Jetzt können Sie sich ausloggen und sich dem Client widmen. Wenn Sie bereits ein Schlüsselpaar haben, prima, wenn nicht, legen Sie eines an, am besten mit

ssh-keygen -t rsa Hotzenplotz@10.10.10.13

Jetzt können Sie den öffentlichen Schlüssel mit folgendem Befehl mit einem Rutsch übertragen, ohne sich auf der Kommandozeile weiter abzuplagen:

ssh-copy-id -i ihreprivateschlüsseldatei Hotzenplotz@10.10.10.13

Sie werden noch einmal um das Paßwort des Allmächtigen gebeten, und wenn Sie alles richtig gemacht haben, dann war’s das. Wenn Sie jetzt versuchen, sich mit

ssh Hotzenplotz@10.10.10.13

anzumelden, sollte das klappen. Wenn nicht, können Sie per Telnet wieder rein und reparieren, was zu reparieren ist.

Wenn alles klappt, Telnet deaktivieren!

Viel Erfolg!

PS:

Es ist klar, daß Sie die Passphrase für Ihren Schlüssel eingeben müssen, wenn dieser mit einer solchen geschützt ist. Wenn Sie auch das nicht haben wollen, müssen Sie keinen neuen Schlüssel ohne Passphrase erzeugen, sondern können die Passphrase vom vorhandenen Schlüssel entfernen:

ssh-keygen -p -f ~/.ssh/privatekey -P "Alte Passphrase" -N "neue oder leere Passphrase"