Public und Private RSA-Key generieren und verwenden

Schlüssel sind zuverlässiger als Passwörter, aber auch etwas mühsamer in der Anwendung. Viele Web-Hoster gehen progressiv dazu über, einloggen nur mehr über RSA-Schlüssel zuzulassen. Das sind zwei Dateien:

• einen öffentliche, die als Schloss vom Administrator des Zielservers dort installiert wird
• einen privaten, den man als eigentlichen Schlüssel bei sich behält und auch mit einem Passwort schützt. Diesen verwendet man in Consolen und anderen Programmen, die sich mit dem Zielserver verbinden (SFTP, Datenbank-Verwaltung etc.).

Unter Windows kann man die beiden Schlüssel mit dem kleinen Programm Putty Gen erzeugen und später mit Pageant für Putty, der bekannten SSH-Konsole, aktivieren. Die einzelnen Programme findet man auf der Putty-Homepage.

Putty Gen

Nach dem Installieren startet das kleine Programm mit diesem Fenster und man kann gleich eine Schlüsselpaar generieren. Welchen Typ es braucht, verrät der Admin des Zielservers, die in den Screenshots angeführten sind aber standard. Unser Server braucht den Typ “SSH-2 RSA”.

Es folgt die kuriose Aufforderung mit der Maus im grauen Feld herumzufahren, dabei generiert man Zufallswerte:

Danach folgt das letzte Fenster, hier gibt man dem erzeugten Schlüsselpaar einen Namen (oder belässt den angeführten) und vergibt idealerweise ein Passwort für den eigenen privaten Schüssel.

Danach nicht auf Generate klicken, das ist nur ein Neustart der Prozedur.

Auch nicht auf Save public key klicken. Das erzeugt eine *.key-Datei mit Zeilenumbrüchen, die man auf Ubuntu-Servern nicht brauchen kann. Um diesen Key zu speichern: rechte Maustaste auf das Feld mit dem Zahlen- und Buchstaben-Code, “alles auswählen”, dann “kopieren” und dies in eine leere ASCII-Text-Datei (Texteditor) einfügen.

Den Button Save private key kann man aber anwählen, um eine *.ppk-Datei zu speichern.

Wenn das Schlüsselpaar bereits generiert ist und der öffentliche Schlüssel bereits am Server liegt, kann man trotzdem noch das Passwort ändern: unter File lädt man den privaten Schlüssel und ändert was man braucht, generiert aber anschliessend nur den privaten Schlüssel neu.

Key auch unter Linux verwendbar

Will man einen unter Windows generierten Schlüssel auf einem Linux-Desktop verwenden, so muss dieser ein spezielles Format haben, das ebenso PuttyGen erzeugen kann. Dafür lädt man den privaten Schlüssel in PuttyGen und exportiert dann weiter unter Conversions > Export OpenSSH key. Diese Datei spielt man dann auf dem Linux-Rechner unter ~/.ssh/authorized_keys. Damit diese Datei auch später verwendet werden kann, darf sie nur vom betreffenden user lesbar sein, also führt man unter ~/.shh diesen Befehl aus chmod og-rwx authorized_keys.

Keys am Handy unter Android

Auch hier braucht man einen richtig formatierten public key. Man kann einen existierenden laden (Bild unten links) oder einen neuen wie oben genieren, dann aber als OpenSSH key exportieren.

Wir besprechen das einrichten mit JuiceSSH.

Zuerst müssen wir einen User unter Manage Connections und Identitäten anlegen. An dem User hangen auch die privaten Schlüssel.

Das Interface fragt nach einen Namen, einen Kennwort und dem privaten Schlüssel. Dieser erscheint anschliessend in einer Liste.

Zuletzt speichert man die “Identität”.

So wie die User, müssen Verbindungen zuerst angelegt werden, um später aufgerufen zu werden. Unter Adresse fügt man die IP und dem Port an. Unter Identität wählt man jene zuvor definiert an, die natürlich zum Server passen muss bzw. muss zuvor der public key vom Administrator hochgespielt worden sein.

Zuletzt folgt das konkrete Verbinden: im Startmenü steht die Verbindung und im folgenden wird das Passwort für den private key abgefragt. Wenn alles eingeben wurde, startet anschliessend ein klassisches SSH-Fenster.

Schlüssel verwenden

Der öffentliche Schlüssel muss nun an den Server-Admin geschickt werden. Er muss nicht speziell geschützt werden.

Diese Datei wird dann auf dem Linux-Rechner unter ~/.ssh/authorized_keys abgelegt. Damit die Datei auch später verwendet werden kann, darf sie nur vom betreffenden User lesbar sein, also führt man unter ~/.shh diesen Befehl aus: chmod og-rwx authorized_keys.

Mit Pageant und Putty

Pageant und Putty müssen installiert sein. Man startet zuerst Pageant, das geht indem man die Datei *.ppk anwählt. Jetzt wird das zuvor vergeben Passwort abgefragt. Das Programm versteckt sich dann ggf. in der Taskleiste und auf die wenigen Menüpunkte kommt man mit der rechten Maustaste:

• Unter View Key bzw. Add Key kann man den zuvor gerierten Schlüssel sehen bzw. weitere hinzufügen und hierin verwalten.
• Unter New Session startet der normale Putty-Dialog zum Eintragen neuer Server.
• Unter Saved Sessions befinden sich jene, die bereits mit RSA-Key im Putty Dialog gespeichert wurden. Wählt man eine dieser an, startet sofort die Console mit dem Login.

Nach der Eingabe des Usernamens, folgt keine weitere Passwortabfrage, aber es wird der verwendete Schlüssel anzeigt:

