SSH absichern – BASICS – vom Passwort zum Schlüssel

Die dritte Maßnahme ist die umfangreichste. Hierfür müssen wir erst ein Schlüsselpaar erzeugen. Das „Schloss“ wird in einer Datei auf dem Server gespeichert, der „Schlüssel“ auf unserem PC. Dann weisen wir PuTTY an, den Schlüssel zu verwenden und wir passen sshd_config erneut an.

Unser Lohn ist eine nochmals deutlich schwerer zu crackende SSH-Verbindung.
Viel Arbeit. Packen wir’s an!

Aktuell: Ja
System: Linux / Unix generic. Hier vorgestellt auf Debian 7 „Wheezy“

Achtung!
Bitte vor dem Editieren der Konfigurationsdatei eine Sicherheitskopie davon erstellen! In der Einleitung wird beschrieben, wie wir das erledigen…

Wie eingangs erwähnt, haben wir noch ein paar Sachen zu tun, bevor wir uns das erste Mal mittels eigenem Schlüssel / Schloss am Server anmelden können.

Bitte lies Dir die folgenden Anleitungen durch, weil wir sie für dieses Tutorial brauchen werden:

Gut, gut. Wenn Du so weit bist, fangen wir an:

Öffne Dein TrueCrypt Volume und lege dort ein Verzeichnis „keys“ an.

Starte pwgen und erzeuge damit einen Haufen ’sichere‘ Passwörter mit 32 Zeichen Länge. Dann legst Du eine neue Text-Datei im TrueCrypt Volume an, in welche Du diese Passwörter hinein kopierst. Sie dient uns als „Pool“, wenn wir später ein neues, starkes Passwort benötigen.

Bitte lege noch eine Text-Datei an. Ich nenne diese Datei wie den Host des Servers, damit ich gleich weiß, welche Datei für welchen Server ist.

Starte nun den PuTTYgen und erzeuge damit ein SSH-2/RSA Schlüsselpaar von 8192 Bit Länge.

puttygen-4 In das Kommentarfeld (2) kommt der Host vom Server und der Benutzername, für den wir den Schlüssel erstellt haben.

Das Passwort nimmst Du aus der Passwort-Textdatei. Wir möchten hier 64 Zeichen, also zwei 32er PWs hintereinander. Dieses kopierst Du dann in PuTTYgen in die Zeile (3) und die neu erstelle Textdatei vom Server.

Nun speichere den „privaten“ Schlüssel (4) in das „keys“ Verzeichnis Deines TrueCrypt Volumes. Als Dateinamen wie beim Kommentar den Host des Servers und den Benutzernamen angeben.

Der öffentliche Teil des Schlüsselpaars, das „Schloss“, ist oben in der Zeile „Public Key for pasting into OpenSSH authorized_keys file“ (1). Hier rechts klicken und „Alles auswählen“ anklicken. Den Inhalt kopierst Du per Strg+C / Strg+V in Deine Server-Text-Datei. Dazu schreibe ich noch ein paar Worte, wer was ist. Aber das weißt Du sicher selber am Besten, wie Du diese Datei gestaltest. Wichtig ist nur, dass sie niemals das TrueCrypt Volume verlassen darf…

