Der Kermit 95 SSH Client


Übersetzung von http://www.columbia.edu/kermit/sshclient.html

8. Dezember 2002 11:01:22h
Letztes Update: 15. Oktober 2010 11:05:18h

Kermit 95 2.0 (und höher) fürWindows beinhaltet Secure Shell (SSH) v1- und v2-Clients, einen FTP-Client (der normale oder sichere Verbindungen herstellen kann) und einen HTTP-Client (dito), zusätzlich zu den vielen Verbindungsmethoden und Clients, die es bereits besitzt.

Dieses Dokument bezieht sich nicht auf C-Kermit 8.0 für Unix, welches den externen SSH-Client als Transportmittel für die Herstellung von SSH-Verbindungen benutzt, wie hier beschrieben.

Inhalte:

 1. K95 SSH Überblick
  2. Typische SSH-Session
  3. SSH-AUTHENTICATION-OPTIONEN
     3.1. Host-Authentication
     3.2. User-Authentication
  4. Bekannte Bugs
  5. Beachtenswerte Dinge
  6. Noch nicht implementiert
  7. Neue Befehle für SSH
     7.1. Der SSH-Befehl
     7.2. SET-SSH-Befehl

1. K95 SSH-Überblick

[ Top ] [ Inhalte ] [ Nächste ]

