CVS mit SSH

Dieses Dokument zeigt, wie ein Zugang zu einem CVS-Server eingerichtet werden kann, so daß die Benutzer zwar CVS nutzen, aber keine Logins auf Shell-Ebene durchführen können. Dazu wird der forced command Mechanismus von OpenSSH verwendet, mit dessen Hilfe lediglich das CVS-Kommando auf dem Server ausgeführt werden kann.

Bei der Einrichtung des Clients gibt es normalerweise wenig zu beachten, es sei denn, man verwendet Windows 98.

Auf die Besonderheiten bei der Verwendung von Windows 98 wird in einem eigenen Abschnitt eingegangen.

Zunächst einmal muß CVS auf dem Server installiert werden, falls das noch nicht der Fall ist. Die aktuelle Version bekommt man unter http://savannah.nongnu.org/projects/cvs/. Da in der Vergangenheit immer mal wieder sicherheitsrelevante Fehler in CVS auftraten, sollte man auch hier entsprechend bereinigte Versionen verwenden (siehe auch: CERT Advisories).

Außerdem wird ein SSH-Server benötigt. Hier bietet sich OpenSSH an, das für viele System verfügbar ist. Für OpenSSH gilt in puncto Sicherheitsvorgeschichte das für CVS Gesagte (siehe auch: CERT Advisories). Bei der Konfiguration des SSH-Servers gilt es zu beachten, daß „Public Key Authentication“ erlaubt ist. Für CVS ist kein anderes Verfahren erforderlich, so daß man solche auch verbieten kann, sofern sie nicht anderweitig gebraucht werden.

Als nächstes kann man User Accounts für die späteren CVS-Benutzer einrichten. Dabei sollte man folgendes beachten:

• Der User braucht eine Shell (leider) … eine richtige Shell, keine Dummy-Shell.
• Der User muß das Kommando cvs ausführen können und die Repository muß für ihn erreichbar sein. Das muß insbesondere beachtet werden, wenn der Benutzer nach dem Login „ge-chroot-et“ wird (siehe auch SSH in einer chroot Umgebung) oder der CVS-Server in einem chroot Käfig läuft.
• Das Homeverzeichnis sollte zunächst einmal leer sein. Man legt dann das Verzeichnis .ssh mit den entsprechenden Rechten an.
• Die Dateien .rhosts und .forward sollte man anlegen und mit den richtigen Rechten und – soweit es das Filesystem unterstützt – Fileattributen sichern, so daß der Benutzer diese nicht ändern kann.

Solchermaßen vorbereitet besorgt man sich nun den SSH Public Key des späteren Benutzers und schiebt ihn in dessen Homeverzeichnis als ~/.ssh/authorized_keys. Auch diese Datei sollte man durch Rechte/Attribute entsprechend sichern.

Zuvor jedoch muß die authorized_keys Datei noch etwas ausgestattet werden. Über ein vorangestelltes command="Kommando" veranlaßt man OpenSSH beim Login mit diesem Public Key das entsprechende Kommando auszuführen und nichts anderes. Wenn man schon dabei ist, kann man auch gleich noch ein paar andere Optionen setzen, die allesamt vor den Public Key gestellt werden. Die Option from= ergibt natürlich nur Sinn, wenn der spätere Benutzer immer von der selben IP-Adresse aus zugreift. Die Datei authorized_keys könnte demnach so aussehen (Der eigentliche Key wurde größtenteils weggekürzt und das alles muß   inkl. Key   in einer Zeile stehen, auch wenn es hier um der Lesbarkeit willen umgebrochen wurde. Die Optionen werden ausschließlich durch Kommata getrennt; zwischen Optionen und Key muß mindestens ein Leerzeichen stehen.):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,
command="/usr/local/bin/cvs server",from="10.0.0.1" ssh-rsa KrRNTLxBm0/d ...

Wie man leicht sieht, heißt also das Kommando, das serverseitig zur Ausführung der diversen CVS-Befehle gebraucht wird, cvs server.

Damit ist die Einrichtung auf dem Server abgeschlossen.

Inhalt

Die CVS-Installation auf dem Client gestaltet sich nicht anders als beim Zugriff auf andere Repositories (für Windows 98 siehe Beispiel: WinCVS/OpenSSH unter Windows 98). Man muß lediglich sicherstellen, daß CVS für die Verbindung SSH verwendet. Die Authentisierung muß mit dem SSH Private Key erfolgen, dessen zugehöriger Public Key bei der Installation auf dem Server in die authorized_keys Datei des Users eingetragen wurde.

Die entsprechenden Environment Variablen könnten beispielsweise folgendermaßen aussehen:

CVSROOT=:ext:cvsuser@remo.te:/path/to/repos
CVS_RSH=ssh

Inhalt

Hinweis: Die nachfolgende Beschreibung zeigt ein WinCVS/OpenSSH Setup unter Windows 98, das ich selbst erfolgreich getestet habe. Einfacher geht es jedoch womöglich mit dem Windows SSH Client PuTTY und CrossVC als CVS Client. Danke an Tilo Riemer für den Hinweis.

Die Client-Installation unter Windows 98 gestaltet sich u.U. etwas komplizierter. Zunächst einmal benötigt man ein Windows-taugliches SSH, daß die Protokollversion 2 unterstützt. Einen entsprechenden Client bekommt man zwar von F-Secure (siehe F-Secure SSH), dieser bietet aber   in der kostenfreien Version   neben diversen Lizenz-bedingten Einschränkungen keine Authentisierung über SSH Public Keys … Bong … Damit können wir diesen Client gleich wieder vergessen, zumal mit OpenSSH ja eine Alternative zur Verfügung steht.

Da es eine OpenSSH Portierung für Windows gibt (siehe http://sshwindows.sourceforge.net/), könnte man auf die Idee kommen, diese zu installieren und zusammen mit dem wohl verbreitetesten Windows CVS Client   WinCVS   einzusetzen. Leider funktioniert das nicht, da WinCVS bei Verbindungen über SSH höchst intolerant reagiert, wenn der verwendete SSH Client Fehler- und/oder Warnhinweise ausgibt. Genau das tut der OpenSSH Client jedoch bei Windows 98, weil er versucht ein Verzeichnis .ssh anzulegen (was Windows 98 nicht zuläßt). Möglicherweise könnte man die Kombination OpenSSH für Windows und WinCVS lauffähig machen, wenn man ein $HOME auf ein Verzeichnis eines Netzlaufwerkes setzt, in dem das Verzeichnis .ssh vorhanden ist. Das habe ich aber nicht ausprobiert.

Eine funktionsfähige Lösung stellt unter Windows 98 jedoch die Verwendung von WinCVS mit OpenSSH in der Cygwin Umgebung dar. Cygwin ist eine *NIX-artige Umgebung für Windows und beinhaltet neben einem Grundsystem eine beachtliche Anzahl zusätzlicher Pakete, darunter auch OpenSSH (und CVS).

Cygwin wird nun zunächst installiert (was nicht schwer ist, siehe Cygwin User Guide). Neben den Grundkomponenten benötigt man zusätlich nur OpenSSH. Um CVS auch über die Kommandozeile zu nutzen, kann man auch das Paket CVS installieren, was jedoch für WinCVS nicht notwendig ist.

Nach der Cygwin Installation startet man zunächst einmal die Bash-Shell (durch Doppelclick auf das Cygwin Symbol), damit das eigene Homeverzeichnis angelegt werden kann. Dieses befindet sich in c:\cygwin\install\path\home\username. Dort legt man mit mkdir .ssh (Punkt nicht vergessen) das entsprechende SSH Verzeichnis an. In dieses kopiert man nun seinen SSH Private Key. Anschließend baut man   immernoch in der Cygwin Shell   eine Verbindung zu CVS Server manuell auf (z.B. ssh cvsuser@remo.te). Zwar wird man keinen Shell-Zugang bekommen (siehe Installation auf dem Server), aber OpenSSH bekommt die Chance, den Host Key von remo.te zu erfahren und wird in Zukunft keine Meldungen über einen unbekannten Host Key zeigen (die WinCVS zum Abbrechen bringen würde). Schießlich setzt man noch die Environment Variable HOME in c:\autoexec.bat (set HOME=c:\cygwin\install\path\home\username) und macht einen Neustart.

Nun kann man WinCVS installieren (getestet habe ich mit Version 1.3.12.1 Beta 12 (Build 1)). Nach dem Start stellt man dort unter Preferences/General als Authentication ssh ein sowie die weiteren Angaben zum Server und dem Pfad der Repository. Die Authentication läßt sich über den Button Settings ... noch weiter spezifizieren. Dort gibt man seinen Private Key an (in $HOME/.ssh) und die Cygwin OpenSSH Binary (c:\cygwin\install\path\bin\ssh.exe). Falls man CVS auch unter Cygwin auf der Kommandozeile nutzen will, so muß bei WinCVS unter Preferences/Globals die Option Checkout text files with the Unix LF (0xa) aktiviert werden.

Nun kann man per WinCVS auf die entsprechende Repository zugreifen. Dabei wird ein comamnd.com Fenster geöffnet, in dem OpenSSH läuft. Falls man nicht den SSH Agent benutzt (das ist eine andere Geschichte) oder einen Private Key ohne Paßwortschutz hat (Urgs), muß man in diesem Fenster das Paßwort für den Private Key eingeben, bevor es weitergehen kann. Und damit ist die Installation auch schon abgeschlossen.

Inhalt

Eine persönliche Anmerkung zum vorangegangenen Beispiel sei gestattet: Der Grund für die Wahl von Windows – und sogar Windows 98 – in diesem Beispiel ist schlicht und einfach, daß ich vor einiger Zeit gezwungen war, so etwas für einen Kunden einzurichten und es sich doch als etwas kniffeliger herausstellte als zunächst gedacht. Keinesfalls soll das Beispiel dazu dienen, diese Plattform zu propagieren. Meiner Meinung nach war Windows 98 nie ein gutes Betriebssystem, schon gar nicht im Netzwerk (inwieweit neuere Windows Versionen verbessert wurden, will ich hier nicht diskutieren, dazu fehlt es mir auch an entsprechender Erfahrung). Mittlerweile ist Windows 98 auch noch völlig veraltet und es gibt keinen Support mehr dafür, so daß ein solches System durchaus eine Sicherheitsrisiko darstellt.

Inhalt