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 >> ~/.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:
- 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.
