Aus LinuxUser 07/2001

Zu Befehl

Auf der sicheren Seite – ssh und scp

Jedesmal, wenn Sie sich über telnet auf einem Rechner anmelden oder per ftp Daten von einem Computer zu einem anderen übertragen, wird das Passwort – wie alle anderen Daten auch – im Klartext gesendet. Damit kann jeder, der den Netzverkehr „abhört“, Informationen und damit auch Zugang zum benutzten Account bekommen. Mit der Secure Shell (ssh) und den dazugehörenden Kommandos ssh für das Login und scp zur Dateiübertragung sind sie auf der sicheren Seite: Hier kommen verschlüsselnde Alternativen auf der Kommandozeile.

Telnet, FTP & Co. übertragen alle Daten im Klartext: Sind Sie per Telnet auf einem anderen Unix-Rechner eingeloggt und geben dort ein Passwort ein, dann wird dieses zwar eventuell nicht angezeigt (viele Programme schützen Passwortdialoge etwa durch Anzeigen von Sternchen), mit einem Packet-Sniffer lässt sich ein solches Passwort aber problemlos auslesen. Ebenso können per FTP übertragene Daten von Neugierigen kopiert werden. Ausreichende Gründe, auf die Verwendung der Secure Shell, ssh, umzusteigen.

Nicht nur Shell-Sitzungen können mit ssh verschlüsselt werden, sondern auch X11-Verbindungen. Dabei kann direkt die Umgebungsvariable $DISPLAY richtig gesetzt werden – Sie können auf diese Weise Anwendungen auf einem anderen Computer starten. Bevor es ins Detail geht: Gegenwärtig existieren zwei unterschiedliche und inkompatible Versionen des SSH-Protokolls: SSH 1.x und SSH 2.x. Da SSH 1.x (und damit zusammenhängend OpenSSH) mit hoher Wahrscheinlichkeit auf Ihrem Linux-System zum Einsatz kommt, ist in diesem Artikel SSH 1.x gemeint, wenn von ssh die Rede ist.

Clients und Daemons

Zu SSH gehören auf der Client-Seite ssh/slogin als funktionaler Ersatz von telnet, rlogin oder rsh sowie scp zum Kopieren von Dateien (ersetzt ftp und rcp). Der Server ist der sshd (SSH-Daemon). Darüber hinaus gibt es Administrationswerkzeuge wie z. B. ssh-keygen (zum Erzeugen von RSA-Schlüsseln), ssh-agent (zur Verwaltung der RSA-Keys, Automatisierung und Vereinfachung des Logins), ssh-add (Registrierung neuer Schlüssel beim SSH-Agent) und make-ssh-known-hosts (Erstellung einer Liste mit bekannten öffentlichen Host-Keys einer Domain). ssh muss sowohl auf Ihrem eigenen Rechner wie auch auf der Gegenseite installiert sein; genauer: um eine Verbindung von A nach B aufzubauen, muss auf Rechner A die Client-Software und auf B der Daemon installiert sowie letzterer auch aktiviert sein.

Um sich auf einem anderen Rechner einzuloggen, tippen Sie

ssh [Userid@]RemoteHost

wobei die Userid@ nur angegeben werden muss, wenn der Benutzername auf dem anderen System von dem Ihres eigenen Rechners abweicht. Hinter den Kulissen baut der der Client eine TCP/IP-Verbindung zum Server auf (Default-Port: 22). Nach Austausch der Protokollversion wird während der Verbindung auf ein paketbasiertes Binär-Protokoll umgeschaltet.

Alternativ zu Userid@RemoteHost können Sie auch den Aufruf

ssh -l Userid RemoteHost

verwenden. Diese Aufrufform ist an die Syntax des (unsicheren) rlogin angelehnt. Möchten Sie sich nicht auf dem anderen Computer anmelden, sondern nur einen Befehl ausführen, können Sie diesen direkt in den Aufruf mit hineinnehmen. Vorsicht bei Wildcards: Wenn Sie diese verwenden, sollte der Befehl in Anführungszeichen eingeschlossen werden, da sonst die Shell des eigenen Rechners eingreift:

huhn@asteroid:~$ ssh plutarch.cologne.de "ls -l xani*"
 huhn@plutarch.cologne.de's password:
 -rwxr-xr-x    1 huhn     users      630396 Nov 14  2000 xanim.cine

Mit dem Aufruf

ssh -t [Userid@]RemoteHost mutt

wird in einem „Pseudo-Terminal“ der Mail-Client mutt gestartet. Die Ausgabe auf diesem Terminal wird verschlüsselt übertragen und entschlüsselt im eigenen Terminalfenster angezeigt. Der Parameter -t wird für Programme benötigt, die die Bildschirmsteuerung selbst übernehmen; ein einfacher Aufruf der Form ssh RemoteHost mutt würde fehlschlagen.

… weitere Parameter

Sichere Dateitransporte

Das zweite große Anwendungsgebiet von ssh neben dem geschützten Login ist der Datei-Transfer: Hier ersetzt das Tool scp (secure copy) die ungeschützten Dienste ftp (file transfer protocol) und rcp (remote copy).

Eine Datei per scp zu kopieren, ist fast so einfach wie das normale, lokale Kopieren mit cp; ein Beispiel-Aufruf sieht etwa so aus:

