Das Passwort kann bei einem Brute Force-Angriff geknackt werden, während SSH-Schlüssel kaum durch eine Brute Force-Attacke allein in falsche Hände geraten können.
SSH-Schlüssel sind ein Paar von zwei langen Strings (Zeichenketten): Ein öffentlicher Schlüssel und ein privater Schlüssel.
Der private Schlüssel (Private Key) bleibt auf dem Client-Rechner, der öffentliche Schlüssel (Public Key) wird auf den Server übertragen und mit dem privaten Schlüssel gekoppelt. Wenn die beiden Schlüssel beim Login zusammenpassen, braucht der Server kein Passwort. Allerdings erhöht eine Passphrase (Passwort-Phrase) die Sicherheit des Logins via Public Key und Private Key um einen weiteren Faktor.
Das RSA-Schlüsselpaar
Das Schlüsselpaar wird auf dem Client-Rechner erzeugt – in den meisten Fällen ist das der lokale Rechner / die Workstation des Webmasters oder Administrators.
ssh-keygen -t rsa
Das Terminal bestätigt den Aufruf mit
Generating public/private rsa key pair
Schlüssel und Passwort-Phrase speichern
Der ssh-keygen-Befehl stellt Fragen:
Enter file in which to save the key (/Users/myusername/.ssh/id_rsa):
Enter speichert die Datei im vorgeschlagenen Verzeichnis. Bei einem neuen Schlüsselpaar ist der Default-Name immer id_rsa und id_rsa.pub. Aber Vorsicht!
ssh-Schlüssel für mehrere Domains / Server
Ein zweites Schlüsselpaar für einen weiteren Server würde die Schlüssel überschreiben und den alten Schlüssel endgültig unbrauchbar machen!
Darum kann man die Dateinamen der Schlüssel während der Erzeugung ändern oder ergänzen. Wenn weitere Schlüssel erzeugt werden, ändert man die Dateinamen, z.B.
/Users/myusername/.ssh/id_rsa_server1
Die Dateinamen der Schlüssel lauten dann id_rsa_server1 und id_rsa_server1.pub. Und besser statt server1 einen sprechenden Namen einsetze.
Passphrase für mehr Sicherheit
Enter passphrase (empty for no passphrase):
Die Passphrase chiffriert den Schlüssel zusätzlich und muss beim Login wie ein Passwort eingegeben werden, um den Private Key zu entschlüsseln. Es geht auch ohne Passphrase, aber das lokale Passwort ist ein weiterer Sicherheitsmechanismus: Die Sicherheit des Private Keys beruht darauf, dass er für niemanden sichtbar ist. Sollte der lokale Rechner kompromittiert werden (z.B. wenn der Rechner gehackt oder gestohlen wird), kann sich der Hacker ohne die Passphrase immer noch nicht einloggen.
Warum Passphrase und nicht Passwort? Eine Passphrase kann Buchstaben und Ziffern, Sonderzeichen und Leerzeichen enthalten. Viele kennen Passphrase sicher aus der WordPress config.php.
Der Private Key wird nicht im Netz gespeichert, sondern nur auf der eigenen Workstation. Die Passphrase entschlüsselt den Private Key nur auf dem lokalen Rechner und kann nicht durch eine Brute Force-Attacke ausgehebelt werden.
Die Erzeugung der Schlüssel
Nach der Abfrage der Passphrase erzeugt der Client das Schlüsselpaar.
Generating public/private rsa key pair. Enter file in which to save the key (/Users/myusername/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/myusername/.ssh/id_rsa. Your public key has been saved in /Users/myusername/.ssh/id_rsa.pub. The key fingerprint is: SHA256:jWwmjfEqKtPykNNaMPhFzcBvBMt1janp4ygtHiI2oJo myusername@MyClient.local The key's randomart image is: +---[RSA 2048]----+ | .o.. .+ | | ..*..o . | | +o+o | |. . =* o | |= .oo S . | |o* . o= | |B+=..o.. | |BB=oo.. | |E*+o | +----[SHA256]-----+
- Der Private Key (private Schlüssel) liegt jetzt unter /Users/myusername/.ssh/id_rsa
- Der Public Key (öffentlicher Schlüssel) unter /Users/myusername/.ssh/id_rsa.pub
-rw------- 1 myusername staff 1766 1 Mär 07:21 id_rsa -rw-r--r-- 1 myusername staff 416 1 Mär 07:21 id_rsa.pub -rw-r--r--@ 1 myusername staff 1875 29 Dez 15:42 known_hosts
cat zeigt den Inhalt des Public Key:
ssh-rsa AAAAB3NzaC1yc2EAAAAD… myusername@MyClient.local
Public Key auf den Server kopieren
Jetzt muss der Public Key auf den Server in authorized_keys transferiert werden. Wenn es noch keine Datei authorized_keys im Verzeichnis .ssh auf dem remote Server gibt, wird die Datei neu angelegt.
touch authorized_keys ls -al -rw-r--r-- 1 root root 0 1. Mär 08:41 authorized_keys -rw-r--r-- 1 root root 1003 22. Sep 15:09 known_hosts
Beim ersten angelegten Schlüssel in authorized_keys kann der Public Key mit scp (Secure Copy) (Pfad zum .ssh-Verzeichnis anpassen!) übertragen werden.
scp /Users/myusername/.ssh/id_rsa.pub user@123.45.67.89:/root/.ssh/authorized_keys
Passwort eingeben und der Upload beginnt:
id_rsa.pub. 100% 416 4.1KB/s 00:00
Mit scp also nur für die erste Schlüsseldatei! Wenn ein zweiter oder dritter Schlüssel angelegt wird, würde die authorized_keys-Datei überschrieben. Stattdessen den neuen Key mit vi oder nano mit -w-Flag als neue Zeile in die authorized_keys einfügen.
Die Datei authorized_keys hat keine Schreibrechte. Evtl. die Schreibrechte setzen:
chmod u+w authorized_keys
Den Inhalt von id_rsa.pub mit vi oder nano in die Datei authorized_keys kopieren (), nano mit dem -w Flag ( -w. –nowrap Don’t hard-wrap long lines), damit keine Zeilenumbrüche eingefügt werden.
Anschließend die Schreibrechte wieder zurücknehmen:
chmod u-w authorized_keys
Login testen nicht vergessen! Um sich auf einem remote Host einzuloggen, neues Terminalfenster öffnen und ssh eingeben:
ssh myusername@remoteServer
Wenn nicht der vorgegebene Name des Schlüssels benutzt wird, müssen Pfad und Name des Schlüssels angegeben werden:
ssh -i /Users/myusername/.ssh/id_rsa_mykey remoteuser@123.456.789.012
!!! Mehr als ein Schlüsselpaar?
Wenn Public und Private Key für mehr als einen Server angelegt wurden, muss eine Config-Datei auf dem eigenen Rechner / der Workstation des Webmasters dem Login zeigen wo’s lang geht.
Wenn es noch keine Config-Datei gibt, wird sie im .ssh-Verzeichnis des Users mit touch angelegt.
touch config
Host server1 Hostname 123.45.67.89 user webmaster IdentityFile ~/.ssh/id_rsa_server1 Host server2 Hostname 98.76.543.210 user webmaster IdentityFile ~/.ssh/id_rsa_server2
und anmelden mit
ssh server1 oder ssh server2
Root Login nur noch mit SSH-Keys
Wenn der öffentliche Schlüssel auf den Server kopiert wurde und das Login mit SSH-Schlüssel erfolgreich getestet wurde, kann das Login in der SSH-Konfiguration auf SSH-Keys beschränkt werden.
sudo nano /etc/ssh/sshd_config
Zeile mit PasswordAuthentication suchen
PasswordAuthentication no
ssh neu starten, um die Änderungen zu übernehmen (Ubuntu):
reload ssh
oder (CENTOS, REDHEAD, FEDORA)
/etc/init.d/sshd restart oder
service sshd restart
Backup von Private und Public Key
Beim einfachen SSH-Login muss das Passwort den Angriffen standhalten. Beim Login mit dem Private Key ist der lokale Rechner allein verantwortlich. Ein weiterer Rechner mit SSH-Schlüssel-Zugang oder zumindest ein externes Backup müssen dafür sorgen, dass bei einem Ausfall des Rechners der Zugang zum Server möglich ist.
Passphrase für Private Key ändern
Das -p Flag fordert eine Änderung der Passphrase für den Private Key an. ssh-keygen will die alte Passphrase und zwei mal die neue Passphrase.
ssh-keygen -f id_rsa -p
