Einsatz von SSH auf dem Server absichern

Am häufigsten wird SSH dafür benutzt, eine textbasierte Shell auf einem entfernten Rechner zu öffnen. Das wirkt zunächst identisch zu dem, was Telnet macht. Der große Unterschied zu Telnet ist, daß die Kommunikation verschlüsselt erfolgt. Passwörter oder sensible Daten können also nicht so leicht von Fremden mitgelesen werden.

Neben der klassischen Shell erlaubt SSH auch einen sicheren Dateitransfer über das Modul sftp und das sichere (weil verschlüsselte) Portforwarding. Letzteres ist eine 'Killerapplikation', welche jedoch schon tiefgreifendere Kenntnisse vorraussetzen sollte.

Das klassische Einsatzgebiet ist die entfernte Wartung von Servern. Da unter UNIX/Linux alles an der Konsole konfiguriert werden kann (ob diese Aussage für alle Windowmanager stimmt, ist mir unbekannt), hat man in SSH eine geeignete Möglichkeit, auch Produktionsmaschinen entfernt warten zu können.

Wie authentifiziere ich mich?

Unter SSH gibt es unterschiedliche Möglichkeiten der Authentifizierung. Die bekanntesten Authentifikationsmöglichkeiten sind Nutzer Passwort und PublicPrivate Key Verfahren.

Die Authentifizierung mittels eines Passwortes erfolgt analog zu dem lokalen Login. Der Benutzername und das Passwort ist üblicherweise zu dem lokalen identisch.

Bei der Authentifikation über den Public/Private Key Mechanismus wird ein öffentlicher Identifikationsschlüssel (Public Key) auf dem Server hinterlegt. Zusammen mit dem privaten Identifikationsschlüssel (Private Key) kann der Nutzer eindeutig identifiziert werden. Der private Identifikationsschlüssel ist äußerst sicherheitsrelevant und darf nicht verloren gehen. Das Schlüsselpaar ist meist durch eine Passphrase gesichert, die sozusagen eine Art Passwort ist, um das Schlüsselpaar gegen unbefugte Verwendung zu schützen. Alles rund um SSH-Keys wird in der Frage Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? erklärt.

Vor der Authentifikation wird eine verschlüsselte Verbindung aufgebaut, so daß keine sensitiven Daten unverschlüsselt übertragen werden.

Neben den beschriebenen Authentifikationsmethoden existieren noch weitere (z.B. per known_hosts).

Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner?

Wofür man einen SSH-Key gebrauchen kann, wird in diesem Kapitel oft genug erklärt. Doch wie erstellt man ihn? Eigentlich ganz einfach:

ssh-keygen -t dsa -b 2048

Bei der Frage nach dem Dateinamen kann man einfach Return drücken.

Die Passphrase ist ein Passwort für den SSH-Key und sollte nicht weggelassen werden, da sonst jeder, der den Key in die Finger bekommt, diesen auch verwenden kann. Wenn passwortlose SSH-Verbindungen möglich sein sollen, empfiehlt sich die Verwendung des ssh-agent. Siehe dazu Wie geht SSH ohne Passwort?

In ~/.ssh/id_dsa liegt der private Schlüssel („Private Key“). Den lässt Du dort einfach liegen und sorgst dafür, dass ihn niemand in die Finger bekommt.

Jetzt solltest Du noch den öffentlichen Schlüssel („Public Key“) ~/.ssh/id_dsa.pub auf den Zielrechner kopieren. Das geht mit dem Befehl

cat ~/.ssh/id_dsa.pub | ssh zieluser@zielrechner \
"mkdir -p .ssh; cat >> .ssh/authorized_keys"

Das war übrigens das letzte Mal, dass Du das Passwort des Zielrechners eingeben musstest ;-) Ab sofort kannst Du Dich mit Deinem SSH-Key einloggen und brauchst nur noch die Passphrase des Keys.

Verschlüsselter Dateitransfer: SCP

Das Tool SCP kann hervorragend verwendet werden, um einzelne Dateien sicher über ein öffentliches Netzwerk (zum Beispiel das Internet) zu transportieren.

Dabei wird wie bei der interaktiven Shell eine Authentifikation erzwungen, bevor mit dem Transfer begonnen wird.

SCP kann aufgrund seiner einfachen Befehlsstruktur leicht in Skripte integriert werden. In Verbindung mit SSH-Keys mit gecachtem Passphrase ist die Nutzung eingängig und schnell eingebaut.

Die im SSH Protokoll definierte Verschlüsselung und optionale Komprimierung belasten die CPU relativ stark. Die resultierende Übertragungsrate ist damit proportional zur vorhandenen Rechenleistung.

Die Rechenleistung eines heutigen PCs (Pentium 3, 1.5GHz +) ist hoch genug, um eine 100Mbit Leitung auszulasten. Bei entsprechend kleiner dimensionierten Leitung ist ein entsprechend kleinerer Rechner ausreichend.

scp user@Server:file /tmp

Obiges Beispiel kopiert die Datei file von dem Server in das lokale Verzeichnis /tmp

Wie kann ich den Login ausschließlich mit SSH-Keys erlauben?

Die Anmeldung mit einem SSH-Key ist mit Abstand die sicherste (Absicherung des SSH-Keys vorausgesetzt ;-) - schon aufgrund der Schlüssellänge im Vergleich zur Länge eines durchschnittlichen Passworts.

Was muss man also tun, um ausschließlich den Login per SSH-Key zu erlauben?

Der erste Schritt ist, seinen Public-Key auf den Server zu kopieren, sonst kommt man hinterher nicht mehr rein. Siehe dazu die Frage Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner?

Anschließend ergänzt bzw. ändert man auf dem Server die Datei /etc/ssh/sshd_config, so dass die folgenden Einträge enthalten sind:

PubkeyAuthentication yes
UsePAM no
PasswordAuthentication no

Alle andere Einträge in dieser Datei bitte nicht ändern.

Nach Änderung der Konfiguration muss der sshd neu gestartet werden:

rcsshd restart

Jetzt geht es in die Testphase:

  • Ist der Login mit SSH-Key problemlos möglich?
  • Geht der Login als ein User ohne hinterlegten Public Key wirklich nicht?

SSH dürfte jetzt nicht mehr nach dem Passwort fragen, höchstens nach der Passphrase des SSH-Keys.

Vorsichtsmaßnahmen bei entfernten Servern

Falls man diese Änderung auf einem Server macht, auf den man keinen physikalischen Zugriff hat, sollte man sich vor Beginn der Umkonfiguration einen „Backup-sshd“ starten. Das geht mit

sshd -p 2222

der Login erfolgt dann mit

ssh -p 2222 user@server

Dieser sshd wird durch rcsshd restart nicht beeinflusst und akzeptiert weiterhin Logins mit Passwort.

Nach Ende der Testphase nicht vergessen, den sshd auf Port 2222 zu killen und anschließend nochmal mit

ssh -p 2222 user@server

testen, ob er wirklich beendet wurde.