scp /tmp/archiv.tgz UserId@RemoteHost:/tmp/

Stimmen die User-Namen überein, kann auch hier wieder UserId weggelassen werden, es bleibt also scp datei RemoteHost:Verzeichnis. Über die Option „-r“ (für rekursiv) lassen sich auch ganze Verzeichnisse kopieren; auch die von cp bekannte Option „-p“ (preserve; Rechte und Besitzer/Gruppe erhalten) kann hier verwendet werden. Das ergibt natürlich nur Sinn, wenn User- und Group-IDs auf beiden Systemen identisch sind.

Ohne Passwort anmelden

Wollen Sie nicht nur gelegentlich sondern häufig Dateien zwischen Rechnern übertragen oder sich auf einem anderen System anmelden, so kann die ständige Passwort-Abfrage des Zielsystems störend sein; auch eine Automatisierung von Standardaufgaben über Skripte scheitert am interaktiven Element der Passwort-Eingabe. Hier bietet ssh die Möglichkeit, einen Schlüssel auf dem Zielsystem zu hinterlegen, über den Ihre Berechtigung zum Login nachgeprüft werden kann, ohne ein Passwort zu verlangen. Ein solcher Schlüssel, englisch: Key, ist mit dem Programm ssh-keygen zu erzeugen. Das Programm wird einfach ohne Parameter aufgerufen:

huhn@asteroid:~$ ssh-keygen
 Generating RSA keys: ………………………………………oooooO……………oooooO
 Key generation complete.
 Enter file in which to save the key (/home/huhn/.ssh/identity):
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in /home/huhn/.ssh/identity.
 Your public key has been saved in /home/huhn/.ssh/identity.pub.
 The key fingerprint is:
 1024 f7:a8:6f:6e:1a:e9:6c:3c:43:a8:a2:82:c4:cb:d4:08 huhn@asteroid

Die „Passphrase“, nach der hier zwei mal gefragt wird, hat nichts mit dem Passwort auf dem Zielsystem oder Ihrem lokalen Passwort zu tun – vielmehr können Sie mit Hilfe der Passphrase Ihr Schlüsselpaar (bestehend aus einem öffentlichen und einem geheimen Schlüssel, dazu gleich mehr) schützen. Ein solcher Schutz ist z. B. beim Einsatz von ssh auf einem Notebook sinnvoll, denn sollte Ihr Notebook gestohlen werden und sich auf diesem ein ungeschützter ssh-Key befinden, so kann dieser zum Einbruch in ein anderes System verwendet werden. Auf stationären Rechnern, die Sie vor dem Zugriff anderer sicher wähnen, kann darauf aber verzichtet werden.

In Ihrem Home-Verzeichnis befindet sich nun ein neues Unterverzeichnis .ssh (mit führendem Punkt), das u. a. das bereits erwähnte Schlüssel-Paar, bestehend aus identity und identity.pub enthält. Erste Datei ist Ihr geheimer, privater Schlüssel (eine binäre Datei, die sich nicht im Editor lesen lässt); die zweite Datei mit der Endung „.pub“ ist der öffentliche (public) Schlüssel. Dieser kann nun auf einen Zielrechner kopiert werden, um künftig eine automatische Anmeldung auf diesem System zu ermöglichen. Das geht folgendermaßen:

  • Kopieren Sie (z. B. mit scp) die Datei ~/.ssh/identity.pub ins Home-Verzeichnis des Zielrechners.
  • Loggen Sie sich dann auf dem Zielrechner ein. Prüfen Sie, ob dort bereits ein Unterverzeichnis .ssh existiert; wenn nicht, legen Sie es an (mkdir ~/.ssh).
  • Wechseln Sie (auf dem Zielrechner) in das Verzeichnis .ssh und hängen Sie die vom ersten Rechner kopierte Datei an die (eventuell bereits vorhandene) Datei authorized_keys an; das geht mit dem Befehl cat ~/identity.pub >> authorized_keys. (Sollte die Datei noch nicht vorhanden gewesen sein, wird sie von diesem Aufruf erzeugt.)
  • Löschen Sie schließlich die nun nicht weiter benötigte Datei identity.pub im Hauptverzeichnis (nur da!). Testen Sie nun, ob eine Anmeldung ohne Passwort-Abfrage möglich ist. Sollte dies nicht gelingen, sind eventuell die Rechte des .ssh-Verzeichnisses auf dem Zielrechner falsch gesetzt: Das Verzeichnis selbst muss mit den Rechten 700 ausgestattet sein (also lesbar, schreibbar, betretbar durch den Besitzer und niemand sonst). Darüber hinaus dürfen für das Home-Verzeichnis keine Schreibrechte für Gruppe (g) und Andere (o) gesetzt sein; führen Sie im Zweifelsfall die Befehle
chmod go-w ~
 chmod 700 ~/.ssh

aus. Um übrigens auch eine Verbindung in die andere Richtung zu ermöglichen (also verteilte Rollen von Client und Server), ist die Prozedur aus Schlüsselgenerierung und Einfügen in die authorized_keys erneut durchzuführen, nun eben umgekehrt.

LinuxUser 07/2001 KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS
Deutschland

Hinterlasse einen Kommentar

  E-Mail Benachrichtigung  
Benachrichtige mich zu: