Einrichten von public keys mit ssh
Inhaltsverzeichnis
ssh-Verbindungen über asymmetrische Schlüssel abzusichern
Methoden die den Zugriff von OpenSSH zu steuern
OpenSSH kann auf verschiedene Weise vor unbefugtem Zugriffen abgesichert werden. Die Passwortabfrage, die per Voreinstellung aktiv ist, ist nur eine Möglichkeit, und nicht einmal die Sicherste. (Es sind auch einige Methoden noch implementiert die traditionell von früheren Tools her stammen, diese sollte man aber möglichst nicht mehr verwenden.)
Da bei jedem Verbindungsaufbau die Hostschlüssel überprüft werden, gibt es die Möglichkeit bestimmte Rechner als vertrauenswürdig zu erklären, und Zugriffe von anderen Rechnern abzuweisen. Eine sehr sichere Methode, ist die Identifikation über asymmetrische Schlüssel, die publickey-Authentifizierung. Natürlich können alle Verfahren miteinander kombiniert werden, oder gleichberechtigt nebeneinander Zugriffe erlauben.
Mit welchen Methoden man sich am anderem Rechner letztlich ausweisen muss, um Zugriff zu erhalten, bestimmen die Einstellungen des ssh-Daemons am Server, die natürlich dort nur von root gemacht werden können. Ihm obliegt es, bestimmte Authentifizierungsverfahren zu erlauben oder zu sperren.
Publickey-Authentifizierung
Hierbei wird ein Schlüsselpaar erzeugt. Wird mit einem dieser Schlüssel verschlüsselt, dann kann nur der andere Schlüssel das wieder entschlüsseln. Einer der beiden Schlüssel bleibt geheim, den anderen Schlüssel können alle haben, mit denen man kommunizieren will, er ist öffentlich. Wenn jetzt jemand mit dem öffentlichen Schlüssel die Nachricht entschlüsseln kann, dann muss der Versender der Nachricht der Inhaber des geheimen Schlüssels sein.
In der Praxis sieht das so aus, der User auf dem Client, also der Rechner der sich an den Servern anmelden will, erzeugt das Schlüsselpaar, der private Schlüssel bleibt lesegeschützt in seinem Homeverzeichnis auf diesem Rechner, den öffentlichen Schlüssel hinterlegt er auf allen Servern dort jeweils in seinem Homeverzeichnis. Bei entsprechender Konfiguration der Server ist jetzt ein passwortloses und sehr sicheres Anmeldeverfahren an alle Server von diesem Client und diesem User möglich. Dieser muss nur dafür sorgen, dass sein privater Schlüssel geheim bleibt.
Wir werden jetzt hier für den User hans ein solches Schlüsselpaar erzeugen, und installieren.
- clientrechner ist dabei der Name der Workstation des Users und server der Name des Rechners, an dem er sich mittels ssh anmelden möchte.
Schlüsselpaar erzeugen
hans ist auf dem clientrechner in seinem homeverzeichnis
- Erzeugung eines rsa 2048-Bit Schlüssel für die Authentifizierung:
hans@clientrechner:~> ssh-keygen -b 2048 -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/hans/.ssh/id_rsa):
Hier wird durch Enter die Datei bestätigt. Sollte es diese Datei jedoch schon geben, muss hier überlegt werden, ob das alte Schlüsselpaar noch benötigt wird und ein andere Name für den Schlüssel verwendet werden sollte.
Created directory '/home/hans/.ssh'. Enter passphrase (empty for no passphrase):
Hier kann man eine Passphrase eingeben, muss es aber nicht, wir geben nur Enter für eine leere Passphrase ein und bestätigen anschließend nochmal:
Enter same passphrase again: Your identification has been saved in /home/hans/.ssh/id_rsa. Your public key has been saved in /home/hans/.ssh/id_rsa.pub. The key fingerprint is: g1:c2:a1:f6:1b:a3:d9:3e:39:a6:12:07:4e:1e:a2:1e hans@clientrechner hans@clientrechner:~>
Achtung: Die hier beschriebene Methode ohne Eingabe einer Passphrase ist unter Sicherheitsaspekten nicht optimal. Es besteht die Möglichkeit, dass ein Angreifer durch Diebstahl des Schlüssels Zugriff auf hierdurch abgesicherte Systeme bekommt. Einem solchen Missbrauch kann man vorbeugen, indem eine starke Passphrase verwendet wird, ohne deren Kenntnis der Schlüssel unbrauchbar ist, denn sie wird für jeden Zugriff auf den Schlüssel angefordert.
Einen Kompromiss zwischen den konkurrierenden Anforderungen in puncto Sicherheit einerseits und Useability andererseits bietet das Programm ssh-agent. Um abgesicherte Schlüssel zu verwenden und trotzdem nicht immer wieder zur Eingabe der Passphrase gezwungen zu sein, werden die Credentials hier einmalig abgefragt und für eine bestimmte Zeit im Arbeitsspeicher gehalten, so dass sämtliche folgenden Zugriffe als password-los erscheinen.
Im Verzeichnis /home/hans/.ssh liegen jetzt zwei Dateien:
hans@clientrechner:~>ls .ssh/ id_rsa id_rsa.pub hans@clientrechner:~>
id_rsa enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden. Dieser Schlüssel indentifiziert uns eindeutig als hans@clientrechner
id_rsa.pub dagegen soll auf den Zielrechner kopiert werden.
Public Schlüssel auf dem Server installieren
- Der Öffentliche Schlüssel muss auf den Zielrechner kopiert werden, dazu kann man das script ssh-copy-id benutzen oder man erledigt dieses zu Fuß, dazu am besten erstmal in das Home-Verzeichnis von hans
hans@clientrechner:~> cd .ssh hans@clientrechner:~/.ssh> sftp server Connecting to server... Password: sftp> put id_rsa.pub Uploading id_rsa.pub to /home/hans/.ssh/id_rsa.pub id_rsa.pub 100% 391 0.4KB/s 00:00 sftp> bye
- jetzt wechselt hans mit ssh auf den server dort muss er sich immer noch mit Passwort anmelden.
- Falls das Verzeichnis .ssh noch nicht existiert müssen wir es jetzt dort im Homverzeichnis von hans anlegen:
hans@server:~> mkdird .ssh hans@server:~> chmod 700 .ssh
- Anschließend wird der Schlüssel in die Datei authorized_keys portiert, diese Datei kann mehrere Schlüssel aufnehmen, also von jedem Client von dem aus sich der User anmelden will, kann er hier einen öffentlichen Schlüssel ablegen, daher ist das doppelte Umleitungszeichen wichtig, um eine evtl. existierende Datei nicht versehentlich zu überschreiben, sondern neue Schlüssel anzuhängen.
hans@server:~> cat id_rsa.pub >> .ssh/authorized_keys
- wenn wir die Datei .ssh/authorized_keys jetzt neu angelegt haben sollten, dann müssen wir die Zugriffsrechte neu setzen und den öffentlichen Schlüssel löschen wir mal sicherheitshalber auch gleich.
hans@server:~> chmod 600 .ssh/authorized_keys hans@server:~> rm id_rsa.pub
den ssh-Deamon konfigurieren
Nun müssen wir noch den ssh-Server-Daemon konfigurieren. Das kann aber jetzt nur root auf diesem Server machen.
- Folgende Zeilen sollten in der Datei /etc/ssh/sshd_config stehen:
PermitRootLogin yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Achtung diese Zeilen sind schon vorhanden, nur waren sie evtl. bis jetzt mit # am Anfang auskommentiert
- Falls wir diese Zeilen editiert haben, müssen wir den sshd neu starten:
server:~#rcsshd restart
- Dann geht es ans Testen. Wir wechseln wieder zu unserem Clientrechner und probieren, ob wir ohne Passwort auf den Server zugreifen können:
hans@clientrechner:~> ssh server Last login: ....................... Have a lot of fun... hans@server:~>
- Das war es eigentlich schon. Im Moment funktionieren noch beide Verfahren. Das ist während der Umstiegphase von Passwörtern auf Schlüssel wichtig, um sich nicht versehentlich selbst auszusperren. Bei Problemen mit der Schlüsselanmeldung, tritt wieder die Passwortauthentifizierung in Kraft. Wenn aber alles funktioniert, sollte man in der /etc/ssh/sshd_config des Servers noch folgenden Einträge ändern, dann kann man sich nicht mehr mit Passwort anmelden:
PasswordAuthentication no #UsePAM yes
- die Änderungen werden mit rcsshd restart wirksam.
- Damit sind nur noch Benutzer zugelassen, die einen Publikkey auf dem server besitzen. Ein Passwort für irgendeinen User nützt zur Anmeldung über ssh gar nichts mehr.
Hans muss jetzt nur auf seinen privaten Schlüssel aufpassen. Sowohl Verzeichnis ~/.ssh als auch der private Schlüssel sollten immer für andere nicht lesbar sein. Wer noch sicherer gehen will, vergibt bei der Erzeugung des Schlüssels eine Passphrase. Die muss er dann aber beim Verbindungsaufbau immer angeben.
Authentifizierung mit PuTTY
Diese Art der Authentifizierung lässt sich auch mit PuTTY verwenden. Mit putty und ssh key auf einen sicheren Linux Server zugreifen
Weitere Hinweise
- Gut wäre noch, wenn wir ganz verbieten, dass man sich als root am Server anmelden kann. Als User angemeldet können wir immer noch zum User Root wechseln um Verwaltungsaufgaben zu erledigen. Kontrolliertes Ausfuehren von Befehlen als root
PermitRootLogin no
- Wenn man mehrere Schlüssel (z.B. für unterschiedliche Server oder verschiedene Netze) haben will, muss man diese unter unterschiedlichen Namen speichern (zB. id_dsa, id_dsa_netz1, id_dsa_netz2 ) Damit der SSH Client dann auch den richtigen findet, muss man dies mit der Option -i angeben also:
ssh -i id_dsa_netz1 server
