Public Key Authentication an Ubuntu OpenSSH mit Windows puTTY-Client

(Last Updated On: 25. Dezember 2016)

Wie funktioniert Public Key Authentication?

Anstatt eines Passwortes verifiziert der Server den Login eines Benuzters über Schlüsselpaare. Es gibt einen privaten Schlüssel und einen öffentlichen Schlüssel. Der öffentliche Schlüssel bleibt bei dem PC, von dem aus ihr euch auf den Server verbinden wollt. Es ist empfohlen, für jeden Rechner einen extra Schlüssel zu haben. Der öffentliche Schlüssel wird aus dem privaten Schlüssel erstellt und wird auf dem Server hinterlegt. der öffentliche Schlüssel ist im Klartext ersichtlich – es ist nicht schlimm, wenn den öffentlichen Schlüssel jemand in die Finger kriegt, denn der Client, also der Teil, der sich zum Server verbinden will, muss in seinen SSH-Client den privaten Schlüssel eingepflegt haben. Der öffentliche Schlüssel bringt einem Angreifer gar nichts, denn dieser Schlüssel liegt nur auf dem Server.

Wenn jetzt im Gegenzug jemand den privaten Schlüssel von euch klaut, dann kann er daraus aber ebenfalls nicht ohne weiteres etwas anfangen. Denn um diesen Schlüssel in seinen eigenen Client einspeisen zu können, muss er wiederum ein Passwort eingeben, mit welchem ihr zuvor euren privaten Schlüssel gesichert habt – der private Schlüssel ist nämlich im Gegensatz zum öffentlichen Schlüssel enkryptet und kann nur mit Hilfe des Passwortes entschlüsselt werden.  Außerdem braucht er das Passwort, um einen öffentlichen Schlüssel zu generieren, was vielleicht nötig ist, wenn dieser noch nicht auf dem Server der Wahl hinterlegt ist.

Installation und Erstkonfiguration des SSH-Servers

Der erste Schritt ist, einen SSH server auf  dem SErver zu installieren, falls noch nicht geschehen. Bei einem SErverhoster ist das bereits passiert, aber wenn ihr euren eigenen Server zusammenbaut und diesen später von zu Hause aus hosten oder ins Rechenzentrum stellen wollt, dann ist das wieder eine andere Geschichte.

sudo apt-get install openssh-server

Wenn wir hier eine Meldung bekommen wie „Nothing to do“, dann ist der Server bereits instaliert.

Jetzt machen wir ein Backup der Datei /etc/ssh/sshd_config. Wichtig ist dabei das in sshd! Denn nur die ist die Config-Datie für den Server. die Datei /etc/ssh/ssh_config ist zuständig für den SSH-Client!

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.facotry-defaults
sudo chmoda-w /etc/ssh/sshd_config.factory-defaults

Das Backup ist jetzt read-only und kann nicht so ohne weiteres überschrieben werden. Jetzt können wir die Datei mit dem Editor vi oder einem anderen Editor unserer Wahl editieren.

