Erstellen und Verwenden von SSH Keys

0
455

Wer häufig mit verschiedenen Webdiensten oder Webserver arbeitet, sollte sich überlegen ob er das noch mit normaler Passwort Authentifizierung macht – oder mit einem viel sicheren Verfahren wie beispielsweise SSH Key Authentifizierung.

Weshalb SSH Keys?

Ich habe mich für die SSH Key Authentifizierung entschieden, weil viele Dienste, die ich nutze, ohnehin bereits die SSH Key Authentifizierung einsetzen. In meinen Fall sind das Dienste wie ein Strato Backupspace, GIT-Versionierung und last but not least: Der Login auf meinen Webservern.

Zu diesem Tutorial

Die von mir eingesetzte Methode wurde auf MacOS, Linux und dem Windows Subsystem Ubuntu getestet. Ich habe hierfür kein PuttyGen verwendet, da die hier vorgestellte Methode für mich die einfachste bzw. schnellste ist.

Als Beispiel verwende ich hier das SSH Key Auth Verfahren zum Login auf einem Root / V-Server.

Step 1: Generieren des Schlüsselpaars

Das Schlüsselpaar selbst ist schnell erstellt:


ssh-keygen -o -b 4096 -t rsa

und erhalten folgenden Output:

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/d0n/.ssh/id_rsa): id_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
SHA256:vA0LrC6kJ8fHVfXV1S9nqCFT16QjUf+8L5N8eavG3AY d0n@LMZW-2VV0HNHV2Q
The key's randomart image is:
+---[RSA 4096]----+
|            ...+=|
|          . ..oo+|
|         . o.oo.o|
|     . .. o o.oo=|
|      o.S  o o +o|
|  .  ... =  .E  .|
| + ...  o . o.oo.|
|o =.o        +=++|
| + o.       ..o=+|
+----[SHA256]-----+

  • Zeile 2: Hier habt ihr die Möglichkeit, andere Pfade oder Dateinamen für euer Schlüsselpaar anzugeben
  • Zeile 3 + 4: Ich empfehle stark, hier eine Passphrase anzugeben. Wieso? Ich gehe später noch mal darauf ein ,-)

Zur Erklärung! Ihr erhaltet nun 2 neue Dateien:
– id_rsa <—— Dies ist der private Schlüssel der bspw. bei euch auf dem Rechner bleibt
– id_rsa.pub <- Dies ist der öffentliche Schlüssel und wird dort verwendet, WO ihr euch per SSH Auth einloggen möchtet

Step 2: Kopieren des Schlüssels auf euren Webserver

Es gibt 2 Möglichkeiten, den Schlüssel nun auf den Webserver zu installieren.

Möglichkeit 1 (die einfachste):


ssh-copy-id -i SCHLÜSSELNAME BENUTZER@SERVER

Möglichkeit 2 (die aufwendigere, die ihr aber auch direkt auf dem Zielserver verwenden könnt):


cat ~/.ssh/id_rsa.pub | ssh BENUTZER@SERVER "cat &gt;&gt; ~/.ssh/authorized_keys

Warum direkt auf dem Zielserver? Ihr könnt den PUB Key auch einfach auf den Server kopieren und dann mittels cat registrieren.

Bitte testet die Einrichtung direkt. Ob es funktioniert hat merkt ihr, in dem ihr nicht mehr nach einem User Passwort sondern nach einer Key Passphrase gefragt werdet.

Step 3: Testen der Einrichtung

Ihr könnt euch nun wie folgt auf dem Server einloggen:


ssh -i KEYNAME BENUTZER@SERVER

Empfehlung 1: Verwendung von einer eigenen Passphrase

In manchen Fällen kann es notwendig sein, keine Keyphrase zu verwenden. Ich verwende immer eine. Kommt mein privater Schlüssel in fremde Hände, hat dieser vollen Zugriff auf meine Zugänge die ich mit diesem Schlüsselpaar abgesichert habe.

Empfehlung 2: Verhindern, das normale Logins noch möglich sind

Jetzt haben wir einen sicheren Zugang mittels SSH Keys eingerichtet. Wieso also noch die Zugänge auf einem Webserver für die normale Passwort-Authentifizierung offen lassen?

Loggt euch auf dem Webserver als User ein (den ihr per SSH Key Auth eingerichtet UND getestet habt) und editiert die SSH Konfiguration:


sudo vi /etc/ssh/sshd_config

Sucht dort nach dem Eintrag PermitRootLogin und editiert diesen:


PasswordAuthentication no

Nach einem Neustart des SSH Dienstes wird die neue Einstellung aktiv:


reload ssh

VORSICHT: Solltet ihr eure SSH Key Authentifizierung nicht getestet haben UND dies fehlerhaft sein, sperrt ihr euch nun von eurem Webserver aus!

Empfehlung 3: Auf dem Client die SSH Konfiguration anpassen

Bisher verwenden wir für den Login: ssh -i KEYNAME BENUTZER@HOSTNAME

Dies geht einfacher, indem ihr auf eurem Client eine Config erstellt:


cd .ssh

vi config

und tragt dort folgendes ein:


Host HOSTNAME // bspw. MyServer

HostName FULLHOSTNAME.DE // bspw. MyServer.de

User BENUTZER // bspw. d0n

IdentityFile ~/.ssh/id_rsa // Speicherort eures privaten Schlüssels

Ab sofort könnt ihr euch einloggen wie folgt:


ssh HOSTNAME

Empfehlung 4: Deaktivierung des ROOT Logins auf Webservern

Generell solltet ihr euch immer mit einem Benutzer einloggen. Falls ihr unbedingt Root Rechte auf einem Webserver (Root / V-Server etc.) benötigt, könnt ihr diese mittels sudo -i jederzeit erlangen. Vorteil: Der Benutzername ist nicht jedem bekannt, aber jeder weiß, das es ein Root-Konto auf dem Webserver gibt.

Achtung! Wenn keine Benutzer auf dem Webserver angelegt sind, sperrt ihr euch aus!

Editiert als Root-Benutzer die SSH Konfiguration:


vi etc/ssh/sshd_config

und verhindern sie den Root-Login:


PermitRootLogin no

Nun ist es noch notwendig, dass der SSH Server neu gestartet wird:


/etc/init.d/ssh restart

// oder

service ssh restart

// oder

reload ssh

Empfehlung für Mac-User und SmartGit:

Ich hatte die Herausforderung, dass SmartGit meinen privaten Schlüssel einfach nicht akzeptieren wollte. Also musste eine andere Möglichkeit her:

  1. Importieren des Keys in den Keychain. Somit muss die Phassphrase nicht immer eingegeben werden.

ssh-add -K ~/.ssh/id_rsa

2. SmartGit Einstellungen ändern

Ich habe über Settings > Authentification (1) die Einstellung vorgenommen, den System SSH Client (2) zu nutzen. Im Anschluss war die Nutzung von SmartGit mit meinen Repositories möglich.

Hat euch dieser Artikel gefallen oder habt ihr Anmerkungen? Ihr vermisst etwas oder hattet Probleme bei der Einrichtung? Lasst es uns doch gerne über die Kommentare wissen.