Secure Shell (SSH)

Gesicherte Kommunikation über unsichere Netze

Index

SSH im Überblick

Hinweis: Neben den nichtkommerziellen SSH-Versionen gibt es auch kommerzielle Versionen. Die bereits erwähnte finnische Firma Data Fellows hat die exklusiven Rechte zur Vergabe von Lizenzen für die kommerziellen SSH-Produkte.

Die nachfolgenden Darstellungen beziehen sich auf die nichtkommerziellen Versionen 1.2.x (die unter Beachtung der NON-COMMERCIAL LICENSE konstenfrei beschafft und genutzt werden können) sowie die von diesen Implementierungen realisierte Version 1.x des SSH-Protokolls.

Interessante Eigenschaften

Die folgende Liste nennt einige interessante Eigenschaften der Secure Shell:
  • Jeder Nutzer kann eine beliebige Anzahl von RSA-Schlüsseln zu seiner eigenen Identifikation verwalten und verwenden. Zu deren bequemer Handhabung steht der SSH-Agent zur Verfügung.

    •  

     

    Kommando-Übersicht

    Zur SSH-Distribution gehören folgende Kommandos: Anmerkung:
    SSH nutzt gegenwärtig zur Schlüsselverteilung keine Verzeichnissysteme (Directories) wie z.B. X.500 und keine Zertifikate. Die RSA-Keys der Nutzer und Server-Rechner werden in Dateien des Dateisystems gehalten und durch die mitgelieferten Werkzeuge bzw. mit Hilfe eines gewöhnlichen ASCII-Editors (Vi, Emacs, ...) gepflegt. Es ist möglich, beim ersten Kontakt zu einem unbekannten Server dessen Host-Key automatisch zu "lernen". In diesem Fall trägt der SSH-Klient diesen Schlüssel in die lokale Schlüssel-Datenbasis ein.

    In den vom 6. August 1998 datierten Internet-Drafts (z.B. http://www.ssh.fi/drafts/) für die Version 2.0 des SSH-Protokolls sind verschiedene Formate für öffentliche Schlüssel und/oder Zertifikate vorgesehen, deren Unterstützung obligatorisch, empfohlen oder optional ist:

     
    DSS, der Digital Signature Standard der US-Regierung 
    [http://csrc.nist.gov/fips/fips186.ps]    		 obligatorisch
    X.509-Zertifikate, konkret Version 3 (X.509v3) empfohlen
    SPKI-Zertifikate optional
    OpenPGP-Zertifikate optional

    Prinzipieller Ablauf beim Login

    Das Login auf einem Server läuft gemäß SSH-Protokoll 1.x prinzipiell so ab: Hinweis: Die Umleitung der X11-Verbindungen funktioniert nur, wenn die von SSH eingestellte DISPLAY-Variable vom Nutzer nicht nachträglich verändert wird. Der SSH-Dämon muß den X11-Applikationen als lokaler X11-Server erscheinen, deshalb ist eine entsprechende Einstellung von DISPLAY erforderlich.

    Gegenseitige Authentifizierung der Partner

    Der Server weist seine Authentizität implizit nach. Letztlich kann er nur bei Kenntnis der privaten Keys dH und dS den vom Klienten generierten und verschlüsselten Sitzungsschlüssel ermitteln. Gelingt ihm das nicht, endet die Kommunikation, da er dann die Pakete des Binärprotokolls weder entschlüsseln noch korrekt erzeugen kann.

    Unerläßliche Voraussetzung für die Sicherheit dieses Verfahrens ist, daß der Klient überprüfen kann und überprüft, ob der öffentliche Host-Key des Servers wirklich diesem zugeordnet ist. Ein beliebiges Schlüsselpaar kann jeder, auch ein potentieller Angreifer, ohne Probleme generieren und in den Authentifizierungsdialog einbringen.

    Die Zusammengehörigkeit von Server und öffentlichem Host-Key wird an Hand der Einträge in entsprechenden Administrationsdateien überprüft.

    Verfahren zur Authentifizierung des Klienten

    Die Secure Shell unterstützt in der Grundversion die vier nachfolgend genannten Verfahren zur Authentifizierung des Klienten, wobei die Nutzung der einzelnen Verfahren durch Kommandozeilen-Optionen bzw. Einträge in den Konfigurationsdateien gezielt zugelassen bzw. unterdrückt werden kann. Die in einer konkreten Konstellation verfügbaren Verfahren werden nacheinander bis zum ersten Erfolg oder bis zum definitiven Mißerfolg versucht:
    1. Rhosts-Authentifizierung

      2.  

       

      Dieses Verfahren entspricht der Authentifizierung bei rlogin und rsh. Es basiert auf den Einträgen in den Dateien /etc/hosts.equiv oder /etc/shosts.equiv bzw. $HOME/.rhosts oder $HOME/.shosts.

      Warnung: Diese Methode ist absolut unsicher und wird daher sinnvollerweise vom Server in der Regel nicht unterstützt!!

    2. Rhosts-RSA-Authentifizierung

      3.  

       

      Hierbei handelt es sich um eine Kombination der Rhosts-Authentifizierung (Verfahren 1) mit einer RSA-basierten Authentifizierung des Klienten-Rechners. Die bekannten öffentlichen Schlüssel der Klienten werden beim Server in den Dateien $HOME/.ssh/known_hosts und /etc/ssh_known_hosts gespeichert. Der Klient muß in einem Challenge-Response-Dialog nachweisen, daß er den zugehörigen privaten Schlüssel kennt.

      Der private Schlüssel eines Hosts (Rechners) wird im File /etc/ssh_host_key gespeichert. Dieses File darf nur für den Superuser root lesbar sein!

    3. reine RSA-Authentifizierung

      4.  

       

      Sie stellt die flexibelste und potentiell sicherste Methode dar. Hierbei weist der Nutzer die Kenntnis seines privaten Schlüssels und damit seiner Identität über ein Challenge-Response-Verfahren nach, das sich unter Verwendung des SSH-Agenten automatisch abwickeln läßt.

      Die zur Authentifizierung nutzbaren öffentlichen Schlüssel stehen auf dem Server im File $HOME/.ssh/authorized_keys. Das Schlüsselpaar des Nutzers wird beim Klienten in einer Datei, standardmäßig in $HOME/.ssh/identity, gespeichert.

    4. Paßwort-Authentifizierung

      5.  

       

      Die Authentifizierung erfolgt durch Angabe eines Nutzerpaßworts, wobei dieses immer verschlüsselt übertragen wird.

      Im Standardfall handelt es sich dabei um das normale UNIX-Paßwort. Allerdings lassen sich auch andere Paßwörter nutzen, z.B. von AFS bzw. Kerberos oder von den SecurID-Karten der Firma Security Dynamics [http://www.securitydynamics.com]. Mitunter sind dafür spezielle Patches erforderlich.

    Je nach Installation können weitere Authentifizierungsverfahren zur Verfügung stehen. So enthalten z.B. die Quellen der SSH 1.2.27 eine optionale Unterstützung des zum TIS Internet Firewall Toolkit [http://www.tis.com/research/software/fwtk/] gehörenden Authentifizierungs-Servers sowie von Kerberos-Tickets. Standardmäßig wird Kerberos Version 5 verwendet. Mit entsprechenden Patches läßt sich aber auch die beispielsweise bei AFS eingesetzte Version 4 von Kerberos nutzen.

    Beispielsitzung

    Die nachfolgenden Ausschnitte aus einer realen Sitzung des Nutzers hot sollen zeigen, welche Schritte von einem normalen Anwender unternommen werden müssen, um mit der SSH unter Verwendung der reinen RSA-Authentifizierung (Verfahren 3) ein erstes erfolgreiches Login zu realisieren. Es wird dabei von der Annahme ausgegangen, daß der Nutzer maximale Sicherheit und Flexibiltät wünscht und sich daher nur auf seine eigenen RSA-Keys verläßt.

    Im Beispiel sitzt Nutzer hot am Rechner kirke und will sich auf Rechner sisyphus.hrz anmelden.

    Um sich selbst mit Hilfe von RSA-Keys authentifizieren zu können, muß sich der Nutzer mindestens ein solches Schlüsselpaar erzeugen. Dazu dient das Programm ssh-keygen: 

    hot@kirke 8 > ssh-keygen 
Initializing random number generator...
Generating p:  ..........................................++ (distance 734)
Generating q:  ...++ (distance 48)
Computing the keys...
Testing the keys...
Key generation complete.
Enter file in which to save the key (/home/hot/.ssh/identity): 
Enter passphrase: 
Enter the same passphrase again: 
Your identification has been saved in /home/hot/.ssh/identity.
Your public key is:
1024 37 16859638557607674292986699368320095767875909797393325534467993118889
8248355555842589544029851114499535066615194649319583696257760306546230720850
5511775977979037973020626780660559112158077971574041530476930932301911603728
8384562010283474570023156169635886609631715470531463357831759704636209077472
3735493413371 hot@kirke
Your public key has been saved in /home/hot/.ssh/identity.pub
    Der Private Key wurde zur Sicherheit mit einer nur dem Nutzer bekannten Passphrase verschlüsselt.

    Der Public Key ist auf einem sicheren Weg auf den Server zu bringen, um denjenigen Klienten den Zugang zu erlauben, die im Besitz des zugehörigen Private Keys sind. Es genügt, den Inhalt der gerade generierten Datei $HOME/.ssh/identity.pub als eine weitere Zeile in die Datei $HOME/.ssh/authorized_keys auf dem Server einzutragen.

    Um sicherzustellen, daß der Klient auch wirklich mit dem richtigen Server kommuniziert, muß dem Klienten der Public Key des Servers bekanntgemacht werden. Sofern dieser Schlüssel noch nicht vom Administrator in die Datei /etc/ssh_known_hosts aufgenommen wurde, muß ihn der Anwender in die Datei $HOME/.ssh/known_hosts eintragen.

    Dazu ist dieser Datei eine neue Zeile hinzuzufügen, die hinter dem Hostnamen des Servers dessen Public Key enthält. Dieser Public Key kann in der Regel direkt der auf der Server-Maschine befindlichen Datei /etc/ssh_host_key.pub entnommen werden, da die externen Schlüsselformate übereinstimmen. Das Voranstellen des Server-Namens gestattet dem Klienten die Zuordnung der Keys zu den verschiedenen Servern. Der sichere Transport der Schlüssel obliegt dem Anwender.

    Hinweis: Die Datei /uni/global/text/ssh_known_hosts enthält eine Sammlung der Public Keys verschiedener Maschinen, u.a. der öffentlichen Server des URZ.

    Die Liste der bekannten Hosts sieht nach dem Eintrag des Schlüssels von sisyphus.hrz z.B. so aus: 

    sisyphus.hrz 1024 35 1037672791507197971938948745194100693185694454963168871
3556827896678605792767417152408598699835899502502833314458715509190444018350
9232949190834716492500158729148375969077951642992724314261111314438986691881
6150558438630930840117849687124516919057970663026120425900174307027554281688
80318691535204077340995723
    Hinweis: Will der Nutzer generell sicherstellen, daß immer nur vorab eingetragene Server akzeptiert werden, so muß er in der Konfigurationsdatei des Klienten ($HOME/.ssh/config) die Option StrictHostKeyChecking einschalten. Damit wird verhindert, daß der Klient neue Keys von bisher unbekannten Servern einfach "lernt", also ohne Prüfung einträgt.

    Anmerkung: Ab der Version 1.2.20 sind bei StrictHostKeyChecking drei Werte zulässig: yes, no und ask. Im Standardfall wird ask verwendet, d.h., vor dem Lernen eines neuen Keys wird das Einverständnis des Nutzers eingeholt.

    Damit sind alle notwendigen Vorbereitungen für ein gesichertes Login getroffen. Zur Demonstration wird ssh mit der Option -v gestartet, um den gesamten Authentifizierungsdialog am Bildschirm verfolgen zu können. Bei der normalen Arbeit wird man auf die Option -v in der Regel verzichten. 

    SSH Version 1.2.26-afs_pl1 [i686-unknown-linux], protocol version 1.5.
Standard version.  Does not use RSAREF.
kirke: Reading configuration data /home/hot/.ssh/config
kirke: Reading configuration data /etc/ssh_config
kirke: ssh_connect: getuid 324 geteuid 0 anon 1
kirke: Connecting to sisyphus.hrz [134.109.132.18] port 22.
kirke: Connection established.
kirke: Remote protocol version 1.5, remote software version 1.2.26-afs_pl1
kirke: Waiting for server public key.
kirke: Received server public key (768 bits) and host key (1024 bits).
kirke: Host 'sisyphus.hrz' is known and matches the host key.
kirke: Initializing random; seed file /home/hot/.ssh/random_seed
kirke: Encryption type: 3des
kirke: Sent encrypted session key.
kirke: Installing crc compensation attack detector.
kirke: Received encrypted confirmation.
kirke: ClearToken info:
kirke:    BeginTimestamp: 906443693 (Tue Sep 22 07:54:53 1998)
kirke:    EndTimestamp: 906535274 (Wed Sep 23 09:21:14 1998)
kirke:    calculated lifetime: 91581 (25.4392 hours)
kirke: credentials: lifetime=141, issue_date=906443693
kirke: credentials: endTime calculated by krb_life_to_time(906443693,141)=906535274
kirke: Remote: extracted endTime of credentials=906535274
kirke: Remote: lifetime of credentials calculated by krb_time_to_life(906443693,906535274)=141
kirke: Remote: AFS token accepted (afs@tu-chemnitz.de, AFS ID 4324@tu-chemnitz.de)
kirke: No agent.
kirke: Trying RSA authentication with key 'hot@kirke'
kirke: Received RSA challenge from server.
Enter passphrase for RSA key 'hot@kirke': 
kirke: Sending response to host key RSA challenge.
kirke: Remote: RSA authentication accepted.
kirke: RSA authentication accepted by server.
kirke: Requesting pty.
kirke: Requesting X11 forwarding with authentication spoofing.
kirke: Requesting shell.
kirke: Entering interactive session.
Last login: Tue Sep 22 11:35:00 1998 from 134.109.192.39
Sun Microsystems Inc.   SunOS 5.5.1     Generic Jan 1997
================================================================
Terminal type ?(xterm):
hot@sisyphus 1 > tokens

Tokens held by the Cache Manager:

User's (AFS ID 4324) tokens for afs@tu-chemnitz.de [Expires Sep 23 09:21]
   --End of list--
hot@sisyphus 2 > exit
logout
Connection to sisyphus.hrz closed.
kirke: Transferred: stdin 13, stdout 546, stderr 36 bytes in 8.2 seconds
kirke: Bytes per second: stdin 1.6, stdout 66.5, stderr 4.4
kirke: Exit status 0
    Anmerkung: Die im Beispiel gezeigte und bereits vor der Authentifizierung des Klienten erfolgte Weiterleitung des AFS-Tokens (die betreffenden Teile sind oben rot und kursiv geschrieben) ist nur dann möglich, wenn sowohl in den SSH-Klienten als auch in den SSH-Server die von Dug Song bereitgestellten Patches zur Unterstützung von AFS und Kerberos v4 integriert wurden.

    Die oben blau gefärbten Ausschriften dokumentieren die zur Authentifizierung des Klienten unternommenen Schritte. Wir erkennen, daß vom Klienten weder eine Rhosts- noch eine Rhosts-RSA-Authentifizierung versucht, sondern sofort mit der von uns gewünschten reinen RSA-Authentifizierung begonnen wurde. Dies kann an entsprechenden Einträgen in den Konfigurationsdateien sowie im Falle der Rhosts-RSA-Authentifizierung auch daran liegen, daß beim Klienten kein Host-Key zur Verfügung steht.

    Die reine RSA-Authentifizierung verläuft erwartungsgemäß erfolgreich. Da kein SSH-Agent verwendet wird und der Private Key des Klienten durch eine Passphrase geschützt ist, muß diese eingegeben werden, um die Challenge des Servers mit einer korrekten Response beantworten zu können.

    Mit Hilfe des SSH-Agenten kann man den oben dargestellten Ablauf beim Login komfortabler gestalten. Sofern der SSH-Klient Zugriff auf einen Agenten hat, probiert er im Rahmen der reinen RSA-Authentifizierung zuerst alle im Agenten gespeicherten privaten RSA-Schlüssel, wozu er keine Passphrase benötigt. Erst wenn mit diesen Schlüsseln kein Login gelingt, wird wie oben auf eine Schlüsseldatei zurückgegriffen. Indem man also vorab alle relevanten Schlüsselpaare (meist handelt es sich nur um genau eines) unter Angabe der jeweiligen Passphrase in den Agenten lädt, kann man sich spätere wiederholte Eingaben einer Passphrase ersparen.

    Der SSH-Agent kann auf zwei unterschiedliche Arten gestartet werden:

    1. mit einem Kommando als Argument oder
    2. ohne Angabe eines Kommandos.
    Im ersten Fall wird das angegebene Kommando in einem Kind-Prozeß des Agenten ausgeführt, so daß es selbst sowie alle seine Kinder die Verbindung zum Agenten erben. Sehr häufig wird als Kommando eine Shell angegeben, wie das folgende Beispiel zeigt: 
      ssh-agent tcsh
    Die Kommunikation mit dem Agenten erfolgt in den neueren SSH-Versionen über einen dem Eigentümer des Agenten-Prozesses gehörenden Unix-Domain-Socket, dessen Namen die Kind-Prozesse über eine vom Agenten erzeugte Umgebungsvariable erfahren. Ab SSH 1.2.22 heißt sie SSH_AUTH_SOCK und kann z.B. folgendermaßen aussehen: 
      SSH_AUTH_SOCK=/tmp/ssh-hot/agent-socket-10095
    Frühere SSH-Versionen verwendeten die Variable SSH_AUTHENTICATION_SOCKET.

    Im zweiten Fall, der erst in neueren SSH-Versionen zur Verfügung steht, wird der Agent als Hintergrundprozeß gestartet. Um mit ihm kommunizieren zu können, benötigt man natürlich wieder den Namen des Sockets, der in der bereits erwähnten Umgebungsvariablen abzulegen ist. Dies erreicht man sehr einfach dadurch, daß man den Agenten mittels des Shell-Kommandos

      eval `ssh-agent`

    startet, das sofort die vom Agenten auf die Standardausgabe ausgegebenen Kommandos ausführt, die eine korrekte Einstellung der Umgebung vornehmen. Hier ein Beispiel für die vom Agenten generierten Kommandos bei Verwendung der tcsh: 

      setenv SSH_AUTH_SOCK /tmp/ssh-hot/agent-socket-10781;
  setenv SSH_AGENT_PID 10782;
  echo Agent pid 10782;
    Wirklich benötigt wird nur die erste Zeile. Die restlichen zwei dienen der Information des Nutzers über die Prozeßnummer des Agenten, die z.B. dann von Interesse sein kann, wenn man den Agenten später wieder beenden möchte.

    Im Normalfall erkennt der Agent an Hand der Umgebungsvariablen SHELL automatisch, welche Art von Kommandos (Bourne- oder C-Shell) für die vom Nutzer verwendete Shell benötigt werden, um die Umgebung korrekt einzustellen. Man kann diese Entscheidung durch eine Option auf der Kommandozeile auch selbst treffen:

    ssh-agent -c wählt Kommandos im Stil der C-Shell
    ssh-agent -s wählt Kommandos im Stil der Bourne-Shell

    Sobald ein Agent verfügbar ist, kann man mit 

      ssh-add
    das in der Datei $HOME/.ssh/identity gespeicherte RSA-Schlüsselpaar in den Agenten laden. Der Ablauf sieht in etwa so aus: 
    hot@kirke 62 > ssh-add
Need passphrase for /home/hot/.ssh/identity (hot@kirke).
Enter passphrase: 
Identity added: /home/hot/.ssh/identity (hot@kirke)
    Falls andere Schlüsseldateien verwendet werden sollen, so sind deren Namen als Argumente von ssh-add anzugeben.

    Mit ssh -l kann man sich die öffentlichen Schlüssel der im Agenten registrierten RSA-Schlüsselpaare anzeigen lassen: 

    hot@kirke 63 > ssh-add -l
1024 37 16859638557607674292986699368320095767875909797393325534467993118889
8248355555842589544029851114499535066615194649319583696257760306546230720850
5511775977979037973020626780660559112158077971574041530476930932301911603728
8384562010283474570023156169635886609631715470531463357831759704636209077472
3735493413371 hot@kirke
    Sofern man nachfolgend das oben gezeigte Login auf sysiphus.hrz wiederholt, nimmt der Anmeldedialog nach der Entgegennahme des AFS-Tokens folgende Gestalt an: 
    ...
kirke: Remote: AFS token accepted (afs@tu-chemnitz.de, AFS ID 4324@tu-chemnitz.de)
kirke: Connection to authentication agent opened.
kirke: Trying RSA authentication via agent with 'hot@kirke'
kirke: Received RSA challenge from server.
kirke: Sending response to RSA challenge.
kirke: Remote: RSA authentication accepted.
kirke: RSA authentication accepted by server.
kirke: Requesting pty.
...
    Die beiden folgenden Tabellen fassen die typischerweise an der Authentifizierung beteiligten Dateien zusammen: Hinweis:

    Bis auf $HOME/.ssh/authorized_keys und ggf. $HOME/.ssh/identity.pub sollten die Dateien des Verzeichnisses $HOME/.ssh im Normalfall lediglich für ihren Eigentümer lesbar sein. Nutzer, deren Homeverzeichnis im AFS liegt, müssen beachten, daß sich die AFS-ACLs immer auf Verzeichnisse und nie auf einzelne Dateien beziehen. Wie in Punkt 2.11 des AFS-FAQs von Thomas Müller beschrieben, kann man mittels symbolischer Links die Zugriffsrechte aber auch pro Datei definieren.

    Konkret empfiehlt es sich, das Verzeichnis $HOME/.ssh/ für jedermann lesbar zu machen (system:anyuser hat die Rechte rl), dort aber nur die öffentlich zugänglichen Dateien sowie symbolische Links auf die privaten Dateien abzulegen. Die privaten Dateien selbst werden dann in einem anderen, nur für den Eigentümer lesbaren Verzeichnis untergebracht.

    Anmerkungen zur Sicherheit

    Generell empfiehlt es sich im Bereich der Sicherheit, keine zu alten Werkzeuge zu verwenden, da in der Regel in den neueren Versionen Fehler der Vorgänger beseitigt und mitunter sehr nützliche zusätzliche Funktionen angeboten werden. Natürlich können auch neue Fehler hinzukommen.

    SSH-Versionen unterhalb 1.2.13 sollten keinesfalls mehr verwendet werden, da sie eine ernste Sicherheitslücke enthielten, die das Stehlen des privaten Host-Keys ermöglichte.

    Auf einigen Plattformen (z.B. SunOS 4.1.x) besteht bis Release 1.2.14 für normale Nutzer eine sehr einfache Möglichkeit, auf private RSA-Schlüssel anderer Nutzer zuzugreifen, sofern diese einen SSH-Agenten zur Schlüsselverwaltung verwenden und die Verbindung zum Agenten weiterleiten lassen. Dieses konkrete Problem wurde in Release 1.2.16 behoben.

    Dennoch ist auch bei 1.2.16 Vorsicht bezüglich der Verwendung des SSH-Agenten geboten, da durch Ausnutzung von Race Conditions immer noch Angriffsmöglichkeiten bestehen, wenngleich der Angriff nicht ganz einfach zu realisieren sein dürfte. 

    Hauptanliegen von Version 1.2.17 war die Behebung der Sicherheitsprobleme im Zusammenhang mit dem SSH-Agenten. Dazu wurde ein neues Protokoll zur Kommunikation mit dem Agenten eingeführt. Das alte und das neue Protokoll sind inkompatibel. Daraus resultiert z.B. die Meldung 

      Warning: Denied agent forwarding because the other end has too old version.
    Dieser Hinweis sollte nicht mißverstanden werden. Wer keinen Agenten nutzt, ist von keinerlei Einschränkungen betroffen. Die anderen Funktionen der SSH bleiben unabhängig vom Agenten voll erhalten. Sobald sowohl Klient als auch Server mindestens die Version 1.2.17 haben, kann der Agent wieder in vollem Umfang genutzt werden.

    Von der Verwendung der Releases 1.2.18 und 1.2.19 ist eher abzuraten, da innerhalb kurzer Zeit relativ viele Änderungen vorgenommen wurden, weil verschiedene Probleme entdeckt worden sind. Außerdem existieren für diese Versionen keine AFS-Patches. Mit der Version 1.2.20 scheint sich die Situation wieder deutlich stabilisiert zu haben.

    Wird der SSH-Klient als Setuid-Root-Programm (Programm, das mit Root-Rechten ausgeführt wird) betrieben, so besteht bis einschließlich Version 1.2.21 eine relativ leichte Möglichkeit, Zugang zu fremden SSH-Agenten zu erlangen und so die dort gespeicherten Schlüssel im Rahmen von Authentifizierungsdialogen zu mißbrauchen. Dieses Problem wurde im Advisory SNI-23: SSH - Vulnerability in ssh-agent beschrieben. Einen Zugriff auf den Agenten mittels ssh-add gestattet diese Attacke dagegen nicht, so daß der Angreifer z.B. keine Schlüssel auslesen kann.

    Das intern verwendete Binärprotokoll der SSH 1.x nutzt zur Sicherung der Integrität der zwischen Server und Klient ausgetauschten Pakete den (in der Regel verschlüsselt übertragenen) CRC-32, der ein kryptographisch schwaches Verfahren darstellt. Wie von Ariel Futoransky und Emiliano Kargieman (CORE SDI S.A., Buenos Aires, Argentinien) gezeigt wurde, besteht daher für einen Angreifer prinzipiell die Möglichkeit, durch eine sog. Insertion Attack, d.h. durch speziell konstruierte, mit einem korrekten CRC versehene Pakete Daten seiner Wahl unbemerkt in den verschlüsselten SSH-Kanal einzuschleusen und so z.B. beliebige Kommandos auf dem Server auszuführen.

    Ein Security Advisory, Informationen zu den kryptographischen Details sowie Patches zur Erkennung derartiger Attacken stehen unter dem URL http://www.core-sdi.com/ssh/ zur Verfügung. Gegen diesen Angriff sind alle SSH-Versionen bis einschließlich 1.2.23 anfällig. Version 1.2.24 steht nicht öffentlich zur Verfügung. Ab Version 1.2.25 wurde zusätzlicher, von den Advisory-Autoren bereitgestellter Code integriert, der gefälschte Pakete erkennen und so die Kommunikationspartner vor der beschriebenen Attacke schützen soll. Nach der Freigabe von SSH 1.2.25 wurde ein weiterer Patch veröffentlicht, der diesen Erkennungs-Code verbessert und den man anwenden sollte, sofern man Version 1.2.25 einsetzt. Ab SSH 1.2.26 ist dieser neue Patch bereits Bestandteil der Standard-Distribution.

    Dieser Zusatzcode ist nur als Zwischenlösung zu sehen, da das Problem nicht durch Fehler in der Implementierung, sondern durch eine Schwäche im Design der Version 1.x des SSH-Protokolls bedingt ist. Diese Schwäche wird in der Version 2.x des SSH-Protokolls beseitigt, indem man dort einen kryptographisch starken MAC (Message Authentication Code) verwendet, der auf dem mittlerweile in vielen Systemen favorisierten HMAC-Verfahren (RFC 2104: HMAC: Keyed-Hashing for Message Authentication) beruht.

    SSH-Installationen des URZ

    1. Zentrales Dateisystem (/uni/global)

      2.  

       

      Auf /uni/global stehen SSH-Installationen für verschiedene UNIX-Plattformen zur Verfügung, die jeweils Klienten, Server und Manuals umfassen:

      SSH-Version  AFS-Patchlevel Plattformen
      1.2.21  1  dec5000
      1.2.26  1 linux2, i386_linux3, sun5, hp1ux10, hp2ux10, sun4, dec3000, risc6000, sgi4000

      Eine künftige Pflege dieser Installationen konzentriert sich schwerpunktmäßig auf linux2, sun5, hp1ux10, hp2ux10 und evtl. sun4.

      Warnung: Von der Nutzung evtl. noch existierender SSH-Installationen für oben nicht genannte Plattformen (z.B. Linux 1.x) ist auf Grund ihres relativ hohen Alters eher abzuraten.

      Anmerkung: Bei der unter /uni/global bereitgestellten Installation von SSH 1.2.21 wird der im Security Advisory SNI-23 beschriebene Zugriff auf fremde SSH-Agenten (hoffentlich zuverlässig) verhindert, da die das genannte Problem verursachende Datei authfd.c der Quelltext-Distribution der Version 1.2.21 bereits gegen die gleichnamige Datei der im SNI-23 empfohlenen Version 1.2.22 ersetzt wurde. 

    2. Windows NT

      3.  

       

      Die durch das URZ administrierten Installationen von Windows NT (z.B. auf den öffentlichen Maschinen im PC-Pool) enthalten einen kommerziellen SSH-Klienten von DataFellows. Sein Versions-Identifikator lautet SSH-1.5-W1.0, d.h., er unterstützt die Version 1.5 des SSH-Protokolls. Der Klient ist über die Menüfolge

      Start --> Programme --> URZ Software --> tools --> Telnet --> Ssh.exe
      zu erreichen. Das Installationsverzeichnis heißt u:\tucz\dept\nt\pool_sw\ssh32. 
    3. Öffentliche UNIX-Server

      4.  

       

      Die öffentlichen UNIX-Server des URZ sind jeweils mit einem lauffähigen SSH-Dämon ausgestattet und somit über SSH erreichbar. Nach Möglichkeit sollten alle Nutzer die Secure Shell zur Arbeit mit entfernten Maschinen verwenden. Die konkrete Version des SSH-Servers ist möglicherweise auf den einzelnen Systemen verschieden.

      An dieser Stelle sei noch einmal auf die weiter oben bereits erwähnte inkompatible Änderung des Protokolls zur Kommunikation mit dem SSH-Agenten hingewiesen, die zu dessen eingeschränkter Verfügbarkeit führen kann.

      Auch wenn sowohl Server als auch Klient mindestens die Version 1.2.17 verwenden, kommt es evtl. unter bestimmten Umständen bei der Nutzung weitergeleiteter Verbindungen zum SSH-Agenten zu einem unangenehmen Nebeneffekt. Beim Schließen einer SSH-Verbindung wird die weitergeleitete Verbindung zum Agenten möglicherweise nicht automatisch geschlossen. Der Anwender erhält dann die folgende Meldung: 

        Waiting for forwarded connections to terminate...
  The following connections are open:
    Forwarded agent connection
      Dieses Verhalten ist als Bug zu werten. Tritt es auf, dann hilft nur noch das gewaltsame Trennen der Verbindung durch das Beenden des Klienten-Prozesses über ein Signal oder durch die Escape-Sequenz Tilde-Punkt (~.), die allerdings nur unmittelbar nach dem Betätigen der Return-Taste ihre Sonderbedeutung besitzt. 
    4. Symmetrische Verschlüsselungsverfahren zum Schutz von SSH-Kanälen

      5.  

       

      Die zentral bereitgestellte SSH-Installation unterstützt zum Zweck des kryptographischen Schutzes der SSH-Kanäle die folgenden symmetrischen Verschlüsselungsverfahren:

      Bezeichnung bei SSH  Erläuterung
      3des Triple DES mit 192-Bit-Schlüsseln
      blowfish Blowfish mit 256-Bit-Schlüsseln
      none keinerlei Verschlüsselung

      Der Triple DES (3des) ist das Default-Verfahren.

      Warnung: Die Verwendung von none sollte nur in begründeten Ausnahmefällen erfolgen, da der Verzicht auf eine Verschlüsselung zum kompletten Verlust des kryptographischen Schutzes der SSH-Kommunikation führt, d.h., auch die Authentizität und Integrität der Kommunikation sind nicht mehr gewährleistet.

      Das Verfahren IDEA, das bei der SSH vorzugsweise verwendet wird, sofern man es bei der Konfiguration nicht explizit ausschließt, wurde gezielt deaktiviert, um eine Verletzung der Lizenzbedingungen (s. http://www.ascom.ch/infosec/idea/licensing.html) von vornherein auszuschließen.

      Sollte der im Vergleich zu IDEA rechenaufwendigere Triple DES zu spürbaren Geschwindigkeitseinbußen führen, was rein subjektiv auf neuerer Hardware bisher nicht festgestellt werden konnte, so empfiehlt sich die Wahl des freien Algorithmus Blowfish, der für eine Software-Implementierung entwickelt wurde, u.a. mit dem Ziel, schnell und sicher zu sein. Auf jeden Fall ist Blowfish deutlich schneller als DES und IDEA. Bisher gilt er auch als sicher, wenngleich er nicht so intensiv untersucht wurde wie IDEA und vor allem DES.

      Die Verwendung von Blowfish wird durch eine entsprechende Option des SSH-Klienten aktiviert. Hierbei sind verschiedene Angaben möglich:

    5. Unterstützung von AFS und Kerberos v4

      6.  

       

      In die SSH-Installation von /uni/global wurden neben kleineren eigenen Modifikationen, die der Anpassung an unsere konkrete Umgebung dienen, vor allem die von Dug Song bereitgestellten Patches zur Unterstützung von AFS und Kerberos v4 integriert (Original-URL: http://www.monkey.org/~dugsong/ssh-afs-kerberos.html).

      Hinweis: Ab AFS-Patchlevel 4 für SSH 1.2.17 geben die auf /uni/global bereitgestellten Server und Klienten ihr jeweiliges Patchlevel in der Versionsangabe (durch ssh-v ermittelbar) bekannt, z.B. 1.2.17-afs_pl4 oder 1.2.25-afs_pl1.
      Mit dem Übergang auf SSH 1.2.22 nutzen die Patches von Dug Song nicht länger die AFS-Bibliotheken von Transarc, sondern erfordern die frei verfügbaren Kerberos4-Bibliotheken der KTH (Kungliga Tekniska Högskolan; Royal Institute of Technology, Stockholm, Sweden), die auch eine AFS-Unterstützung bieten. Bedingt durch die Verwendung der KTH-Bibliotheken wurde bei uns mit SSH 1.2.22 erstmals zusätzlich zum schon länger genutzten AFS-Teil auch die Unterstützung von Kerberos v4 aktiviert.

      Darüber hinaus hat der Wechsel der Bibliotheken einige weitere Konsequenzen, die nachfolgend etwas näher dargestellt werden sollen.

      Bis SSH 1.2.21 wurden pro Plattform in der Regel zwei SSH-Klienten und zwei SSH-Server angeboten:

      ssh.afs Klient für AFS-Klienten-Maschinen
      ssh.noafs Klient für Maschinen, die keine AFS-Klienten sind
      sshd.afs Server für AFS-Klienten-Maschinen
      sshd.noafs Server für Maschinen, die keine AFS-Klienten sind

      Die Klienten ssh.afs und ssh.noafs können direkt aufgerufen werden. Allerdings sollte diese Unterscheidung durch den Nutzer nicht nötig sein, da das Kommando /uni/global/bin/ssh auf den betreffenden Plattformen ermittelt, ob die verwendete Maschine AFS-Klient ist oder nicht, und in Abhängigkeit davon den entsprechenden SSH-Klienten startet.

      Auf Machinen, die keine AFS-Klienten sind, sollten unbedingt der Original-Server sowie der Original-Klient eingesetzt werden, da die AFS-Patches nach bisherigen Erfahrungen eine vorzeitige, fehlerhafte Programmbeendigung bewirken.

      Es empfiehlt sich ggf., beim Start des SSH-Dämons das jeweils adäquate Server-Programm dynamisch zu ermitteln, wie es im folgenden Beispiel an Hand eines Shell-Skripts für Linux gezeigt wird: 

        #!/bin/sh
  
  afsd=`ps -aux | grep 'root.*afsd' | grep -v grep`
  if [ -z "$afsd" ]; then
    /usr/local/sbin/sshd.noafs "$@"
  else
    /usr/local/sbin/sshd.afs "$@"
  fi
      Ab SSH 1.2.22 ist es erfreulicherweise nicht mehr notwendig, zwei getrennte Versionen der Klienten- und Server-Software anzubieten. Die Programme testen jetzt selbständig zur Laufzeit mit Hilfe einer KTH-Funktion, ob sie auf einem AFS-Klienten ausgeführt werden. Nur wenn dies der Fall ist, aktivieren sie die AFS-Unterstützung. Damit ist die Software auch problemlos auf Maschinen ohne AFS-Funktionalität einsetzbar.

      Achtung: In reinen AFS-Umgebungen wie unserer muß man der SSH mitteilen, wo sie den Kerberos-Server (konkret den AFS kaserver) findet. Dazu dienen die Dateien /etc/krb.conf und /etc/krb.realms, die in unserer AFS-Zelle folgenden Inhalt haben:

      Hinweis: Dug Song bietet über seine Seite http://www.monkey.org/~dugsong/ssh-afs-kerberos.html ein Shell-Skript an, daß diese beiden Dateien aus CellServDB und ThisCell automatisch generiert.

      Anmerkungen zu Solaris 2.x:

      Die über /uni/global/bin erreichbaren SSH-Werkzeuge wurden konkret unter der mittlerweile schon relativ alten Release Solaris 2.4 compiliert und gelinkt, um sie auf möglichst vielen Plattformen nutzen zu können. Möglicherweise ist die Software allerdings unter noch älteren Solaris-Releases nicht lauffähig.

      Im Paket-Pfad /uni/global/packages/ssh-1.2.y/bin stehen zusätzlich die unter Solaris 2.5.1 erzeugten Werkzeuge zur Verfügung. Um die Programme sauber voneinander zu trennen, wurden sie in getrennten Verzeichnissen abgelegt: SOL_2.4 und SOL_2.5.1. Wer also die Versionen für Solaris 2.5.1 nutzen möchte, muß auf die Software im Verzeichnis SOL_2.5.1 zugreifen.

      Anders als bei den Klienten sollte man bei den Servern der Version des Betriebssystems etwas mehr Beachtung schenken. Es ist allgemein ratsam, nach Möglichkeit einen SSH-Server einzusetzen, der für das Zielsystem generiert wurde. Die Unterscheidung der SSH-Server erfolgt durch entsprechende Namens-Suffixe. Die beiden unter /uni/global/packages/ssh-1.2.y/etc verfügbaren Versionen tragen die Bezeichnungen sshd.sol_2.4 bzw. sshd.sol_2.5.1.

      Anmerkungen zu Linux 2.x:
      Für die beiden Linux-Plattformen linux2 (Systeme mit der älteren C-Bibliothek Libc) und i386_linux3 (Systeme mit der aktuellen C-Bibliothek Glibc) stehen getrennte SSH-Installationen zur Verfügung. Die Paketpfade lauten:
      Plattform Paketpfad
      linux2 /afs/tu-chemnitz.de/global/linux2/packages/ssh-1.2.y
      i386_linux3 /afs/tu-chemnitz.de/global/i386_linux3/packages/ssh-1.2.y

      Für den Zugriff auf die Klienten-Programme existieren auf den öffentlichen Linux-Maschinen des URZ folgende Pfade:

      Plattform Zugriffspfad
      linux2 /uni/global/bin
      i386_linux3 /uni/global3/bin

      Im Normalfall sind Glibc-basierte Systeme in der Lage, viele Libc-Programme auszuführen. In Tests unter RedHat 5.2 und SuSE 6.0 wurden bisher keine Probleme mit den Libc-basierten SSH-Klienten festgestellt. Dennoch empfiehlt es sich, die Versionen sauber zu unterscheiden. Bei den SSH-Servern ist diese Unterscheidung der Versionen sogar erforderlich, um Beschädigungen von Log-Dateien des Systems zu vermeiden.

      Achtung: Die Libc-basierten Server lassen sich auf vielen Glibc-basierten Linux-Installationen ohne Fehlermeldung ausführen, allerdings besteht dabei die Gefahr der Beschädigung der Log-Dateien utmp und wtmp, da die Datensätze dieser Dateien bei Glibc und Libc eine unterschiedliche Struktur aufweisen, was allerdings nicht automatisch bemerkt wirkt.

      Die Patches von Dug Song sorgen in unserer Installation für das Einrichten einer PAG-Umgebung (Process Authentication Group) auf dem Server (früher nachträglich durch spezielle Scripts des URZ realisiert) sowie eine Übertragung der auf dem Klienten evtl. vorhandenen AFS-Token zum Server (AFS token passing), so daß dort keine wiederholte AFS-Authentifizierung (Kommando klog) nötig ist. Außerdem ermöglichen die Patches ein Login mit dem AFS-/Kerberos-Paßwort anstelle des UNIX-Paßworts. Auf den meisten öffentlichen Rechnern des URZ sind gegenwärtig derart modifizierte Server im Einsatz.

      Das AFS-Token-Passing sowie die Möglichkeit des Logins mit dem AFS-Paßwort können durch Optionen in den Konfigurationsdateien des Servers bzw. des Klienten abgeschaltet werden, indem man den Wert no einträgt. Die folgenden Einstellungen sind hierbei relevant (Groß- und Kleinschreibung werden von der Software nicht unterschieden):

      AFSTokenPassing   no
      AFSPasswordAuthentication   no   (nur beim Server; existierte nur bis zur Release 1.2.17)
      KerberosAuthentication   no   (nur beim Server; existiert erst ab Version 1.2.20)
      KerberosOrLocalPasswd   no   (nur beim Server; existiert erst ab Version 1.2.20)
      Hinweise:
      Durch Aufruf des Klienten ssh mit der Option -k wird die Weiterleitung von AFS-Token und Kerberos-Tickets unterdrückt.

      Die Optionen AFSTokenPassing und AFSPasswordAuthentication sind standardmäßig auf yes gesetzt, also aktiviert. Dagegen ist in der unter /uni/global bereitgestellten Installation die Option KerberosAuthentication erst ab SSH 1.2.22 im Standardfall auf yes, in älteren Versionen dagegen auf no gesetzt, da die Software bis SSH 1.2.21 nur für AFS-, nicht aber für reine Kerberos-Authentifizierung konfiguriert wurde. Sofern der Server auch dort das AFS-Paßwort akzeptieren soll, muß also die Zeile 

        KerberosAuthentication  yes
      in die Konfigurationsdatei (standardmäßig /etc/sshd_config) eingetragen werden.

      Sollen sowohl das AFS- als auch das UNIX-Paßwort zum Login genutzt werden können, ist generell die Options-Zeile 

        KerberosOrLocalPasswd   yes
      zu ergänzen, da diese Option den Default-Wert no hat.
      Die ab SSH 1.2.22 verwendete KTH-Bibliothek versucht, unter Verwendung der C-Funktion getservbyname() den zum Dienst kerberos-iv gehörenden Port zu ermitteln. Falls dies nicht gelingt (z.B. weil kein passender Eintrag in /etc/services bzw. der entsprechenden NIS-Map gefunden wurde), so verwendet die Implementierung den Standard-Port 750, worauf sie mit der Meldung 
        kerberos-iv/* unknown service, using default port 750
      hinweist. Hierbei handelt es sich um keinen Fehler. Die obige, möglicherweise irritierende Mitteilung läßt sich vermeiden, indem man geeignete Service-Einträge ergänzt, z.B. durch den Nachtrag der folgenden Zeilen in der Datei /etc/services: 
        kerberos-iv 750/udp     kdc # Kerberos (server) udp
  kerberos-iv 750/tcp     kdc # Kerberos (server) tcp
      Ein unter Verwendung der KTH-Bibliothek beschafftes AFS-Token wird möglicherweise auf dem AFS-Klienten mit einer inkorrekten numerischen AFS-ID registriert, da die KTH-Routinen im Gegensatz zum Code von Transarc nicht mit dem AFS Protection Server kommunizieren, um die korrekte AFS-ID zu ermitteln. Statt dessen verwenden sie einfach die UNIX-ID. Da im URZ die UNIX- und AFS-ID jedes Nutzers identisch sind, wird dieser Unterschied in der Regel nicht sichtbar.

      Johan Danielsson, ein Mitglied des KTH-Entwickler-Teams, wies in einer privaten E-Mail darauf hin, daß die AFS-ID lediglich durch das Kommando tokens verwendet wird, intern aber sonst keine Rolle spielt, so daß trotz falscher ID alles normal funktionieren sollte:

      The ID in the token is just a number and isn't used for anything (other than in the listing produced by `tokens'). To get the correct AFS id, you'll have to talk to your protection server; the Transarc code does that, but we don't think the (lots of) extra code is worth it. Instead we use the unix id. Everything should work just fine anyway.
      SSH 1.2.22 führt ein weiteres neues "Feature" ein. Sofern das Home-Verzeichnis eines Nutzers im AFS liegt, versucht SSH, die Xauthority-Informationen lokal zu speichern, um deren Ablauschen zu verhindern. Man sollte beachten, daß die Daten zwischen AFS-Servern und -Klienten im Klartext übertragen werden. Laut Aussagen von Dug Song, dem Autor der AFS-Patches für SSH, ist es deshalb sehr leicht, die Xauthority-Informationen zu stehlen.

      Aus diesem Grund speichert SSH diese Daten entweder im Verzeichnis /ticket (falls dieses existiert) oder unter /tmp, wobei angenommen wird, daß sich diese beiden Verzeichnisse stets auf der lokalen Platte des Servers befinden. Die Administratoren sollten deshalb immer dafür sorgen, daß diese Annahme zutrifft.

      Aus der lokalen Speicherung der Xauthority-Informationen resultieren Meldungen folgender Art, die vom Kommando xauth stammen, aber wiederum keinen Fehler signalisieren: 

        /usr/bin/X11/xauth:  creating new authority file /tmp/Xauth4324_9046
      Diese Meldung läßt sich durch jeden Nutzer individuell unterdrücken, in dem er beim Aufruf des Kommandos xauth den Standard-Fehlerstrom umlenkt, z.B. nach /dev/null. Dazu ist es notwendig, in der Datei $HOME/.ssh/rc ein geeignetes Shell-Skript abzulegen. Sofern dieses Skript existiert, wird es vom SSH-Dämon anstelle von xauth ausgeführt. Über die Standard-Eingabe übergibt der Dämon an das Skript die für xauth relevanten Informationen proto und cookie.

      Man muß beachten, daß das Skript $HOME/.ssh/rc immer von der Login-Shell des Nutzers (tcsh, bash,  ...) interpretiert wird. Da sich die jeweiligen Shell-Sprachen mehr oder minder deutlich voneinander unterscheiden, empfiehlt es sich in der Regel, $HOME/.ssh/rc lediglich zum Aufruf eines anderen Skripts zu nutzen, das dann die konkret auszuführenden Anweisungen bzw. Kommandos (z.B. xauth) enthält. Auf diese Weise kann man sehr einfach die zu verwendende Shell festlegen.

      Hier nun ein Beispiel:

      Kerberos-Tickets, die entweder analog den AFS-Token vom Klienten auf den Server übertragen oder bei der Authentifizierung über das AFS-/Kerberos-Paßwort vom Server neu beschafft werden, verwaltet der SSH-Dämon ebenfalls in einer Datei auf der lokalen Platte des Servers, und zwar wie bei der Xauthority-Informationen entweder unter /ticket (falls dieses Verzeichnis existiert) oder unter /tmp.

      Bei einer regulären Beendigung einer SSH-Verbindung werden die vom Dämon auf der lokalen Platte angelegten Xauthority- und Ticket-Dateien wieder entfernt.

      Die Namen der jeweils vom SSH-Dämon angelegten Dateien haben folgenden Aufbau:

      Die vom Dämon gestarteten Programme können die konkret verwendeten Namen der lokalen Xauthority- und Ticket-Dateien über die Umgebungsvariablen KRBTKFILE bzw. XAUTHORITY erfahren.

      Da bis Version 1.2.17 eine andere interne Kodierung für das AFS-Token-Passing verwendet wurde, ist die Übergabe des Tokens an den Server nicht möglich, falls alte und neue Versionen von Klienten und Servern aufeinandertreffen. "Alt" heißt hier bis SSH 1.2.17, neu bedeutet ab SSH 1.2.18 bzw. praktisch ab SSH 1.2.20, da es für SSH 1.2.18 und 1.2.19 keine AFS-Patches gab. Um diese Probleme weitgehend zu entschärfen, enthalten die auf /uni/global bereitgestellten Klienten ab der Version 1.2.20 eine spezielle lokale Modifikation, die ein AFS-Token-Passing auch bei der Nutzung eines Servers der Version 1.2.17 oder älter gestattet. 

    6. Weitere lokale Modifikationen

      7.  

       

      Die unter /uni/global bereitgestellten SSH-Server wurden außerdem lokal so modifiziert, daß sie an Stelle der Host-Namen die IP-Adressen der Klienten-Maschinen in die Accounting-Dateien des Systems (utmp, utmpx, wtmp, wtmpx, lastlog) eintragen.

      Des weiteren wurde der SSH-Server ab Version 1.2.21 derart erweitert, daß er jetzt in der Lage ist, die ggf. existierende Datei /etc/login.access auszuwerten. Dieses Konzept wird auch in dem auf /uni/global angebotenen und auf vielen öffentlichen URZ-Maschinen eingesetzten tuclogin genutzt. Es stammt aus dem Paket logdaemon von Wietse Venema und realisiert nach den Worten des Autors eine einfache, aber effektive Form der Zugangskontrolle beim Login, die auf Nutzerkennzeichen, Host-Namen und IP-Adressen beruhen kann.

      Die konkret im SSH-Server verwendete Implementierung wurde der Release 5.6 des Logdaemon-Pakets entnommen. SSH verwehrt das Login mit der Meldung "Permission denied", falls weder unter Verwendung des kanonischen Hostnamens noch der IP-Adresse ein Login durch die in /etc/login.access enthaltenen Regeln gestattet wird. Sofern /etc/login.access nicht existiert, gelten von dieser Seite her keinerlei Einschränkungen für die Logins, d.h., der in der lokalen Installation ergänzte Code zur Auswertung der Zugangsregeln bleibt wirkungslos.

    Installation aus den Quellen

    Die Installation auf UNIX-Systemen ist weitestgehend automatisiert, da ein configure-Script zur Verfügung steht. Detaillierte Informationen sind im File INSTALL der Distribution zu finden.

    Meist genügt eine in etwa wie folgt aussehende Kommandofolge:

    1. ./configure
    2. make
    3. make install (als Superuser)
    4. /usr/local/sbin/sshd
    Speziell auf relativ langsamen Maschinen empfiehlt es sich, den sshd beim Starten des Betriebssystems zu aktivieren, z.B. durch Eintragen von 
      if [ -x /usr/local/sbin/sshd ]; then
     /usr/local/sbin/sshd && echo sshd
  fi
    in eine geeignete rc-Datei. Dadurch werden unangenehme Verzögerungen beim Aufbau jeder SSH-Verbindung vermieden, die daraus resultieren, daß die beim Start des Dämons durchgeführte Generierung der RSA-Server-Keys verhältnismäßig zeitaufwendig ist. Der einmal gestartete Dämon behandelt alle nachfolgend eintreffenden Verbindungswünsche der Klienten.

    Auf relativ schnellen Computern fällt dagegen die für die RSA-Schlüssel-Erzeugung benötigte Zeit nicht ins Gewicht. Es ist deshalb ohne weiteres möglich, unter Verwendung des inetd oder eines äquivalenten Mechanismus für jeden eintreffenden Verbindungswunsch einen neuen Dämon zu starten. Bei Nutzung des inetd muß der SSH-Server mit der Option -i gestartet werden, so wie dies in der folgenden Beispiel-Zeile der Datei /etc/inetd.conf gezeigt wird: 

      ssh stream  tcp nowait  root    /usr/sbin/tcpd  /usr/local/sbin/sshd -i

    Installation der Dateien von /uni/global

    In der Regel dürfte es genügen, den Dämon sshd und einige zugehörige Dateien lokal zu installieren. Die restlichen Kommandos können direkt von /uni/global genutzt werden.

    Bei einer lokalen Installation des Kommandos ssh ist bis zur Version 1.2.21 darauf zu achten, daß dieses Kommando nur feststellt, ob die verwendete Maschine ein AFS-Klient ist, und danach den entsprechenden SSH-Klienten ssh.afs bzw. ssh.noafs startet. Demnach ist neben ssh noch der eigentliche Klient zu installieren. Ab SSH 1.2.22 handelt es sich bei ssh um den wirklichen SSH-Klienten.

    Sofern ssh den privaten Host-Key der Klienten-Maschine lesen und privilegierte TCP-Ports (unterhalb 1024) verwenden können soll, so muß dieses Programm dem Superuser root gehören und das Setuid-Bit gesetzt bekommen. Aus Sicherheitsgründen sollte man allerdings nach Möglichkeit auf das Setuid-Bit verzichten, da Programme, die Root-Rechte haben, die Integrität des gesamten Systems gefährden können.

    Im Paketpfad /uni/global/packages/ssh-1.2.y/etc finden sich folgende SSH-Dateien:

    ssh_config Beispiel-Konfiguration für den SSH-Klienten (global oder lokal verwendbar)
    ssh_host_key Platzhalter für den RSA-Host-Key (Schlüsselpaar)
    ssh_host_key.pub Platzhalter für den im externen Format abgelegten öffentlichen Schlüssel des Hosts
    sshd_config Beispiel-Konfiguration für den SSH-Dämon
    config.sample Beispiel für eine nutzerbezogene Konfigurationsdatei
    bis SSH 1.2.21:
    sshd.afs SSH-Dämon für AFS-Klienten-Maschinen
    sshd.noafs SSH-Dämon für Maschinen, die keine AFS-Klienten sind
    ab SSH 1.2.22:
    sshd SSH-Dämon, der sowohl auf AFS-Klienten-Maschinen als auch auf Rechnern ohne AFS-Funktionalität lauffähig ist

    Anmerkungen:

    Mit Ausnahme von config.sample sind die o.g. Dateien auch über /uni/global/etc erreichbar.

    Beachten Sie bitte die obigen Anmerkungen zur Unterscheidung der verschiedenen SSH-Versionen bei Linux 2.x und Solaris 2.x .

    Die Files ssh_host_key und ssh_host_key.pub sind für jede Maschine neu mit Hilfe des Kommandos ssh-keygen zu generieren. Die unter /uni/global/etc angebotenen Dateien sind daher nicht verwendbar. Um Fehlern vorzubeugen, handelt es sich bei ihnen auch nur um Textdateien, die den Zweck und die Handhabung der lokalen Entsprechungen angeben.

    Vorgeschlagene Installationsschritte:
    1. Kopieren des Dämons (z.B. /uni/global/etc/sshd) in ein lokales Verzeichnis und Setzen geeigneter Zugriffs-Rechte

      2.  

       

      Beispiel:

      Der Dämon trägt bewußt nicht das Setuid-Bit. Er sollte immer direkt von root gestartet werden.
    2. Kopieren der Konfigurationsdateien ssh_config und sshd_config nach /etc

      3.  

       

      Diese Dateien sind bei Bedarf vom Administrator an die lokalen Gegebenheiten anzupassen. Die in den Beispielen getroffenen Voreinstellungen zielen auf ein hohes Sicherheitsniveau ab.

      Die Datei ssh_config kann einem Anwender neben config.sample als Vorlage zur Erstellung privater Konfigurationsdateien für den Klienten dienen.

    3. zentrale Bereitstellung der öffentlichen Host-Keys häufig benötigter Maschinen in der Datei /etc/ssh_known_hosts

      4.  

       

      Hinweis: Die öffentlichen Host-Keys der öffentlichen Maschinen des URZ können der Datei /uni/global/text/ssh_known_hosts entnommen werden.

      Sollen außer den dort abgelegten Schlüsseln keine weiteren zur Verfügung gestellt werden, so empfiehlt sich ein symbolischer Link:

          ln -s /uni/global/text/ssh_known_hosts /etc/ssh_known_hosts

    4. Erzeugen des Host-Keys mittels /uni/global/bin/ssh-keygen:

      5.  

       

          /uni/global/bin/ssh-keygen -b 1024 -f /etc/ssh_host_key -N ''

      Dieses Kommando erzeugt die Dateien /etc/ssh_host_key und /etc/ssh_host_key.pub

      Achtung: Die erzeugte Datei /etc/ssh_host_key darf lediglich für root lesbar sein, da sie den unverschlüsselten privaten Schlüssel des Hosts enthält!

    5. Starten des Dämons

      6.  

       

      Der Dämon kann jederzeit von der Kommandozeile aus gestartet werden, z.B. durch folgende Eingabe:

          /usr/local/sbin/sshd

      Nach dem Start legt der Dämon automatisch die Dateien /etc/sshd.pid und /etc/ssh_random_seed an (diese Namen stellen die Default-Werte dar und können bei Bedarf über die Konfigurationsdatei verändert werden).

      Für den Routine-Betrieb einer Maschine ist es natürlich generell ratsam, den sshd wie oben beschrieben automatisch zu starten: entweder beim Booten des Betriebssystems oder über den inetd bzw. analoge Mechanismen.

    Bemerkung zu einigen anderen Sicherheits-Werkzeugen

    Neben SSH gibt es noch andere Ansätze, um eine höhere Sicherheit der Kommunikation über unsichere Netze zu erreichen. Die wesentlichen Unterschiede zwischen SSH und einigen weiteren Vertretern praktisch verfügbarer Implementierungen sollen hier kurz genannt werden.

    Absicherung verschiedener Dienste durch SSH

    SSH kann generell zum Aufbau gesicherter Netzverbindungen (auch im Rahmen eigener Entwicklungen) verwendet werden. Tatu Ylönen orientiert aus Sicherheitsgründen bewußt nicht auf eine Programmier-Schnittstelle (API), sondern darauf, den unveränderten SSH-Klienten als Sub-Prozeß zu starten und mit ihm über Pipes zu kommunizieren.

    Mögliche Anwendungen:

    Ein Beispiel soll das illustrieren. SSH wird verwendet, um eine Klartext-Übertragung der Paßwörter bei FTP zu verhindern. Durch die integrierte Weiterleitung von TCP-Ports ist es sehr einfach möglich, die Steuerverbindung von FTP kryptographisch zu sichern. Dadurch wird automatisch die Übertragung von Nutzerkennzeichen und Paßwort transparent verschlüsselt.

    Die für jede Übertragung neu aufgebauten FTP-Datenverbindungen können nur dann mit Hilfe der Port-Weiterleitung gesichert werden, wenn der FTP-Klient dem Nutzer gestattet, die vom Server zu verwendende Zieladresse inkl. Port zu spezifizieren, was meist nicht möglich ist. Um vom Rechner client aus eine gesicherte FTP-Verbindung zum Rechner ftp-serv aufzubauen, empfiehlt sich folgendes Vorgehen:

    1. Aufbau einer SSH-Verbindung zum FTP-Server ftp-serv mit Weiterleitung eines freien Ports (z.B. 2345) zum well-known Port von FTP (21):
      2. ssh -L 2345:ftp-serv:21 ftp-serv
      Ab SSH 1.2.23 ist es notwendig, die Option gatewayports auf yes zu setzen, da sonst nur Verbindungen mit der Zieladresse 127.0.0.1 (Adresse des Loopback-Geräts; meist localhost genannt) weitergeleitet werden. Das Setzen dieser Option kann z.B. über die Datei $HOME/.ssh/config oder durch Angabe von -g auf der Kommandozeile erfolgen:
      ssh -g -L 2345:ftp-serv:21 ftp-serv
    2. Nutzung des weitergeleiteten Ports auf dem Rechner client:
      3. ftp client 2345
      Hinweis: Falls statt client die Adresse localhost angegeben wird, kann mit hoher Wahrscheinlichkeit keine Datenverbindung aufgebaut werden. Damit scheitert auch ein Auflisten von Datei-Verzeichnissen.
    Ein weitergeleiteter Port ist von allen Klienten nutzbar. Bezogen auf das FTP-Beispiel bedeutet das, daß sich beliebige Klienten an den Port 2345 des Rechners client wenden können, wodurch sie den FTP-Server auf Rechner ftp-serv erreichen.

    Die konkrete Vorgehensweise bei der Absicherung anderer TCP-basierter Dienste unter Nutzung der Port-Weiterleitung ist jeweils von den verwendeten Klienten abhängig.

    Weitere Informationsquellen


    copyright by Holger Trapp
    18. Mai 1999