Jetzt vergeben wir erste Intialeinstellungen für den SSHd, indem wir die datei sshd_config editieren und folgende einstellungen festlegen (wenn in der Originaldatei ein #-Zeichen am Anfang der Zeile ist, muss dies entfernt werden.

Port <Port_über_den_ihr_connecten_wollt>

diese einstellung bestimmt den Port, den ihr bei putty angeben müsst, um euch auf den SErver zu verbinden. Es wird generell empfohlen, einen anderen Port (nicht Port 22) größer als 1024 zu verwenden, um sich dadurch ein wenig gegen automatisierte Angriffe zu schützen. Solltet ihr jedoch eine Firewall auf dem Server verwenden, müsst ihr vorher sichergehen, dass er neue Port in dieser Firewall freigeschaltet ist. Wenn ihr nicht wisst, wie das geht, solltet ihr die finger davon lassen.

Eventuell wollt ihr verhindern, dass man andere Verbindungen über euren SSH Server tunneln kann. Es ist über SSH beispielsweise möglich, eine X11-Verbindung zu tunneln und dadurch grafische Oberflächen des Servers zu starten. Wenn ihr selbst auf solche Funktionalitäten angewiesen seid, solltet ihr es natürlich lassen. Es ist aber allgemein sicherer, sie zu deaktivieren, wenn man sie nicht braucht oder nicht weiß, wie das geht.

AllowTcpForwarding no # deaktiviert SSH-Tunneling
X11Forwarding no # deaktiviert X11 Fowarding

Dann wollt ihr vielleicht einstellen, dass nur bestimmte User-Accounts sich über SSH einloggen können. es ist beispielsweise gängige Praxis, zu verhindern, dass sich der User „root““ direkt am über SSH einloggen kann. Dazu müssen allerdings die anderen User, die mit root-Rechten arbeiten können, mittels sudo an die root-Rechte kommen können. Wenn ihr davon keinen Schimmer habt, solltet ihr auch diese Einstellung in ruhe haben. Aber ihr könnt auch verhindern, dass sich andere User über SSH anmelden können. Wenn es nur sehr wenige User gibt, die SSH nutzen wollen, kann man einfach die Usernamen dieser User in der einstellung AllowUsers eingeben.

AllowUsers Fred Wilma # erlaubt die User Fred und Wilma

Ist es umgekehrt, also wollen viele user SSH nutzen und nur wenige sollen ausgepserrt sein, kann man die Letzteren über die Option DenyUsers aussperren

DenyUsers Fred Wilma # sperrt die User Fred und Wilma aus SSH

Es ist außerdem empfehlenswert, zu verhindern, dass man sich direkt als root-User per SSH einloggen kann. Dazu müssen Sie dann alelrdings zuvor bereits sudo konfiguriert haben.

PermitRootLogin no
PermitEmptyPasswords no

Desweiteren deaktivieren wir host-based authentication. Wenn aktiivert würde es heißen, dass wir vertrauenswürdigen hosts erlauben, sich ohne Passworteingabe einzuloggen, wenn es auf diesen einen gleichanmigen user gibt. Wenn wir auf unserem server server1.dafrk-blog.com als vertrauenswürdigen host einen anderen rechner namens server2.dafrk-blog.com kofniguriert haben, und es auf diesem ebenfalls einen user dafrk gibt, dann darf sich der user dafrk per ssh auf server1.dafrk-blog.com einloggen, ohne ein Passwort einzugeben. Da wir dies in 90% aller fälle nicht brauchen werden, entfernen wir diese Möglichkeit über

HostBasedAuthentication no

Eine komplizierte re Einstellung ist die MaxStartups einstellung. Es ist gut, sich gegen automatisierte Angriffe auf einen SSH-Server zu schützen, indem man einstellt, wie viele sogenannte pending connections der Server erlaubt. pending connections sind solche Anfragen an den SSH Server, bei denen ein Client anfragt für einen bestimmten User das Passwort einzugeben, aber isch noch nicht erfolgreich eingeloggt hat. Automatische Anfragen machen das dauernd – sie wollen sich als ein user einloggen und probieren dann irgendein Passwort auf gut Glück aus. mit einer Limitierung kann man hier solchen Auto-Angriffen oft den Garaus machen.

die folgende einstellung erlaubt grundsätzlich zwei Pending-Connections. aber der dritten Verbindung werden zufällig 30 % aller pending connections getrennt, und ab der zehnten Verbindung werden alle pending connections getrennt.

MaxStartups 2:30:10

diese Anzahl kann auf einem Sstem, auf welchem sich viele User per SSH tummeln, zu klein sein. also wisst, was ihr da tut!

Desweiteren kann man einstellen, wie viel Zeit ein Benutzer hat, um sich in seiner pending Connection einzuloggen. die folgende einstellung trennt eine Verbindung, wenn ein Benutzer länger als 30 Sekunden braucht, um sich einzuloggen.

LoginGraceTime 30

jetzt ist unser SSHd grundkonfiguriert. wir müssen die neuen einstellungen aber erst noch laden. Vorher solltenw ir sichergehen, dass der port 22 (oder ein anderer port den wir in der config festgelgt haben) in der firewall freigeschaltet ist. Das Neustarten geht dann über

sudo restart ssh

Initialtest mit Putty

Jetzt wollen wir uns mit putty einloggen. Dazu nehmen wir die IP-Adresse oder den Hostnamen des Servers und ändern den Port, sollten wir diesen in der Erstkonifugraiton umgelegt haben. Danach können wir über den Button Load auf den Server connecten.

2014-10-28_20h15_34

 

eventuell müssen wir einen PuTTY Security Alert wegklicken, der uns darüber informiert, dass  wir den Public Key des SSH-Servers akzeptieren müssen. Diese Meldung einfach mit Yes bestätigen.

wir versuchen nun, uns mit dem root-Account und seinem Passwort einzuloggen. damit stellen wir erstmal sicher, dass in dieser Richtung alles in Ordnung ist. funktioniert der Login auf dem Server, erhalten wir eine kommandozeile, mit der wir arbeiten können.

2014-10-28_20h19_21

Jetzt haben wir sichergestellt, dass der SSH-Server aktuell funktioniert.

Generieren der Schlüssel

Das Generieren der schlüssel geschieht in der Regel auf dem Client, also auf dem Rechner, der sich später zum Server verbinden soll. Schließlich wird ja auch dort der private Schlüssel – der wichtige Schlüssel sozusagen – gespeichert.

Auf Windows-Ebene gibt es dazu das tool puttygen. Diese Öffnen wir und erhalten folgendes Fenster

2014-10-28_20h28_58

Jetzt müsst ihr einen privaten Schlüssel generieren. Das geht über den Button Generate. Während der Ladebalken sich langsam füllt, fahrt ihr mit der Maus über die graue Fensterfläche, um zufällige Werte für die Schlüsselgenerierung zu erstellen.

2014-10-28_20h32_58

Wir können jetzt einen Kommentar hinzufügen. Dieser kommentar wird später dem öffentlichen Schlüssel angehängt und dient dazu, auf dem Server wo dieser hinterlegt wird anzuzeigen, wofür dieser öffentliche Schlüssel gut ist. in der Regel schreibt man dazu, für welchen SSH-Client, also welchen Rechner, dieser öffentliche Schlüssel gedacht ist, also in der Regel einen Namen für euren Rechner.

Die Passphrase ist wie bereits oben angesprochen dafür gut, den privaten Schlüssel zu beschützen, wenn ihn jemand vor euch klaut. Also wählt ein gutes Passwort mit mindestens 13 Zeichen und vielen verschiedenen Zeichentypen (Groß- und Kleinbuchstaben, Zahlen, Sonderzeichen).

Als Typ wählen wir SSH-2 RSa. SSH-2 bezeichnet hierbei die Protokollversion. Heutige OpenSSH-Server, die frisch installiert werden, haben alle die SSh-Protokollversion 2, also die aktuelle. Und RSA ist das sichere der beiden Verschlüsselungsverfahren, also in der Regel die bessere Wahl vor dem unsicheren Ableger DSA. die Schlüssellänge von 2048 Bits ist ebenfalls in Ordnung.

Jetzt geht ihr auf den Button „Save Private Key“ und speichert den privaten Schlüssel in einem euch leicht zugänglichen Ordner als .ppk-Datei.

Den Public Key speichert ihr NICHT über die Schaltfläche „SAve public Key“. der grund ist folgender: Ein öffentlicher Schlüssel (und auch ein privater übrigens) kann auf zwei Arten formatiert sein: Einmal in der Schreibweise für com.SSH (ein alternativer SSH-Server, der überwiegend in älteren oder auf Enterprise-Linux-Systemen verwendet wird) und in der OpenSSH-Variante. Der Button „Save Public Key“ speichert den öffentlichen Schlüssel in der Variante für den com.SSH-Server. Da wir jedoch einen OpenSSh-server haben, machen wir jetzt folgendeS: wir markieren den inhalt des Feldes „Public Key for pasting into OpenSSH authorized_keys file“ und kopieren ihn in unsere Zwischenablage

2014-10-28_20h35_43

als Nächstes öffnen wir einen Texteditor, beispielswiese Notepad++, öffnen ein neues Dokument und stellen sicher, dass beim charset / Zeichensatz / der kodierung UTF-8 ohne BOM eingestellt ist. Danach fügen wir den inhalt des textfeldes in das neue Dokument ein.

2014-10-28_20h37_19

Jetzt speichern wir die Datei als Datei mit beliebigem Namen. Empfohlen wir der Dateiname id_rsa_public.

Übertragung des öffentlichen Schlüssels auf den SErver

Nun haben wir einen privaten und einen öffentlichen Schlüssel auf unserer Festplatte. Jetzt wollen wir den öffentlichen Schlüssel auf den Server übertragen. Das geschieht am besten mit dem programm pscp.exe.

In dem Ordner, in dem ihr die pscp.exe gespeichert habt, rechtsklick ihr mit gedrückter Umschalt-Taste, sodass ihr ein erweitertes windows-kontextmenü habt und wählt dann „eingabeaufforderung hier öffnen“

2014-10-28_20h41_11

dann gebt ihr folgendes in die Eingabeaufforderung ein

pscp.exe "<Pfad_zum_öffentlichen_Schlüssel>" <username_über_den_ihr_euch_einloggen_wollt>@<ip-adresse oder hostname des servers>:<pfad_auf_dem_linux_server_auf_dem_der_schlüssel_gespeichert_werden_soll>

der Pfad fü+r den öffentlichen SChlüsesl auf dem Linux Serve rkönnt ihr beliebig wählen. Nachdem ihr das kommando ausführt, werdet ihr nach dem aktuellen Passwort für diesen Benutzer gefragt. Wenn ihr es richtig eingegeben habt, bekommt ihr eine bestätigung, dass die Datei zu 100% übertragen wurde. ölffnet die Datei mal in einem Texteditor wie vi und geht sicher, dass sie nur eine eine Zeile lang ist. Falls nicht, habt ihr nämlich etwas falsch gemacht – das openSSH-Format verlangt nämlich, dass der öffentliche Schlüssel in einer einzigen Zeile steht. Loggt ihr euch jetzt wie oberen bereits beschrieben ganz normal per puTTY auf euren Server, könnt ihr euch in dem Ordner, in den ihr die Datei hinkopiert habt, dort ansehen.

Jetzt macht ihr folgendes. Ihr erstellt, falls noch nicht vorhanden, im Home-Verzeichnis des Benutzers (normalerweise /home/<username>) den Ordner .ssh

mkdir ~/.ssh

und erstellt dort, falls noch nicht vorhanden, eine Datei namens authorized_keys

cd ~/.ssh
touch authorized_keys

Egal ob die Datei authorized_keys hier schon existierte oder nicht, hängen wir jetzt unseren public key an die datei authorized keys an. Das geht mit

cat "<pfad_zum_öffentlichen_schlüssel>" > "<Pfad zu authorized_keys>"

Sollte die Datie authorized_keys vorher leeer gewesen sein, sollte jetzt ebenfalls nur eine einzige Zeile lang gwesen sein.

Jetzt können wir die Datei mit dem öffentlichen SChlüssel löschen – dieser steht nöämlich jetzt in der Datei authorized_keys und muss deshalb nicht zweimal vorhanden sein. Dann müssen wir noch die Berechtigung 700 und chown für den Benutzer und seine Grupe auf den Ordner .ssh geben. Die Datei authorized_keys braucht ebenfalls einen chown vom Benutzer und ein chmod von 600.

rm id_rsa_public
chown <username>.<gruppe> ~./ssh
chmod 700 ~/.ssh
chown <username<.<gruppe> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Manchmal kann es deswieteren nötig sein, chmod 700 auf das Home-Verzeichnis des Benutzers zu geben

als user:> chmod 700 ~

Zweitkonfiguration des SSHd

Jetzt müssen wir wieder einige Einstellungen im SSHd vornehmen, und zwar grundlegende Konfigurationen zur Public Key Authentication. Zuerst aml müssen wir sichergehen, dass die Einstellung für den Pfad zur Datei authorized_keys so aussieht

AuthorizedKeysFile ~/.ssh/authorized_keys
sudo reload ssh

Damit ist sichergestellt, dass in dem von uns gewünschten Ordner nach dem öffentlichen Schlüssel gesucht wird.

Einpflegen des privaten Schlüssels in den putty-Client.

Wir geben in putty wieder die Daten des Servers ein (IP-Adresse und Port) und wählen dann unter Connection – SSH – Auth den Button „Browse“ an, um unseren privaten Schlüssel (gespeichert als .ppk-Datei), zu öffnen.

2014-10-28_20h57_06

 

Damit wäre die konfiguration von puTTY auch schon abgeschlossen. Damit wir in Zukunft den Schlüssel nicht immer wieder neu suchen müssen, können wir im Startfenster von puTTY die Sitzung über den save-Button speichern, nachdem wir einen Namen für die Sitzung vergeben haben. mit Load können wir sie dann in Zukunft immer wieder laden und haben die nötigen Einstellungen dann bereits getätigt.

Jetzt probieren wir uns wieder auf dem Server einzuloggen. Jetzt fragt uns der putty-Client nicht einfach nur nach einem Passwort für den user XY, sondern nach der passphrase für den Schlüssel <Kommentar_den_wir_vergeben_haben>

2014-10-28_20h59_38

 

Geben wir nun diese Passphrase ein, sind wir eingeloggt. Dabei kann die Passphrase sich natürlich von dem eigentlichen Passwort des Users unterscheiden.

Noch ist jedoch nicht wirklich etwas gewonnen. So oder so – im moment müssen wir schließlich ein Passwort eingeben, um uns einzuloggen. Wie kommen wir nun darüber hinweg? Das geht mit einem weiteren tool namens pageant. Wir führen das programm ab und es legt sich dann in unserer Task Line ab. Über das Symbol mit dem Hut können wir das Programm über die Taskleiste dann aufrufen.

2014-10-28_21h02_22

Wir rechtsklicken auf das Symbol und wählen „Add Key“

2014-10-28_21h16_11

Jetzt wählen wir unseren privaten Schlüsel aus und geben anschließend dessen Passphrase ein.

Wenn wir uns jetzt ganz normal über PuTTY einloggen, werden wir anschließend nicht mehr nach der Passphrase gefragt.

wie auch immer, bei jedem Rechnerneustart müssen wir die Schritte mit dem tool pageant wiederholen. Wir sparen also nur dann etwas, wenn wir uns mehrmals am Tag in das gleiche System einloggen.

Wir können aber natürlich auch einstellen, dass pageant jedesmal den Key automatisch einbinden soll, sobald wir das Tool starten. Das funktioniert über eine bearbeitete Verbindung im Startup Ordner von Windows. Wir erstellen erstmal eine Verknüpfung für Pageant und bearbeiten Sie dann. In dem Feld „Ausführen in“ geben wir den Pfad an, in dem wir unsere privaten Schlüssel gespeichert haben. Und im Ziel-Feld geben wir nach dem Pfad zur pageant.exe bloß noch die Dateinamen der Schlüssel an, die wir laden wollen. Jetzt müssen wir nicht mehr einen Schlüssel nach dem anderen laden, sondern sie werden alle gleichzeitig geladen und wir müssen nur noch das Passwort für die schlüssel eingeben.

2014-10-29_16h41_59

Wenn ihr jetzt noch einstellt, dass pageant beim Windows-Startup automatisch starten soll, müsst ihr euch nicht mal mehr darum kümmern, dass pageant-tool zu starten. Dazu könntet ihr die Verknüpfung zu pageant beispielswiese in den Autostart-Ordner kopieren.

 Abschließende Konfiguration des SSHd

Jetzt, da wir wissen, dass wir uns mit unserem Schlüssel erfolgreich auf dem Server einloggen können, würde es uns vielleicht in den sinn kommen, Passwort-Authentifizierung gänzlich abzuschalten. Das macht natürlich nur sinn, wenn sich alle User auf dem Server mit Public Key authentication einloggen! Ansonsten sperren wir nämlich alle Passwort-Nutzer aus! Das machen wir über

PasswordAuthentication no
ChallengeResponseAuthentication no
sudo reload ssh

Beachten Sie, dass wir den apramter challengeResposneAuthentication auf no stellen. Wenn unser openSSH-Server nämlich die sogeannnte PAM-Authentifzierung unterstützen würde, könnte sich ein User immer noch mit einem Passwort anmelden, obwohl wir den Paramter Passowrdauthentication auf no gesetzt haben – sofern auf dem openSSH Server PAM Authentifzierung möglich ist.

Schlusswort

ich hoffe ich konnte euch dabei helfen, euren Server in Zukunft sicherer und gleichzeitig mit weniger Aufwand zu betreiben. Denkt ab sofort daran, einen SSHd immer gleich als Erstes sauber zu konfigurieren.

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

3 Antworten

  1. 20. April 2015

    […] welches Betriebssystem Sie zu hause haben, möchten Sie sich von einem Linux Client oder von einem Windows Client aus […]

  2. 20. April 2015

    […] Key Authentication am Server anmelden können. einen Artikel zu public Key auhtentication habe ich hier einmal […]

  3. 16. November 2016

    […] per SSH an einem Server per 2FA anmelden wollen, sind meine Posts über Public Key Authentication (Windows-Client | Linux-Client) für Sie wichtig. Wichtig ist hier wieder, dass Sie den Private Key für die […]

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.