SSH wurde zu Kermit 95 hinzugefügt, weil immer mehr Seiten Telnet zurückweisen (clear-text oder secure) und für virtuelle Terminal-Connections SSH brauchen. Bei der Version 1.1.21 beinhaltet die Windows-(nicht OS/2)-Version von Kermit SSH v1- und v2-Clients:

  • Die SSH-Verbindungen von K95 basieren auf OpenSSH 3.0.2p1, welches erst im Windows-Developer-Tool kovertiert werden musste und dann stark angepasst wurde, um (a) „Connection in series“ zu erlauben, (b) sichere Authentifizierungsmethoden zu beinhalten und (c ) mit dem Rest von K95 zu koppeln.
  • K95 kann SSH-Verbindungen mit jedem Host herstellen, der sshd für SSH 1.3, 1.5 oder 2.0 besitzt. OpenSSH unterstützt nicht die SSH-Verbindung 1.2 oder frühere Versionen.
  • Wenn du beim Verbinden nicht eine bestimmten SSH-Version erzwingst ((SSH OPEN blah /VERSION:1), nimmt K95 automatisch eine Version. Die ausgewählte Version wird im Terminal-Screen-Status angezeigt, zB „SSH-2.0“.
  • Was die anderen Features von Kermit angeht, so ist der SSH-Client in jeder erdenklichen Weise vom User konfigurierbar (wem also die Standardeinstellungen und Handlungsweisen nicht passen, der kann sie ändern). Er beinhaltet auch eingebaute Schlüsselerstellung und Management-Werkzeuge, sodass keine externen „Hilfsapplikationen“ benötigt werden.
  • Die K95-Implementation von SSH wurde in Verbindungen mit Solaris getestet, sowie mit HP-UX 8.00 und höher, Linux, OpenBSD, FreeBSD, und VMS.

Die OS&2/Version von Kermit beinhaltet keinen SSH/Client, weil die OpenSSH/Libraries für OS&2 nicht erhältlich sind.

Die SSH/Verbindungen von Kermit werden mit den (neuen) SSH- und SET-SSH-Befehlen konfiguriert und kontrolliert. Diese sind von HELP SSH und HELP SET SSH beschrieben (der HELP-Text wird unten wiedergegeben).

2. Typische SSH-Sitzung

[ Top ] [ Inhalte ] [ Nächste ]
Beim  K-95> prompt, tippst du einfach „ssh somehost“, wobei „somehost“ der IP-Hostname bzw. die Adresse des Hostes ist, mit dem du dich verbinden willst, oder, wenn deine ID auf der Zieladresse eine andere als deine lokale User-ID ist, tippe „ssh someost /user:remoteuserid“. Bei der ersten Verbindung können einige Nachrichten oder Fragen zum Hostnamen kommen, etwa:

[C:\K95] K-95> ssh xyzcorp.com
The authenticity of host 'xyzcorp.com' can't be established.
DSA key fingerprint is 85:f9:8b:cd:23:12:01:d9:cf:7a:12:cf:b5:5d:ab:60.
Are you sure you want to continue connecting (yes/no)?

Aber das ist normal bei jedem SSH-Client. Falls du nicht glaubst, dass der Host ein imposter ist, sag „ja“ (mehr darüber im nächsten Abschnitt). Jetzt fragt doch K95 nach einem Passwort, du tippst es ins Kästchen, K95 sendet es an die verschlüsselte Verbindung, und los geht’s.

Von diesem Zeitpunkt an ist eine SSH-Session genau wie jede andere K95-Terminal-Session. Zur Eingabeaufforderung kommst du mit Alt-X, zum Terminal-Bildschirm mit C oder Alt-X, Dateien kannst du auch übertragen, was immer du möchtest. Wenn du dich beim Host ausloggst, sollte K95 automatisch zum Befehlsschirm zurückkehren, aber das hängt vom SSH-Server ab.

Eine Einzelinstanz von K95 kann derzeit nicht mehrere Terminalsessions managen, SSH, Telnet, Modem oder anders, aber natürlich kannst du mehrere Instanzen von K95 ausführen. Du kannst jedoch eine FTP-Session und/oder HTTP-Session zur selben Zeit als Terminalsession in einer K95-Instanz haben.

3. SSH-Authentifizierungsoptionen

[ Top ] [ Inhalte ] [ Nächste ]
SECTION CONTENTS

3.1. Host-Authentifizierung

3.2. User-Authentifizierung

SSH bietet Sicherheit (oder das Gefühl davon) durch die Verschlüsselung der Sitzung. SSH kann ohne Authentifizierung arbeiten, aber es bietet auch mehrere Optionen für sie, wobei keine vom ihnen besonders sicher ist, abgesehen von Kerberos 5 GSSAPI und SRP.

3.1. Host-Authentifizierung

Es gibt zwei Seiten der Authentifizierung:

  1. Ist der Host, was er zu sein behauptet?
  2. Ist der User, wer er zu sein behauptet?

In seiner einfachsten Form lässt SSH den User verschlüsselte Verbindungen aufbauen, ohne irgendeine Art von Schlüssel oder spezielle Authentifizierungsprozeduren oder -dateien zu benutzen, und alles, was der Hostadministrator tun muss, ist, den SSH-Server zu installieren und Hostkeys zu generieren. Eine Änderung des Host-Login-Systems ist nicht nötig. Dies ist einer der Gründe, warum SSH so beliebt ist, verglichen mit anderen Authentifizierungsmethoden, die sicherer  sind: der Einstieg ist leicht. Jedoch authentifiziert diese Art der SSH-Verbindung nicht den Host zum Client, und es authentifiziert den Client zum Host nur durch eine Passwort-Datei, so wie ein gewöhnliches unsicheres Login. Der einzige Unterschied besteht darin, dass die Sitzung (inklusive Passwort) verschlüsselt wird, was Hackern ein bisschen mehr Arbeit bereitet, bis sie ihre Sniffer-Logs entziffert und dein Passwort haben. Die Annahme besteht darin, dass Hacker sich diese Mühe nicht machen werden, da die unverschlüsselten Passwörter leichter zu stehlen sind (wie Autos ohne Lenkradsperre), aber das ist natürlich Wunschdenken.

Der wichtigste Befehl, den du kennen solltest, ehe du versuchst, eine SSH-Verbindung aufzubauen, ist SET SSH STRICT-HOST-KEY-CHECK. Die Werte sind ON, OFF und ASK.

  • ON bedeutet, dass K95 keine SSH-Verbindung aufbaut zu einem Host, dessen Public-Key nicht in seiner Datei bekannter Hosts ist.
  • OFF bedeutet, dass K95 sich mit jedwedem SSH-Host verbindet.
  • ASK bedeutet, dass K95 fragen wird, ob es okay ist, Verbindung zu einem Host aufzubauen, dessen Key sich nicht in der Datei bekannter Hosts befindet. Dies ist die Standardeinstellung.

Es gibt für jede Protokollversion zwei Dateien bekannter Hosts. Eine Userdatei wird in der Directory \v(appdata)ssh  gespeichert und automatisch geupdated, basierend auf den Verbindungen, die du aufbaust. Die systemweit bekannte Datei bekannter Hosts wird (wahlweise) in der Directory \v(common)ssh  des Betriebssystems gespeichert und von K95 niemals geupdated. Es ist dort, um vom Systemadministrator gepflegt zu werden.

Deine global bekannten Dateien bekannter Hosts werden in einer für alle User gleichen Directory gespeichert:

SSH v1:  \v(common)ssh\known_hosts
SSH v2:  \v(common)ssh\known_hosts2

und deine userspezifischen (und K95-spezifischen) Dateien bekannter Hosts sind:

SSH v1:  \v(appdata)ssh\known_hosts
SSH v2:  \v(appdata)ssh\known_hosts2

(\v(appdata) ist die Variable der Datendirectory der Kermit-Users. Die Applikationsdaten-Directory der Users wird in einer systemabhängigen Art gespeichert. Windows 95/98/98SE/ME/NT speichern die Applikationsdaten mit dem Userprofil. Windwos 2000/XP/Vista etc. speichern die Applikationsdaten in der Directory Documents and Settings . Sag K95: “show var appdata” [zeige var-Appdaten], um die Definiton zu sehen.)

Daher sind bei Windows XP diese Dateien in der SSH-Subdirectory deiner Windows-APPDATA-Directory, zB:

SSH v1:  c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts
SSH v2:  c:\Documents and Settings\username\Application Data\Kermit 95\ssh\known_hosts2

Auf Windows 98 mit Multi-User-Support wäre dies:

SSH v1:  c:\WINDOWS\Profiles\username\Application Data\Kermit 95\ssh\known_hosts
SSH v2:  c:\WINDOWS\Profiles\username\Application Data\Kermit 95\ssh\known_hosts2

Auf Windows 98 ohne Multi-User-Support wäre dies:

SSH v1:  c:\WINDOWS\Application Data\Kermit 95\ssh\known_hosts
SSH v2:  c:\WINDOWS\Application Data\Kermit 95\ssh\known_hosts2

(\v(common) ist die Variable der allgemeinen Datendirectory. Die allgemeine Datendirectory systemabhängig gespeichert. Windows 95/98/98SE/ME/NT speichern die allgemeinen Applikationsdaten in der WINDOWS-Directory. Windows 2000/XP speichern die Applikationsdaten in der Directory Documents and Settings\All Users . Sag K95: “show var common” [zeige var-allgemein], um die Definiton zu sehen.)

Jede Datei beinhaltet eine Reihe (langer) „Zeilen“, eine pro Host, jede Zeile beinhaltet den Hostnamen und Alias, und dann den Key in Base 64; dies ist der Public-Key des Hosts. Einen Host-Key hinzuzufügen bedeutet, eine solche Zeile in der entsprechenden Datei anzuhängen.

SSH STRICT-HOST-KEY-CHECK ON bietet etwas Sicherheit, dass der Host, mit dem du verbunden bist, wirklich der ist, mit dem du verbunden sein wolltest. Es bedeutet aber auch, dass die erste Verbindung, du du mit einem speziellen Host eingehen willst, vermutlich zurückgewisen wird. Das ist die klassische Huhn-und-Ei-Situation. Es wird erwartet, dass du Host-Keys von einer vertrauenswürdigen Quelle wie einer Diskette oder CD-ROM von deinem Host-Administrator bekommst – aber wenn das nicht der Fall ist, wie bekommst du dann einen Key, wenn der sich auf dem Host befindet, mit dem du dich nicht verbinden kannst, weil du keinen Key hast? Du hast folgende Möglichkeiten:

  • Du baust eine andere Art vertrauenswürdiger Verbindung auf, (zB mit Kerberos 5 Telnet) und lädst den Key herunter, oder:
  • du erzählst K95 folgendes::
SET SSH STRICT-HOST-KEY-CHECK OFF (or ASK)

Dann baust du eine SSH-Verbindung auf, authentifizierst mit deinem Passwort, und dann wird der Host-Key automatisch abgefragt und zu deiner Datei bekannter Hosts hinzugefügt. Zukünftige Verbindungen können dann mit SSH STRICT-HOST-KEY-CHECK ON aufgebaut werden. Da du den Host-Authentifizierung-Prozess umgangen hast, um den Key zu bekommen, ist die zukünftige Authentifizierung mit diesem Key nutzlos und du hättest es genauso gut lassen können.

Du wirst dich fragen, ob es eine gute Idee ist, Host-Keys zu behalten. Der Vorteil liegt im Schutz gegen man-in-the-middle-Attacken und DNS-Spoofing, den sie bieten (aber keine kompromittierten Hosts). Der Nachteil besteht darin, dass jeder, der Zugang zu deinen Host-Keys hat (ob erlaubterweise oder nicht), weiß, welche Hosts du besuchst, was an sich schon eine Information ist, die du vermutlich nicht preisgeben möchtest. Dies sagt Hackern aber auch, welche Hosts sie in deinem Namen angreifen können. Wie bereits angemerkt, fügt Kermit 95 (wie jeder andere SSH-Client) neue Host-Keys zu deiner User-Host-Key-Datei hinzu. Du kannst diese Dateien löschen, wenn du willst; das kannst du sogar automatisch in deiner K95 ON_EXIT-Makrodefiniton tun.

3.2. User-Authentifizierung

Unabhängig von der Art, wie der Host sich bei K95 authentifiziert hat, ist die Methode, mit der K95 dich beim Host authentifiziert:

  • Passwort
  • Public/Private Key Pair

Die voreingestellte Methode (bedeutet: die Methode, die benutzt wird, wenn du K95 nicht auf eine der unten beschriebenen Arten eingestellt hast) ist, lokal ein Passwort von dir anzufordern und es dann (verschlüsselt) an den Server zu schicken. Diese Methode bedeutet auch die Eingabe des Passworts jedes einzelne Mal, wenn du dich einloggst (anders als beispielsweise bei Kerberos 5, der einen „single network login“ anbietet).

Wenn du SSH benutzen musst, um einen speziellen Host zu kontaktieren, empfehlen wir die simple Passwort-Authentifizierung. Wenn das für dich okay ist, überspringe den Rest dieses Abschnitts. Wenn nicht, lies weiter.

Du kannst auch öffentliche/private Key-Pairs benutzen, deren Zweck darin besteht, dir zu erlauben, dich beim Host einzuloggen, ohne dein Passwort einzutippen. DIES IST GEFÄHRLICH, weil deine Keys auf deiner Windows-Disc gespeichert werden, von wo sie gestohlen werden können (vor allem von Windows 9x/ME-PCs, die ans Netzwerk angeschlossen sind, aber jede Art von Dateisystem-Sicherheit vermissen lassen). Wenn deine Key-Files verschlüsselt sind, können sie offline entschlüsselt werden. (Je länger die Passphrase für die Key-File-Verschlüsselung ist, desto länger dauert es, Wörterbuch-Attacken gegen sie durchzuführen; als Minimum sollte eine 40stellige Passphrase dienen, aber die meisten Leute benutzen keine so langen, deshalb sind die meisten Key-Files erntereif.)

Um Public/Private-Key-Pairs zu nutzen, brauchst du den Public-Key jedes Host in deinem Pc an folgendem Ort:

\v(APPDATA)\ssh\known_hosts (SSH v1) und/oder \v(APPDATA)\ssh\known_hosts2 Dateien (SSH v2),

und du musst auch deinen eigenen Public-Key zu jedem Host hochladen und ihn in den entsprechenden Ort packen, etwa

as ~/.ssh/authorized_keys (SSH v1) und/oder ~/.ssh/authorized_keys2 (SSH v2) wenn OpenSSH der Daemon ist.

Wenn die richtigen Dateien und Keys im richtigen Format an dden entsprechenden Orten verstaut sind, kannst du dich ohne Passwort einloggen. Um die korrekte Art Key zu bestimmen, den du nutzen musst, musst du die Konfiguration des SSH-Daemons kennen. Wenn du nicht der Hostadministrator bist, kontaktiere den entsprechenden Administrator, um Hilfe zu erhalten. (Ein weitverbreiteter Fehler ist es, die Permissions auf der Directory ~/.ssh/  zu lassen und die Dateien, die sie beinhaltet, welt- oder gruppenzugänglich. Der Daemon von SSH verweigert es, Identity-Dateien zu benutzen, die irgendjemand anderem als dem Account-Eigentümer zugänglich sind.

Hier ist ein Beispiel. Ich habe eine Gast-ID auf einem Linux-Rechner bei einer Remote-Seite. Wenn ich eine SSH-Verbindung zu ihr aufbaue (indem ich per Passwort einlogge), zeigt mir die Statuszeile von K95, dass der Server-Level von SSH bei 2.0 liegt. Wenn ich in der Lage sein möchte, mich zu verbinden, ohne ein Passwort einzugeben, ist (1) eh alles vorbei, da K95 bei der allerersten Verbindung schon den Public-Key des Hosts zu meiner known_hosts2-Datei hinzugefügt hat; doch (2) muss ich den Public-Key meines PCs zu meiner

~/.ssh/authorized_keys2

Datei beim Host hinzufügen. In diesem Fall gab es keine solche Datei. Alles, was ich also tun musste, war meinen Public-Key beim Host hochzuladen, als ~/.ssh/authorized_keys2. Aber welchen Public-Key? Ich habe drei von ihnen (siehe die SSH KEY CREATE-Befehlsbeschreibung unten):

SSH V1 RSA key:  identity.pub
SSH V2 DSA key:  id_dsa.pub
SSH V2 RSA key:  id_rsa.pub

Nun, da der Server SSH v2 benutzt, kann ich die Datei identity.pub ignorieren, die ist nämlich nur für SSH v1. Also begann ich, meine Datei id_dsa.pub zu meiner Directory ~/.ssh hochzuladen, sie in authorized_keys2 umzubenennen, auszuloggen, und eine neue SSH-Verbindung zum selben Host aufzubauen. Der hat mich ohne Passwortabfrage reingelassen, also habe ich gleich beim ersten Mal richtig geraten. Vielleicht hätte der id_rsa.pub – Key auch funktioniert, wer weiß – das hängt vermutlich vom Server ab.

Doch nun kann natürlich jeder, der an eine Kopie der id_dsa Private-Key-Datei von meiner Windows-Disk kommt, sich beim Host unter meinem Namen einloggen – ohne Passwort. Und für denjenigen ist es einfach, diesen Host zu finden, da er in meiner known_hosts2-Datei aufgeführt ist, zusammen mit allen anderen Hosts, bei denen ich mich mit SSH v2 einlogge. Was habe ich also erreicht? Ich hab ziemlich genau die Schlüssel zu allen meinen Häusern auf der Straße liegengelassen, jeder von ihnen sauber beschriftet mit der Adresse des Hauses, die er aufschließt.

Nachdem ich mich nun überzeugt hatte, dass alle Key-Exchange-Mechanismen arbeiten wie vorgesehen (von den SSH-Designern, nicht uns), lösche ich die authorized_keys2-Datei vom Hist und alle Private-Keys von der Windows-Disk. Anders als Kerberos-Identities oder x.509-Zertifikate, können korrumpierte Private-Keys nicht widerrufen oder auch nur aufgespürt werden. Und anders als bei verschlüsselter Passwortauthentifizierung, welche im kurzen Moment des Transits abgefangen werdne muss, sind deine Key-Files für Hacker immer zugänglich, und daher, für eine potentiell unendliche Anzahl von Hackern gleichzeitig.

Beachte nebenbei, dass einige SSH-Hosts keine Public-/Private-Key-Pair-Authentifizierung untestützen, weswegen jede Kombination, die du ausprobierst, nicht funktionieren wird. Es gibt keinen Weg, so etwas zu wissen, ohne dass der Host-Administrator es erzählt oder bis man alle Kombinationen ausgeschöpft hat.

Da Public-/Private-Key-Authentifizierung unsicher ist, unterstützt K95 auch zwei sichere Authentifizierungsmethoden für SSH v2, die keine Public-/Private Key Pairs benötigen:

  • GSSAPI (Generic Security Services Application Programming Interface), welches sich ins Kerberos 5-Authentifizierungssystem hakt.
  • SRP (Secure Remote Password), Stanford University

Natürlich benötigen sichere Authentifizierungen für SSH-Clients modifizierte SSH-Server, die verfügbar sind. GSSAPI benötigt überhaupt keine Host Keys. Die Kerberos-Authentifizierung erfolgt gegenseitig.

Die komplette Liste der SSH v2-Authentifizierungsmethoden von K95 lautet:

external-keyx

Benutze die ausgeführte Authentifizierung als Nebeneffekt eines Key-Exchange-Algorithmus’ wie etwa GSSAPI.

gssapi

Kerberos 5-Identität (benötigt Kerberos 5, auf der Host-Seite installiert, und einen SSH-Server, der deine K5-Identität authentifizieren kann).

hostbased

Wie Rlogin (.rhosts-Datei, nicht sicher)

keyboard-interactive

Kermit fordert lokal Authentifizierungsinformationen bei dir an, wie ein Host-Passwort (oder irgendetwas anderes, das der Host benötigt).

password

Kermit fordert lokal ein Single-Host-Passwort bei dir an.

publickey

Public-/Private-Key-Pair-Exchange (unterstützt, aber nicht empfohlen und nicht unterstützt von den SSH-Servern der Columbia)

srp-gex-sha1

Sicheres Remote-Passwort (SRP, sicher; benötigt einen SSH-Server auf dem Host, der SRP-Authentifizierungen ausführt).

4. Bekannte Bugs

[ Top ] [ Inhalte ] [ Nächste ]

  • Du wirst beinahe immer eine Reihe gruseliger Warnungen erhalten, wenn du versuchst, eine SSH-Verbindung zu einem Host-Pool aufzubauen; das bedeutet, zu einem IP-Hostnamen, der für mehr als einen Server steht, welcher dynamisch ausgesucht wird und durch einen Load-Balancer oder derartiges unsichtbar ist für jede eingehende Verbindung. Dies ergibt sich dadurch, dass der Name des SSH-Hosts nicht derselbe ist, den du dem SSH-Befehl gegeben hast. Wenn du überzeugt bist, den Ort erreicht zu haben, den du erreichen möchtest, kannst du die Warnungen ignorieren. Anderenfalls musst du eine SSH-Verbindung zum spezifischen Hostnamen aufbauen, nicht dem generischen Poolnamen.
  • Das Resultat von „ ssh hostname /command:{any command …}„ könnte gekürzt sein.
  • „sow ssh“ pausiert am Ende jedes Screens nicht, und es zeigt nur SET SSH (oder voreingestellte) Werte, nicht die derzeitigen oder ausgehandelten.
  • Manchmal, wenn du von einem Host ausloggst und K95 zum Kommandobildschirm zurückkehrt, druckt es die „Connection Closed“-Nachricht und die Anfrage in falscher Reihenfolge:
[C:\K95\] K-95> Connection to blah closed.

5. Beachtenswerte Dinge

[ Top ] [ Inhalte ] [ Nächste ]

  • K95 versucht voreingestellt, SSH v2 zu passieren. Wenn du versuchst, dich mit einem SSH v1-Server zu verbinden, könnte das dauern. In diesen Fällen benutzt du am besten „ ssh host /version:1„, um eine sofortige Verbindung zu erhalten.
  • Leitung. Offensichtlich variiert die Leitung mit der Speicherkapazität deines PCs, der CPU-Geschwindigkeit und -ladung, doch der OS an sich ist ebenso ein Faktor. Da der SSH-Code in einem anderen Thread läuft, sind die sich unterscheidenden Thread-Scheduling-Kapazitäten von Win9x/ME gegen NT/2000/XP signifikant; wenn alles andere gleich ist, kannst du die bessere Leistung von Windows NT/2000/XP erwarten.Wenn du die Leitung von Kermit mit anderen SSH-Clients vergleichst, behalte im Hinterkopf, dass Kermit gern eine stärkere und damit CPU-intensivere Verschlüsselungsmethode nimmt als andere Clients, und dass Kermit im Terminal-Window mehr macht: die Emulation vieler Terminal-Typen, Character-Set-Konversion, URL-Highlighting, den Erhalt von Attributen für jede Zelle, True Blinking, Dateitransfer-Initiationserkennung, (Autoup/-Download), Hostinitiiertes Drucken, etc. Die Effekte mögen auf modernen PCs nicht erkennbar sein, doch können sich auf älteren, langsameren bemerkbar machen.
  • Stairsteps. SSH-Server auf einigen Unix-Systemen (meist alte, aber Berichten zufolge auch einige neue) übersetzen LF nicht nach CRLF, deshalb kommen die Zeilen auf deinem Bildschirm als „Stairsteps“ [Treppenstufen] heraus. Normalerweise kannst du das beheben, indem du einen „stty sane“-Befehl an die Unix-Host-Anfrage gibt, oder indem du Kermit den Befehl „set terminal newline on“ gibst. Andere SSH-Clients benehmen sich bei exakt denselben Hosts ganz genau so. Berichten zufolge beseitigen neuere OpenSSH-Server (3.3 oder höher) das Problem.
  • Einige SSH-Server brechen die Verbindung nicht ab, wenn du dich ausloggst. Wenn du dich ausloggst, Kermit aber im Terminal-Screen bleibt, benutze Alt-u, um die Verbindung abzubrechen (dasselbe passiert auch mit anderen SSH-Clients).
  • SSH-Komprimierung ist per Voreinstellung erlaubt. Es verbessert die Leistung auf schnellen Rechnern, kann die Sache aber verlangsamen, wenn das CPU einen Engpass darstellt, besonders bei schnellen LAN-Verbindungen. Komprimierung ist jedoch wichtig für moderne Verbindungen (zB PPP), weil die verschlüsselte Datenstrom nicht vom Modem komprimiert werden kann. Benutze SET SSH COMPRESION OFF, um es auszuschalten.
  • Kerberos-Autoget/Destroy-TGTs.
  • Telnet durch SSH-Port-Weiterleitung
  • Remote SSH-Agent-Proxies.
  • Eingehendes SSH.
  • Integration von HTTP, RDNS, DNS SRV, etc.
  • SHOW SSH zeigt nur Einstellungen, keine Details zur derzeitigen Verbindung.

6. Noch nicht implementiert

[ Top ] [ Inhalte ] [ Nächste ]

  • Kerberos-Autoget/Destroy-TGTs.
  • Telnet durch SSH-Port-Weiterleitung
  • Remote SSH-Agent-Proxies.
  • Eingehendes SSH.
  • Integration von HTTP, RDNS, DNS SRV, etc.
  • SHOW SSH zeigt nur Einstellungen, keine Details zur derzeitigen Verbindung.

7. Neue Befehle für SSH

[ Top ] [ Inhalte ] [ Nächste ]
Abschnittsinhalte:

7.1. Der SSH-Befehl

7.2. Der SET SSH-Befehl

Der Rest dieses Dokuments listet die neuen, SSH-verwandten Befehle von K95. Du findest die meisten dieser Informationen auch mit dem HELP-Befehl (HELP SSH, HELP SET SSH, etc) von K95. Schreibweise:

Fett

Ein Keywort, das wortgetreu eingetippt werden muss. Keywörter können auf jede Länge verkürzt werden, die nicht mit einem anderen Keyword kollidiert, welches am selben Platz erscheinen kann.

Kursiv

Ein Parameter, für den man einen wirklichen Wert einsetzen würde.

{ Ding1, Ding2, … }

Eine kommagetrennte Liste in kursiven Klammern bedeutet eine Wahl; wähle eines der Dinge aus.

[ irgendwas ]

Alles in kursiven Eckklammern ist optional.

Einige dieser Befehle haben Gegenstücke im SSH-Settings-Dialog im neuen Dialer.

7.1. Der SSH-Befehl

Ein ssh-agent.exe-Programm wird in der Programmdirectory von K95 mitgeliefert. Wenn du es ausführst, arbeitet es als SSH-Agent-Programm für andere Applikationen auf deinem PC, wie Kermit 95.

Syntax: SSH { ADD, AGENT, CLEAR, KEY, [ OPEN ], V2 } operands...

Leistet die SSH-bezogene Aktion, die vom Keyword spezifiziert wird.

Sehen wir uns erst einmal die wichtigsten und gebräuchlichsten SSH-Befehle an:

SSH [ OPEN ] host [ port ] [ /COMMAND:command /USER:username /PASSWORD:passwd /VERSION:{1,2} /SUBSYSTEM:name /X11-FORWARDING:{ON,OFF} ]

Dieses Kommando baut eine neue Verbindung auf, indem es das Protokoll der SSH-Version 1 oder 2 benutzt. Die Verbindung zum spezifischen Host wird auf einem SSH-Port hergestellt (du kannst den Port außer Kraft setzen, indem du einen Portnamen oder Portnummer nach dem Hostnamen einfügst). Wenn die Verbindung erst einmal hergestellt ist, beginnen die Authentifizierungsverhandlungen. Wenn die Authentifizierung akzeptiert wird, werden die lokalen und remote Port-Weiterleitungslisten (wenn es welche gibt) benutzt, um die gewünschte Verbindung herzustellen, und wenn X11-Forwarding aktiv ist, resultiert dies in einem Remote-Port-Forwarding zwischen dem X11-Client auf dem Remote-Host und dem X11-Server auf dem lokalen Rechner. Wenn ein /COMMAND geboten wird, wird der Befehl auf dem Remote-Host anstelle deiner Default-Shell durchgeführt.

Annähernde Synonyme: SET HOST /NETWORK:SSH. Dies ist genau wie SSH OPEN, nur dass es nicht den Terminal-Bildschirm betritt (wenn du nicht den /CONNECT-Switch einfügst). Dies erlaubt es SSH-Verbindungen, in Scripts gemacht zu werden, welchen die Interaktionen mit dem Host automatisiert werden. Um zu sehen, wie man einen SSH-basierten Kermit-File-Transfer und -Management-Service aufbaut (ähnlich wie SFTP, aber mit mehr Flexibilität, Funktionalität, Freundlichkeit und Scriptfähigkeit), klick hier.

Wenn dein Username auf dem Host nicht derselbe ist wie in K95s \v(userid)-Wert, musst due den B-Switch einfügen, um den Usernamen auf dem Host zu spezifizieren. Den K95-\(userid)-Wert findest du heraus, indem du SHOW VAR USERID beim K95-Prompt eingibst. Diese Variable kannst du mit dem SET LOGIN USERID global festsetzen, wobei es dann für alle zukünftigen Network.Logins benutzt wird, bis du EXIT von K95 eingibst. Der /USER:-Switch, auf der anderen Seiten, bezieht sich nur auf den Befehl, mit dem er gegeben wird, und rührt das globale USERID-Setting nicht an.

Hier sind die übrigen SSH-Befehle in alphabetischer Reihenfolge:

SSH ADD LOCAL-PORT-FORWARD local-port host port

Fügt ein Port-Forwarding-Triplet zur lokalen Port-Forwarding-Liste hinzu. Das Triplet spezifiziert einen lokalen Port, der weitergeleitet wird, und den Hostnamen/IP-Adresse und Portnummer, zu denen der Port vom Remote-Host aus weitergeleitet wird. Das Port-Forwarding ist bei Verbindungsaufbau aktiviert und bleibt dies, bis die Verbindung gelöst wird.

SSH ADD REMOTE-PORT-FORWARD remote-port host port

Fügt ein Port-Forwarding-Triplet zur Remote-Port-Forwarding-Liste hinzu. Das Triplet spezifiziert einen Remote-Port, der weitergeleitet und den Hostnamen/IP-Adresse und Portnummer, zu denen der Port vom lokalen Rechner aus weitergeleitet wird. Das Port-Forwarding ist bei Verbindungsaufbau aktiviert und bleibt dies, bis die Verbindung gelöst wird.

SSH AGENT ADD [ identity-file ]

Fügt den Inhalt der Identity-Datei (falls es sie gibt) zum SSH AGENT-Private-Key-Cache hinzu. Wenn keine Identity-File spezifiziert wurde, werden alle mit SET SSH IDENTITY-FILE spezifizierten Dateien zum Cache hinzugefügt.

SSH AGENT DELETE [ identity-file ]

Deletes the contents of the identity-file (if any) from the SSH AGENT private key cache. If no identity-file is specified, all files specified with SET SSH IDENTITY-FILE are deleted from the cache.

Löscht den Inhalt der Identity-Datei (falls es sie gibt) vom SSH AGENT-Private-Key-Cache. Wenn keine Identity-File spezifiziert wurde, werden alle mit SET SSH IDENTITY-FILE spezifizierten Dateien vom Cache gelöscht.

SSH AGENT LIST [ /FINGERPRINT ]

Listet den Inhalt des SSH AGENT Private-Key-Cache auf. Wenn /FINGERPRINT spezifiziert ist, wird der Fingerabdruck der Private-Keys anstelle der Keys dargestellt.

SSH CLEAR LOCAL-PORT-FORWARD

Säubert die Local-Port-Forwarding -List.

SSH CLEAR REMOTE-PORT-FORWARD

Säubert die Remote-Port-Forwarding-List.

SSH KEY Commands:

Die SSH KEY-Befehle erstellen und managen Public- und Private-Key-Pairs (Identities). Es gibt drei Arten von SSH-Keys. Jeder Key wird in seiner eigenen Datei gespeichert:

Key Type Private Key File Public Key File
v1 RSA keys \v(appdata)ssh/identity \v(appdata)ssh/identity.pub
v2 RSA keys \v(appdata)ssh/id_rsa \v(appdata)ssh/id_rsa.pub
v2 DSA keys \v(appdata)ssh/id_dsa \v(appdata)ssh/id_dsa.pub

Keys werden mithilfe des OpenSSH-Keyfile-Formates gespeichert. Die privaten Keyfiles können (wahlweise) durch eine Passphrase geschützt werden. Eine Passphrase ist die längere Version eines Passwortes. Englischer Text bietet nicht mehr als 2 Bits Keydaten pro Buchstabe. 56-Bit-Keys können durch eine Brute-Force-Attacke in schätzungsweise 24 Stunden geknackt werden. Wenn Private-Key-Dateien benutzt werden, sollten sie deshalb durch eine Passphrase von mindestens 40 Zeichen (etwa 80 Bits) geschützt werden.

SSH KEY CHANGE-PASSPHRASE [ /NEW-PASSPHRASE:passphrase OLD-PASSPHRASE:passphrase ] filename

Dies wiederverschlüsselt die spezifizierten Private-Key-Dateien mit einer neuen Passphrase. Die alte Passphrase wird benötigt. Wenn die Passphrase (und der Dateiname) nicht geboten werden, fragt Kermit dich nach ihnen.

SSH KEY CREATE [ /BITS:bits /PASSPHRASE:passphrase /TYPE:{V1-RSA,V2-DSA,V2-RSA} /V1-RSA-COMMENT:comment ] filename

Dieses Kommando erstellt ein neues Private/Public-Key-Pair. Die Voreinstellungen sind: BITS:1024 und TYPE:V2-RSA. Der Dateiname ist der Name der Private-Key-Datei. Der Public-Key wird unter demselben Namen erstellt, mit angehängtem .pub. Wenn ein Dateiname nicht spezifiziert ist, fordert Kermit ihn von dir an. V1 RSA-Keyfiles können einen optionalen Comment besitzen, der bei anderen Keytypen ignoriert wird.

SSH KEY DISPLAY [ /FORMAT:{FINGERPRINT,IETF,OPENSSH,SSH.COM} ] filename

Dieser Befehl zeigt den Inhalt einer Public- oder Private-Key-Datei. Das voreingestellte Format ist OPENSSH.

SSH KEY V1 SET-COMMENT filename comment

Dieser Befehl ersetzt den Comment, der mit einem V1 RSA-Keyfile verbunden ist.

SSH V2 REKEY

Ersucht eine existierende SSH V2-Verbindung um die Generierung neuer Session-Keys.

7.2. Der SET SSH-Command

SET SSH AGENT-FORWARDING { ON, OFF }

Wenn ein Authentifizierungs-Agent benutzt wird, resultiert das Festsetzen dieses Wertes auf ON in der Verbindung zum Agent, der zum Remote-Computer weitergeleitet wird. Der Standard ist OFF.

SET SSH CHECK-HOST-IP { ON, OFF }

Spezifiziert, ob die IP-Adresse eine Remote-Hosts gegen den entsprechenden Hostkey in der known_hosts-Datei abgecheckt werden soll. Dies kann benutzt werden, um festzustellen, ob der Host-Key als Ergebnis von DNS-Spoofing geändert wurde. Der Standard ist ON.

SET SSH COMPRESSION { ON, OFF }

Spezifiziert, ob Komprimierung genutzt werden wird. Die Voreinstellung ist ON.

SET SSH DYNAMIC-FORWARDING { ON, OFF }

Spezifiziert, ob Kermit als SOCKS4-Service auf Port 1080 arbeiten soll, wenn es via SSH mit einem Remote-Host verbunden ist. Wenn Kermit als SOCKS4-Service arbeitet, akzeptiert es Verbindungsanfragen und leitet die Verbindung durch den >Remote-Host weiter. Die Voreinstellung ist OFF.

SET SSH GATEWAY-PORTS { ON, OFF }

Spezifiziert, ob Kermit als Gateway für weitergeleitete Verbindungen dienen soll, die vom Remote-Host empfangen werden. Der Standard ist OFF.

SET SSH GSSAPI DELEGATE-CREDENTIALS { ON, OFF }

Spezifiziert, ob Kermit GSSAPI-Credentials nach der Authentifizierung an den Remote-Host delegieren soll. Berechtigungsnachweise zu delegieren, erlaubt es dem Credential, vom Remote-Host benutzt zu werden. Die Standardeinstellung ist OFF.

SET SSH IDENTITY-FILE filename [ filename [ ... ] ]

Spezifiziert eine oder mehrere Dateien, von denen die Authentifizierungs-Identities (Private-Keys) des Users abgelesen werden, wenn Public-Key-Authentifizierung benutzt wird. Es sind Dateien, die zusätzlich zu den voreingestellten benutzt werden:

V1 RSA:  \v(appdata)ssh/identity

V2 RSA:  \v(appdata)ssh/id_rsa

V2 DSA:  \v(appdata)ssh/id_dsa

SET SSH KERBEROS4 TGT-PASSING { ON, OFF }

Spezifiziert, ob Kermit die Kerberos 4 TGTs zum Host weiterleiten soll. Die Standardeinstellung ist OFF.

SET SSH KERBEROS5 TGT-PASSING { ON, OFF }

Spezifiziert, ob Kermit die Kerberos 5 TGTs zum Host weiterleiten soll. Die Standardeinstellung ist OFF.

SET SSH PRIVILEGED-PORT { ON, OFF }

Spezifiziert, ob ein privilegierter Host (weniger als 1024) genutzt werden soll, wenn mit dem Host verbunden wird. Privileged-Ports werden nicht benötigt, außer, wenn SSH v1 mit Rhosts- oder RhostsRSA-Authentifizierung benutzt wird. Die Standardeinstellung ist OFF.

SET SSH QUIET { ON, OFF }

Spezifiziert, ob alle Nachrichten, die in Verbindung mit SSH-Protokollen generiert werden, unterdrückt werden sollen. Die Standardeinstellung ist OFF.

SET SSH STRICT-HOST-KEY-CHECK { ASK, ON, OFF }

Spezifiziert, wie Kermit sich verhalten soll, wenn der Host-Key-Check fehlschlägt. Wenn strenges Host-Key-Checking OFF ist,, wird der neue Host-Key zur protokollversionspezifischen userbekannten Hosts-Datei hinzugefügt. Wenn strenges Host-Key-Checking ON ist, wird der neue Host-Key zurückgewiesen und die Verbindung fallengelassen. Wenn es auf ASK eingestellt ist, fordert Kermit dich auf, anzugeben, ob der neue Host-Key akzeptiert werden soll. Die Standardeinstellung ist ASK. Strenges Host-Key-Checking schützt dich vor Trojanern. Es liegt an dir, den Inhalt der Known-Hosts-Datei mit den derzeitigen Host-Keys zu pflegen.

SET SSH USE-OPENSSH-CONFIG { ON, OFF }

Spezifiziert, ob Kermit eine OpenSSH-Konfigurationsdatei parsen soll, nachdem Kermits SET SSH-Befehle angewendte wurden. Die Konfigurationsdatei wäre platziert in \v(appdata)ssh/ssh_config. Die Standardeinstellung ist OFF.

SET SSH V1 CIPHER { 3DES, BLOWFISH, DES }

Spezifiziert, welche Chiffre genutzt werden soll, um SSH v1-Verbindungen zu schützen. Die Standardeinstellung ist 3DES.

SET SSH V1 GLOBAL-KNOWN-HOSTS-FILE filename

Spezifiziert den Ort der systemweiten known-Hosts-Datei. Der voreingestellte Ort hängt vom Betriebssystem ab:

Operating System File
Windows 95/98/98SE/ME %windir%\ssh_known_hosts
Windows NT/2000/XP/Vista/7/etc \v(common)ssh\ssh_known_hosts

SET SSH V1 USER-KNOWN-HOSTS-FILE filename

Spezifiziert den Ort der Userbekannten Hosts-Datei. Der voreingestellte Ort ist:

\v(appdata)ssh/known_hosts

SET SSH V2 AUTHENTICATION { EXTERNAL-KEYX, GSSAPI, HOSTBASED, KEYBOARD-INTERACTIVE, PASSWORD, PUBKEY, SRP-GEX-SHA1 } [ ... ]

Spezifiziert eine bestellte Liste von SSH v2-Authentifizierungsmethoden, die genutzt werden, wenn mit dem Remote-Host verbunden wird. Die voreingestellte Liste ist:

external-keyx gssapi hostbased publickey srp-gex-sha1

keyboard-interactive password none

SET SSH V2 CIPHERS { 3DES-CBC, AES128-CBC, AES192-CBC, AES256-CBC, ARCFOUR, BLOWFISH-CBC, CAST128-CBC, RIJNDAEL128-CBC, RIJNDAEL192-CBC, RIJNDAEL256-CBC }

Spezifiziert eine bestellte Liste von SSH-Versions-Chiffren, die genutzt werden, um die aufgebaute Verbindung zu verschlüsseln. „Rijndael“ ist ein Alias für „aes“. Die voreingestellte Liste ist:

aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour aes192-cbc aes256-cbc

SET SSH V2 GLOBAL-KNOWN-HOSTS-FILE filename

Spezifiziert den Ort der systemweiten Known-Hosts-Datei. Der voreingestellte Ort hängt vom Betriebssystem ab:

Windows 95/98/98SE/ME: %windir%\ssh_known_hostss

Windows NT/2000/XP:    \v(common)ssh\ssh_known_hosts2

SET SSH V2 HOSTKEY-ALGORITHMS { SSH-DSA, SSH-RSA }

Spezifiziert eine bestellte Liste von Host-Key-Algorithmen, die benutzt werden, um die Identität des Hosts zu verifizieren. Die voreingestellte Liste ist:

ssh-rsa ssh-dsa

SET SSH V2 MACS { HMAC-MD5 HMAC-MD5-96 HMAC-RIPEMD160 HMAC-SHA1 HMAC-SHA1-96 }

Spezifiziert eine bestellte Liste von Nachrichten-Authentifizierungscode-Algorithmen, die für den Integritätsschutz der aufgebauten Verbindung benutzt werden. Die voreingestellte Liste ist:

hmac-md5 hmac-sha1 hmac-ripemd160 hmac-sha1-96 hmac-md5-96

SET SSH V2 USER-KNOWN-HOSTS-FILE filename

Spezifiziert den Ort der userbekannten Known-Hosts-Datei. Der voreingestellte Ort ist:

\v(appdata)ssh/known_hosts2

SET SSH VERBOSE level

Spezifiziert, wie viele Nachrichten von der OpenSSH-Engine generiert werden sollten. Der Level kann von 0 bis 7 gehen. Der Standardwert ist 2.

SET SSH VERSION { 1, 2, AUTOMATIC }

Spezifiziert, welche SSH-Version benutzt werden soll. Die Standardeinstellung ist AUTOMATIC, was bedeutet, dass die Nutzung von Version 2 unterstützt wird; anderenfalls wird auf Version 1 zurückgegriffen.

SET SSH X11-FORWARDING { ON, OFF }

Spezifiziert, ob X Windows-Systemdaten über die aufgebaute SSH-Verbindung weitergeleitet werden. Die Standardeinstellung ist OFF. Wenn sie ON ist, wird der DISPLAY-Wert eintweder festgesetzt, indem der SET TELNET ENV DISPLAY-Befehl genutzt wird, oder indem er von der DISPLAY-Umgebungsvariablen gelesen wird.

SET SSH XAUTH-LOCATION filename

Spezifiziert den Ort der xauth-Executable (wenn mit der X11-Server-Software bereitgestellt).ъ


K95 SSH Client / The Kermit Project / Columbia University / kermit@columbia.edu / 8 Dec 2002 / 25 Aug 2010