Automatisierung SSH Login mit RSA Zertifikat
Einführung
SSH (Secure Shell) ist ein kryptographisch abgesichertes Protokoll, um auf Remoterechner (üblicherweise mit einem Unix OS) auf der Kommandozeile arbeiten zu können. Nebenbei unterstützen gängige Implementierungen nützliche Features, wie z.B. Portweiterleitung. SSH löst die veralteten und unsicheren Protokolle RSH, Telnet und RExec ab.SSH besteht aus einer serverseitigen Komponente, dem SSH Daemon, sowie der für uns interessanteren Komponente, dem SSH CLient. Die typische Konstellation, die man als Softwaretester trifft, besteht aus einem oder mehreren Unix Server mit einem SSH Daemon, sowie einem Windows Arbeitsplatz, meist noch ohne SSH Client. Als SSH Client unter Windows hat sich quasi das freie PuTTY etabliert.
Soweit so bekannt, dass Login via SSH ist nichts, was einem Berater im Bereich Software Qualitätssicherung unbekannt sein sollte. Weniger bekannt, oder besser gesagt weniger verwendet, ist die Möglichkeit, sich ohne Passwort mit Hilfe eines Zertifikats anzumelden.
Vor- und Nachteile
- Keine Notwendigkeit sich ein sicheres Passwort zu merken oder es regelmässig zu ändern
- Keine manuelle Interaktion für ein Login notwendig
- dadurch besteht eine problemlose Automatisierungsmöglichkeit für z.B. Shell Scripts
Generierung Public/Private RSA Key
Der Private Key ist der Teil, der nicht weitergegeben werden darf. Damit authentifiziert man sich gegenüber dem eigenen Public Key, der an der entsprechenden Gegenstelle im Vorfeld bekannt gemacht werden muss.
Empfohlen wird die Verwendung des asymmetrischen Verschlüsselungsverfahren "SSH-2 RSA", als Schlüssellänge ist 2048 Bit empfehlenswert. Nun kann man mit "Generate" das Schlüsselpaar generieren lassen.
Als "Key comment" kann man seinen Unix Benutzernamen verwenden, dann ist im oberen Public Key Feld schon alles richtig eingetragen. Man kann es aber auch nachträglich ändern, das Feld ist im Klartext dabei.
Man hat nun ausserdem die Möglichkeit, den Private Key zusätzlich mittels "Key Passphrase" mit einem Passwort zu schützen. Man muss dann bei jedem Öffnen des Keyfiles das Passwort angeben. Nutzt man den "PuTTY Agent", muss das Passwort nur einmalig angegegen werden (später dazu mehr).
Beide Keys müssen nun mit Hilfe der entsprechenden Buttons gespeichert werden. Dabei ist es unbedingt notwendig, den Private Key an einen sicheren Ort abzulegen. Das ist umso wichtiger, wenn man den Private Key nicht mit einem Passphrase versehen hat. Ich empfehle die Verwendung eines Passphrases. Zusätzlich ist es empfehlenswert, sich den Inhalt des oberen Textfelds (OpenSSH Public Key) manuell in einer Datei wegzusichern. Diese enthält den Public Key in einem etwas anderen Format, wie wir es unten beschrieben benötigen.
Bekanntmachung Public Key
Der Public Key muss nun serverseitig integriert werden, damit eine Authentifizierung gegen den persönlichen Private Key erfolgen kann. Dies muss bei gewöhnlichen Unix Systeme manuell vorgenommen werden.Dazu führt man ein herkömmliches SSH Login mit Username / Passwort durch. Anschliessend muss der soeben generierte Public Key auf den Server transferiert werden. Da die meisten Server OpenSSH verwenden, sollte man es zuerst mit dem Key im OpenSSH Format probieren. Zum Transferieren der Datei gibt es verschiedenste Möglichkeiten, die "Quick&Dirty" Lösung ist einfach Copy&Paste in einen Unix Texteditor.
Der SSH Daemon erwartet den Public Key an einen genau definierten Ort. Üblicherweise muss der Key in das File authorized_keys im Unterverzeichnis .ssh unter dem eigenen Homeverzeichnis.
user@host ~ # ls -al drwx------ 2 root root 4,0K 9. Feb 2011 .ssh user@host ~ # cat ~/openssh_public_key >> ~/.ssh/authorized_keys
Existiert dieses Verzeichnis oder Datei noch nicht, muss man sie selber anlegen. Dabei sind auf korrekte Berechtigungen zu achten. Eine authorized_keys, auf die jeder andere User schreiben kann, ist üblicherweise nicht das, was man will...
Private Key
Damit hat man zwar ein Plus an Sicherheit erzielt, da nun sowohl das Private Key File als auch das Passphrase notwendig sind, aber für unsere Zwecke hat man letztendlich nichts gewonnen. Sinn des ganzen ist ja, eine Automatisierungsmöglichkeit zu schaffen ohne hässliche Workarounds wie Plaintext Passwörter in Scripte.
Mit Private Keys ohne Passphrase zu arbeiten wird dem zuständigen Systemadministrator des Kunden andererseits überhaupt nicht gefallen. Das ist anhand der Serverlogs zwar nicht erkennbar, aber die eigene Sorgfaltspflicht verbietet einen unnötig fahrlässigen Umgang mit Systeme des Kunden.
Der Agent läuft als Hintergrundservice und beantwortet Zertifikatsanfragen von PuTTY mit den hinterlegten Private Keys, solange man dieses Feature nicht explizit deaktiviert.
Die Bedienung des Agents ist selbsterklärend, einfach den persönlichen Private Key hinzufügen und die Konfiguration ist abgeschlossen. Das Passphrase muss dabei nur einmalig nach hinzufügen des Keys eingegeben werden, solange der Service läuft.
Automatisierung
Nun kann beispielsweise der PuTTY Kommandozeilenclient "plink" auf sichere Weise in Batch Scripte oder aus beliebigen Testtools heraus verwendet werden.C:\Program Files (x86)\PuTTY>plink -v root@sw-quality.de Looking up host "sw-quality.de" Connecting to 213.239.217.134 port 22 Server version: SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1 Using SSH protocol version 2 We claim version: SSH-2.0-PuTTY_Release_0.61 Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange with hash SHA-256 Host key fingerprint is: ssh-rsa 2048 4d:90:f7:c8:14:2d:0f:1e:7a:00:3a:42:d8:03:34:11 Initialised AES-256 SDCTR client->server encryption Initialised HMAC-SHA1 client->server MAC algorithm Initialised AES-256 SDCTR server->client encryption Initialised HMAC-SHA1 server->client MAC algorithm Pageant is running. Requesting keys. Pageant has 1 SSH-2 keys Using username "root". Trying Pageant key #0 Authenticating with public key "sreitinger" from agent Sending Pageant's response Access granted Opened channel for session Allocated pty (ospeed 38400bps, ispeed 38400bps) Started a shell/command
Hinweis Für das Systemmonitoring in kurzen Intervallen während Last- und Performancetests ist diese Methode nur eingeschränkt geeignet. SSH Logins benötigen durch den Diffie-Hellman Schlüsselaustausch einiges an Rechenpower.
Eine alternative Methode des Live Monitorings über SSH ohne wiederholte SSH Logins stelle ich in einem zukünftigen HowTo vor.