Leetperium.de

Die Authentifizierung an einem SSH-Server mithilfe eines Keyfiles bringt einen deutlichen Sicherheitsgewinn im Vergleich zur “herkömmlichen” Authentifizierung mit einem einfachen Passwort. Im Gegensatz zu Passwörtern ist es bei SSH-Keys wirklich unmöglich, die passenden Keys über eine Brute-Force-Attacke in einer halbwegs annehmbaren Zeit zu erraten.

Auch wenn ich das Key-Auth-Verfahren schon länger selbst einsetzte und es durchaus für sicherheitsrelevant halte, habe ich komischerweise nie einen Artikel darüber verfasst. Here we go!

Als Basis nehmen wir wie üblich einen Server mit einer “blanken” Debian Squeeze-Installation. Die Vorgehensweise dürfte bei anderen Distributionen ähnlich sein, jedoch bitte vor jedem Schritt prüfen, ob auch alle Konfigurationsdateien am “richtigen” Platz sind. Der verwendete Test-Server wurde von TomAte92 gesponsert, als Client-Rechner muss mein Raspberry Pi herhalten.

Hinweis: Dieses Tutorial geht davon aus, dass auf dem Client-Rechner ebenfalls ein Linux installiert ist. Ein Howto zur Schlüsselgenerierung und zum Verbindungsaufbau unter Windows mit PuTTY folgt ggf. später!

Kurz ein paar Grundlagen zum Public Key-Verfahren: Wir werden zwei Schlüsseldateien erstellen, einmal den öffentlichen und einmal den privaten Schlüssel. Der öffentliche Schlüssel ist – wie der Name schon impliziert – kein großes Geheimnis. Wesentlich brisanter ist der private Schlüssel. Dieser in der Regel passwortgeschützte Schlüssel ist das Gegenstück zum öffentlichen Schlüssel und erlaubt dem Client eine Verbindung zum Server aufzubauen. Wenn der private Schlüssel dann nicht mit einem Passwort gesichert ist und von Dritten kopiert wird, erhalten diese Root-Zugang zum Server.

Kleine Analogie: Der öffentliche Schlüssel ist quasi das Schloss einer Tür und der private Schlüssel der zum Türschloss passende Schlüssel. Während sich jeder das Schloss ansehen darf, sollte auf den dazu passenden Schlüssel natürlich niemand Zugriff erhalten.

1. Schlüsselpaar auf dem Client-Rechner erzeugen

Zum Generieren des Schlüsselpaares auf dem Client-Rechner kommt das Tool ssh-keygen zum Einsatz. Dieses Tool ist im Debian-Repository in dem Paket openssh-client enthalten.

user@client:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
65:5f:b9:52:9e:03:81:2e:59:df:0d:b7:7f:9e:59:9d user@client
The key's randomart image is:
+--[ RSA 2048]----+
|           ..    |
|          o  ....|
|         +o...++.|
|        oo...=.+.|
|        S.  o = +|
|             . E=|
|               .=|
|               o.|
|                 |
+-----------------+

ssh-keygen erstellt daraufhin ein Schlüsselpaar, bestehend aus dem public und dem private Key. Der pubic Key ist an der Dateiendung .pub erkennbar. Soll auf dem Rechner nur ein Schlüsselpaar angelegt werden, kann der vorgegebene Dateiname beibehalten werden. Bei mehreren Schlüsselpaaren müssen natürlich andere Dateinamen verwendet werden, sonst werden die alten Schlüssel einfach überschrieben.

Auch wenn ssh-keygen den Nutzer dazu verleitet, doch kein Passwort einzugeben, sollte man das auf jeden Fall unterlassen. Auch wenn die Anmeldung damit “bequemer” wird, stellt das ganze doch ein erhebliches Sicherheitsrisiko dar. Immerhin können Angreifer, die sich Zugriff auf den privaten Schlüssel verschaffen, sich dann ebenso bequem und ohne Passworteingabe auf allen Servern anmelden, die dieses Schlüsselpaar verwenden. Also bitte unbedingt ein ausreichend starkes Passwort verwenden!

