Im Linux-Bereich ist eine Systemadministration ohne das SECURE-SHELL-POTOKOLL nicht mehr denkbar. So sorgt SSH für das nötige Maß an Sicherheit bei der Datenübertragung im Internet. SSH (Version 2) greift dabei auf moderne Verschlüsselungsstandards, wie AES-192 (Advanced Encryption Standard, 192 Bit) zurück. Darüber hinaus erreicht man mittels SSH eine überaus stabile Verbindung. Dies ist im Wesentlichen darauf zurückzuführen, dass das Protokoll die Benutzdaten mittels Prüfsummen in den jeweiligen Kopfzeilen gegen eventuelle Verluste von Daten absichert.
SSH-Client an Bord
OpenSSH ist der bekannteste Client für Secure-Shell-Anwendungen. Bei aktuellen Linux-Distributionen kommen 4.x-Versionen von OpenSSH zum Einsatz. Da OpenSSH im Umfeld der auf Sicherheit getrimmten BSD-Distribution OpenBSD entwickelt wird, unterliegt OpenSSH den harten Sicherheitsanforderungen dieses Projekts. Um sich über den aktuellen Stand der Sicherheit von OpenSSH zu informieren, empfehlen sie die Webseiten www.se cunia.com oder www.security-focus.com. Für Windows gibt es ebenfalls einige SSH-Implementierungen – der Favorit unter den freien Lösungen ist PuTTY (www.chiark.greenend.org.uk/~sgtatham/putty). Interessant ist auch WinSCP (www.winscp.net), eine grafische Erweiterung von PuTTY um die Dienste Secure Copy (SCP) und Secure File Transfer Protocol (SFTP).
Einmalig: Serverschlüssel
Jeder SSH-Server besitzt einen individuellen Serverschlüssel, der vor dem Erststart des SSHD erstellt wird. Die drei notwendigen Schlüssel finden Sie im Verzeichnis /etc/ssh:
ssh_host_dsa_key[.pub]
ssh_host_key[.pub]
ssh_host_rsa_key[.pub]
Wenn Sie zum ersten Mal eine Verbindung mit einem SSH-Client zum SSH-Server aufbauen, erscheint eine Warnmeldung, die Sie mit y[es] bestätigen, um den Localhost (RSA) in die Liste der bekannten Hosts einzutragen. Der Public Key (RSA) wird in der Datei ~/.ssh/known_hosts abgelegt. Ändert sich der Server-Schlüssel, so werden Sie mit einer Meldung alarmiert. Die Änderung könnte auf einer Man-in-the-Middle-Attacke basieren, bei der ein Hacker versucht, sich zwischen SSH-Client und -Server einzuklinken, um Kennwörter auszuspähen. Abhilfe gegen diese Spionage schafft der Einsatz von öffentlichen Schlüsseln zur Authentifizierung.
Öffentliche Schlüssel nutzen
Anstelle von Kennwörtern zur Authentifizierung von Benutzern sollten Sie ausschließlich öffentliche Schlüssel (Public Keys) verwenden. Diverse Hacker-Tools wie Hydra erlauben automatisierte Brute-Force-Angriffe gegen SSH-Server. Folgend Einträge in der Datei /etc/log/secure deuten auf einen Angriff hin:
Oct 9 19:40:32 iolo sshd2[2175]:
connection from
“218.38.136.77”
Oct 9 19:40:32 iolo sshd2[11581]:
WARNING: DNS lookup failed for
“218. 38.136.77”
Oct 9 19:40:33 iolo sshd2[11034]:
LoginGraceTime exceeded
Oct 9 19:40:34 iolo sshd2[11581]:
password authentication failed
Es wird höchste Zeit, die Authentifizierung zu ändern. Zunächst erzeugen Sie auf dem SSH-Client Ihren individuellen Schlüssel mit dem Befehl „ssh-keygen –t rsa“. Bestätigen Sie die Eingabeaufforderungen des folgenden Dialogs, und geben Sie auf Anfrage eine Passphrase für Ihren Schlüssel ein. OpenSSH bestätigt den Vorgang: Im nächsten Schritt ändern Sie die Authentifizierungsverfahren des SSH-Servers, so dass zukünftig keine Kennwörter zum Login akzeptiert werden. Bearbeiten Sie hierzu die Datei /etc/ssh/sshd_con’ g als Superuser Root und ändern Sie „yes“ zu „no“ in der Zeile „PasswordAuthentication“. Anschließend starten Sie den SSHD mit dem Befehl „service sshd restart“ neu. Versuchen Sie einen Login per SSH-Client, etwa mit dem Befehl „ssh root@localhost“– er wird scheitern. Kopieren Sie danach Ihren öffentlichen Schlüssel mit dem Befehl:
cat /home/tw/.ssh/id_rsa.pub >>
/root/.ssh/authorized_keys
Danach versuchen Sie das Login erneut.„ssh root@localhost“ meldet dieses Mal:
Enter Passphrase for key ‘/home/tw/.ssh/id_rsa’:
Erst nachdem Sie das Kennwort für Ihren persönlichen Schlüssel eingegeben haben, klappt die Anmeldung.
Schlüsseldienst: SSH-Agent
Anstatt das Kennwort Ihres Schlüssels beim Aufbau jeder SSH-Verbindung immer wieder einzugeben, können Sie den so genannten SSH-Agenten starten, der sich das Kennwort im Hintergrund merkt:
eval ‘ssh-agent’
ssh-add
Enter passphrase for /home/tw/.ssh/id_rsa:
Identify added: /home/tw/.ssh/id_rsa
(/home/tw/.ssh/id_rsa)
Verbindungen, die Sie zu einem SSH-Server aufbauen, dem Ihre öffentlichen Schlüssel bekannt sind, funktionieren jetzt ohne die Eingabe der Passphrase Ihres Schlüssels.
Tipp: Setzen Sie SSH-Agenten ein, wenn Sie Automatismen wie Shell Scripts benutzen, die per SSH oder SCP Informationen austauschen sollen.
Fazit und Ausblick
Deaktivieren Sie stets die normale Kennwort-Authentifizierung von OpenSSH, ansonsten werden Ihre Server immer das Ziel von Brute-Force-Angriffen sein. Wenn sich die Kennwort-Authentifizierung nicht abschalten lässt, sollten Sie Werkzeuge wie fail2ban einsetzen (http://sourceforge.net/projects/fail2ban). Mit der Hilfe solcher Tools können Sie ab einer bestimmten Anzahl von unerlaubten Login-Versuchen die entsprechende IP-Adresse für einen gewissen Zeitraum sperren. Die Einführung individueller RPM-Dateien und eigener Repository-Server erleichtert in mittleren und großen Unternehmen den Umgang mit den notwendigen Schlüsseln spürbar.
Dieser Artikel basiert auf einem Beitrag der COMPUTERWOCHE-Schwesterpublikation PC-Welt.