Test-VM
=======
OpenSSH Key: ssh-rsa AAAAB3NzaC1yc2EAA ... pB3w2q1ZYCnLu+yjuC2yaFV1mq4w== rsa-key-20150810-debvm-bla
PW: I=~HAg@dZps%;.dudS&^~z(8XB9t_V6eXq:^4uO;DF#.zb%.:/W^lb4’4M=Vi.7@

Jetzt haben wir alles beisammen, um auf „Schlüssel / Schloss“ umzustellen!

Wir loggen uns als ‚bla‘ auf dem Server ein – bei Dir ist das natürlich Dein Benutzer, also nicht ‚bla‘.
Jetzt legen wir die Datei authorized_keys an und kopieren den öffentlichen Schlüsselteil – das Schloss – hinein. Anschließend sichern wir die Datei vor fremden Blicken ab. Das wird auch vom SSH-Daemon verlangt. Ist die Datei für jeden les- und schreibbar, wird sie aus Sicherheitsgründen nicht akzeptiert und wir bekommen eine Fehlermeldung im Log.

mkdir /home/bla/.ssh
nano /home/bla/.ssh/authorized_keys
Hier nun den ‚Public Key‘ aus der Server-Text-Datei hinein kopieren.
Wichtig! Der Key muss EXAKT IN EINE ZEILE gepostet werden. Kein Zeilenumbruch, sonst klappt es nicht.
sudo chown bla:root /home/bla/.ssh/authorized_keys
sudo chmod 0600 /home/bla/.ssh/authorized_keys

Das war der ganze Zauber… Ab jetzt sollte die Anmeldung des Benutzers „bla“ über „Schlüssel / Schloss“ funktionieren, da diese Anmeldemethode beim SSH-Daemon von Debian 7 parallel zur Eingabe eines Passworts funktioniert.

putty-09-auth
Also machen wir eine neue Verbindung in PuTTY und stellen aber diesmal auf das Public Key Verfahren um. Diese Optionen verstecken sich unter Connection / SSH / Auth.
Wir entfernen den Haken bei „Attempt ‚keyboard-interactive‘ auth“ und fügen in der Zeile „Private key file for authentication:“ den Pfad und Namen unseres Schlüssels im TrueCrypt Volume hinzu. Hier am Besten auf „Browse“ klicken und dann auf den Schlüssel doppelklicken.

Bauen wir über diesen neuen Eintrag eine Verbindung zum Server auf, werden wir nicht mehr nach dem Passwort des Benutzers „bla“ gefragt, sondern nach dem Passwort des Schlüssels. Nach dessen Eingabe sind wir – hoffentlich – erfolgreich eingeloggt :)

Wenn der Login funktioniert, ändern wir eine Zeile in der der Konfigurationsdatei sshd_config, um zukünftig das Einloggen eines Benutzers per Passwort zu verbieten:

sudo nano /etc/ssh/sshd_config

Wir suchen die Rubrik
# Change to no to disable tunnelled clear text passwords

Dort interessiert uns die Option
#PasswordAuthentication yes

Diese Zeile ändern wir auf
PasswordAuthentication no
wir entfernen also die Raute (#), stellen auf ’no‘ und speichern die Datei. Damit verbieten wir das Übermitteln von getunnelten „Klartextpasswörtern“ über SSH.

Nun ist es wieder enorm wichtig, wie bei der Änderung der Port-Nummer vorzugehen und nach dem Neustart des SSH-Daemons unbedingt mit einer zweiten Verbindung zu testen, ob wir uns als der neue Benutzer wirklich per Schlüssel an unserem Server anmelden können. Danach testen wir noch einmal das ‚alte‘ Verfahren mit „Benutzer / Passwort“.

Funktioniert alles wie geplant – also Login per Schlüssel geht, Login per Passwort geht nicht – schließen wir die alte SSH-Verbindung.
Ab diesem Zeitpunkt sollten wir uns als „bla“ nicht mehr mit einem Passwort, sondern nur noch mit dem Schlüssel am Server anmelden können…

Ansonsten heißt es Fehlersuche. Finden wir den Fehler nicht, kopieren wir die Konfigurationsdatei zurück und starten SSH neu.

And there we have it :)
So einen Schlüssel kann man (nach aktuellem Wissensstand) unmöglich mit einem Wörterbuch brechen. Jeder Versuch, über ein normales Passwort eine Verbindung zum Server aufzubauen, wird vom SSH-Daemon geblockt und die Verbindung geschlossen. Wir können uns nur noch mit dem zusätzlich durch ein Passwort geschützten Schlüssel am Server anmelden!

Damit endet die Serie über die grundlegenden Sicherheitsmaßnahmen für SSH.

Die drei wichtigsten Absicherungen für den SSH-Daemon…
Das haben wir erledigt:

  • Der Bot des Crackers findet den SSH-Port nicht. Wir sollten also nicht mehr auf den ‚ausprobier‘-Listen landen.
  • Unser „root“ Benutzer darf sich nicht per SSH am Server anmelden. Selbst, wenn der Cracker den neuen SSH-Port hat, muss er erst einmal auf unseren Benutzernamen kommen.
  • Das „Schlüssel / Schloss“ Anmeldeverfahren sorgt für zusätzliche Sicherheit! Nach derzeitigem Kenntnisstand ist ein 8k-Schlüssel in einem verschlüsseltem Volume mit zusätzlichem 64-stelligem Passwort tatsächlich „sicher“.

Zögere nicht zu lange!
Diese drei Sicherungen sind relativ schnell eingerichtet und sollten den Script-Kiddies dann einiges an Kopfschmerzen bereiten ;)

Navigation

< Vorheriger Artikel | HOME

Haftungsausschluss!

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.