login as: aw
Authenticating with public key "rsa-key-20190104" from agent
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42...)
Last login: Mon Jan 14 17:04:43 2019 from ...
aw@www:~$ _

Sicherheitslücke im Büro

Schliesst man nun Konsole und Putty, so bleibt aber Peagant mit dem privaten Schüssel in der Taskleiste aktiv. Das gilt auch wenn man den Computer verlässt und jemand anderer gelangt zur Tastatur, dann reicht der Username zum einloggen!

Putty, Pageant und root-Zugriff

Es ist sinnvoll, direktes Einloggen mit den Root-Account zu verbieten, auch und besonders mit RSA-Schlüssel. Es ist besser wenn man das Passwort öfters einfach ändern kann, User aber zuvor trotzdem mit Schlüssel-Paaren einloggen. Das heisst, man wechselt mit su dann zu root.

Soweit so logisch, aber Putty ist hier eigenwillig. Man kann nämlich bei Peageant den privaten Schlüssel angeben und mit dem Passwort entsperren, anschliessend Putty unabhängig von Pageant öffnen und ohne Passwort einloggen. Bloss kann man dann nicht mehr zu root wechseln! Das geht nur wenn man Putty direkt über New Session oder Saved Sessions gestartet hat.

Unter Linux

Hier braucht man kein spezielles Programm, dieser Befehl reicht zum Verbinden: ssh ~/.ssh/authorized_keys [USER]@[SERVER-IP].

SFTP mit Pageant FileZilla

Auch FileZilla kann einen initiierten privaten Schlüssel von Pageant nützen. Man gibt dazu die etwas kurios benannte Verbindungsart Interaktiv und nur den Usernamen an. Mit Verbinden loggt man direkt ohne weitere Passwortangabe ein. Dafür muss der Server naturlich unter der angegeben Adresse antworten. Unter Umständen ist das nicht der Name sondern nur die IP-Adresse.

Alternativ loggt man zuvor via Pageant ein.

Man kann hier aber auch der Auswahl Schlüsseldatei die *.ppk-Datei angeben und es wird dann bei jedem Verbinden zuvor nach dem Passwort gefragt.

Auch hier, nach dem Schliessen von FileZilla bleibt der Schlüssel in Pageant aktiv und entsperrt solange der Computer an ist.

Private tunnel via Putty und PgAdmin4 zu einer PostgreSQL-Datenbank

Wenn ein Server gut abgesichert ist, kommt man auch nicht direkt mit IP, Port, User und Passwort an die Datenbank. Es bestünde nun die Möglichkeit, die Datenbank per RSA-Key anzusprechen, die Sache spielt sich unter /etc/postgresql/[version]/main/postgresql.conf ab, hier sind Verweise zu ssl zu finden.

Man kann aber auch nur mit Putty und einen normalen User-RSA-Key Programme wie PgAdmin4 anhängen:

• Wie oben startet man Putty über Pageant, geht dann aber auf New Session (sonst startet man direkt die Console).
• Anwählen der Verbindung mit dem RSA-Schlüssel (in unseren Beispielen carto.net.2019).
• Unter Category runterscrollen bis Connection/SSH/Tunnels und hier folgendes angeben:
  • Source port 5432. Dieser Port wird am eigenen Rechner verwendet. Er kann auch anders lauten, z. B. 12222.
  • Destination localhost:5432. So wird der entfernte Server intern angesprochen (wenn man über die Konsole eingeloggt ist). 5432 ist der PostreSQL-Port.
  • Auf Add klicken, unter forwarded Ports steht nun L5234 localhost:5432 oder z. B. L12222 localhost:5432.
• Diese Einstellungen oben unter Session wieder speichern.
• Mit diesen Einstellungen eine Konsole öffnen und einloggen.

SSH-Tunnel unter Linux

Der Tunnel ist viel einfacher im ssh-Befehl eingbaut: ssh -L 12222:localhost:5432 ~/.ssh/authorized_keys [USER]@[SERVER-IP]. Das weitere Prozedere unter PgAdmin4 ist ident.

Verbinden mit PgAdmin4

Unter PgAdmin legt man nun eine neue Serververbindung an:

• Unter General gibt man einen beliebigen Namen an, ich habe hier localhost gewählt. Nicht wundern wenn eine Fehlermeldung kommt, denn die wichtigen Anweisungen sind unter Connection anzugeben und das Interface ist anscheinend ungeduldig.
• Unter Connection gibt man die normale Verbindung an. localhost ist hier der eigene Rechner, der Port 5423 ebenso der des eigenen Rechners, die restlichen Angaben sind wiederum der Datenbank am entfernten Server zuzurechnen. Hat man oben den Port 12222 gewählt, so muss man diesen auch hier einsetzen.
• Wenn man über Pageant und Putty angemeldet ist, kann man sich nun mit der Datenbank in PgAdmin verbinden. Es kann passieren, dass die Verbindung aktiv angezeigt ist, aber die Datenbanken etc. sich nicht ausklappen lassen. Dann hilft es den DB-Server zu trennen und am selben Weg wieder zu verbinden. Anscheinend startet der Tunnel nicht automatisch oder pgAdmin sendet kein volles connect-Signal für gespeicherte Einträge. Ein Refresh alleine reicht nicht.

Das Beispiel oben mit dem anderen Port, eben 12222, schaut in dem Masken so aus:

Fehler oder unerwartete Eigenschaften

• Manche Tabellen lassen sich nicht editieren, wenn sie keine Primary Keys haben.
• Wenn man pgAdmin schliesst ohne sich darin vom Server abzumelden oder wenn man über die Konsole per exit ausloggen will während pgAdmin-Verbindungen aktiv sind, wird das Logout nicht aktiv angenommen. Nur wenn man Fenster schliesst, wird die Verbindung unterbrochen.