Sowohl der public als auch der private Key sollten nun redundant an mehreren sicheren (!!!) Orten abgespeichert werden. Ohne Keys steht ihr nämlich vor verschlossenen “Server-Türen”.

2. Schlüssel auf den Server übertragen

Im nächsten Schritt muss der public Key des eben erstellten Schlüsselpaares auf alle Server kopiert werden, auf denen eine Anmeldung mit dem Schlüsselpaar ermöglicht werden soll. Dazu verwenden wir den Befehl ssh-copy-id. Dieser Vorgang muss auch für alle User-Accounts auf dem Server wiederholt werden, für die ein direkter SSH-Login erlaubt sein soll. Dies ist besonders wichtig, wenn sich der root-Account aus Sicherheitsgründen nicht direkt am SSH-Server anmelden darf. (Stichwort “PermitRootLogin no”).

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@192.168.xx.xx
user@192.168.xx.xx's password:
Now try logging into the machine, with "ssh 'user@192.168.xx.xx'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Username und IP-Adresse müssen natürlich den reealen Bedingungen angepasst werden. Sollte der SSH-Server des Ziel-Servers nicht auf dem Standard-Port 22 “lauschen”, muss der Aufruf folgendermaßen aussehen:

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub "user@192.168.xx.xx -p Portnummer"

Die Anführungszeichen vor user und hinter der Portnummer sind erforderlich, sonst werden die Parameter nicht richtig an den SSH-Client übergeben.

Wie uns ssh-copy-id schon vorgeschlagen hat, melden wir uns nun am Ziel-Server an. Anstelle des User-Passwortes werden wir nun nach dem Passwort für den private Key gefragt. Wenn wir dieses richtig angeben, sind wir auch schon “drin”.

3. Passwort-Authentifizierung deaktivieren

Anschließend sollten wir noch für alle Accounts, die das Schlüsselpaar zur Authentifizierung verwenden, den Login über das User-Passwort verbieten. Denn schließlich haben wir die Authentifizierung über das Schlüsselpaar vor allem aus Sicherheitsgründen eingerichtet, unser “Passwort” soll ja unknackbar werden.

Die Passwort-Authentifizierung kann global in der Konfiguration des SSH-Servers oder nur für einzelne Benutzeraccounts gesperrt werden. Um die Passwort-Authentifizierung global zu deaktivieren, fügen wir folgende Optionen in die Datei /etc/ssh/sshd_config ein:

PasswordAuthentication no
UsePAM no

Anschließend muss der SSH-Server neu gestartet werden, damit die geänderte Konfiguration verwendet wird. Für einzelne Benutzer-Accounts kann die Passwort-Authentifizierung auch einfach deaktiviert werden:

passwd -l username

4. Für den Notfall: Keys zurückziehen

Sollte ein private Key durch Angreifer kopiert werden, muss auch bei einem passwortgeschützten Schlüssel dieser sofort im System für ungültig erklärt werden. Dazu muss zuerst die Passwort-Authentifizierung wieder aktiviert werden, sonst hat man nach dem Zurückziehen des Schlüssels keine Möglichkeit mehr, sich an dem System anzumelden. Dazu wird in der Datei /etc/ssh/sshd_config der Parameter PasswortAuthetication auf yes gesetzt und der SSH-Server neu gestartet.

Bei Benutzeraccounts, die über passwd -l gesperrt wurden, muss die Passwort-Authentifizierung mit dem Befehl passwd -u username wieder aktiviert werden.

Anschließend muss der betroffene Schlüssel aus der Datei /home/username/.ssh/authorized_keys entfernt werden. Dazu kann entweder die betreffende Zeile gelöscht werden oder durch ein vorangestelltes “#” auskommentiert werden. Zu guter Letzt muss der SSH-Server neu gestartet werden. Danach sind aus Sicherheitsgründen die Passwörter aller User-Accounts zu ändern.