Secure Shell (SSH) im URZ der TU Chemnitz

SSH ist der vom URZ favorisierte Mechanismus für Remote Login, Remote Copy und Remote Execution beim Zugang zu Unix/Linux-Systemen im Netz.

Software

Die Implementierung OpenSSH gehört bei Unix/Linux-Systemen i.d.R. zum Standardumfang. Für Windows-Systeme ist PuTTY als SSH-Klient und WinSCP zum Übertragen von Dateien zu empfehlen:

• PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
• WinSCP: http://winscp.net/eng/docs/lang:de

Hinweis: Es gibt auch eine Linux-Version von PuTTY. Diese kann ggf. als grafische Alternative zur kommandozeilenorientierten OpenSSH verwendet werden.

Informationen

• Secure Shell (SSH) - Gesicherte Kommunikation über unsichere Netze
• Manuals der OpenSSH-Implementation

SSH, Kerberos und AFS

Die Installation und Konfiguration von OpenSSH auf den vom URZ betreuten Maschinen erfolgt so, dass ein Single-Sign-On-Verfahren realisiert wird:

1. Beim Login unter Linux an einer Maschine in einem der Pools oder an einem Arbeitsplatz geben Sie Ihr Nutzerkennzeichen und Ihr Passwort ein.
2. Daraufhin erhalten Sie ein sog. Kerberos Ticket Granting Ticket (TGT) und Ihr AFS-Token. Das TGT beweist anderen Rechnern und Diensten Ihre Identität, ohne dass Sie erneut Ihr Passwort eingeben müssen. Das TGT wird in einem Ticket Cache gespeichert. Diesen können Sie sich mit dem Kommando klist anzeigen lassen.
3. Beim Aufruf von ssh wird dieses TGT benutzt, um dem Zielrechner Ihre Identität zu bestätigen. Außerdem wird es an den Zielrechner übertragen (forward) und dort ebenfalls im Ticket Cache gespeichert.
4. Am Zielrechner wird ausgehend vom TGT ein AFS-Token erzeugt und dem AFS Cache Manager übergeben, so dass Sie auf Ihre Dateien zugreifen können.

Dieses Verfahren funktioniert nur in der Protokoll-Version 2, die auf Grund des höheren Sicherheitsniveaus stets bevorzugt werden sollte und bei den vom URZ administrierten Maschinen die einzig zulässige ist.

Wenn Sie sich bereits auf einer selbst administrierten Maschine ein TGT beschaffen möchten, um sich damit ohne Passwort-Eingabe per ssh an Maschinen des URZ anmelden zu können, übernehmen Sie bitte die entsprechenden Einstellungen der Konfigurationsdateien.
Beachten Sie bitte, dass Kerberos nur im Campusnutz oder mit einer VPN-Verbindung nutzbar ist.

• Kerberos-TGT beschaffen
  (Ersetzen Sie nkz durch Ihr Nutzerkennzeichen.)

    kinit nkz@TU-CHEMNITZ.DE

• optional: Kerberos-Konfiguration /etc/krb5.conf anlegen, ein Beispiel finden Sie im Abschnitt Kerberos-Konfiguration von Linux-/Unix-Systemen.
• Kerberos-Authentifizierung konfigurieren in ~/.ssh/config oder /etc/ssh/ssh_config

    Host *.tu-chemnitz.de
      GSSAPIAuthentication yes
      GSSAPIDelegateCredentials yes

Umgang mit SSH-Host-Schlüsseln und deren Fingerprints

SSH enthält mehrere Sicherheitsmechanismen. Neben einer verschlüsselten Datenübertragung, die die Vertraulichkeit gewährleistet, wird auch noch eine zuverlässige gegenseitige Authentifizierung der Partner, d.h. des jeweiligen Zielrechners (Servers) sowie des SSH-Benutzers realisiert.

Der Server verfügt dazu über Schlüsselpaare, die seiner indeutigen Identifikation dienen und jeweils aus einem privaten und einem öffentlichen Schlüssel bestehen. Aktuell kommen im URZ drei Typen von Schlüsselpaaren für SSH2 zum Einsatz: RSA, ECDSA und ED25519. Durch entsprechende kryptografische Operationen weist der Server dem Klienten nach, dass er über den zu seinem öffentlichen Schlüssel gehörenden privaten Schlüssel verfügt und somit der echte Server ist.

Dieser Nachweis setzt aber voraus, dass der Klient den authentischen öffentlichen Server-Schlüssel kennt und dessen Authentizität auch wirklich prüft. Dies erfolgt automatisch über die in Dateien gespeicherten Listen bekannter Schlüssel bzw. über Zertifikate einer bekannten SSH-CA (Certification Authority). Relevant hierfür sind die Dateien /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2 und $HOME/.ssh/known_hosts).

Wenn man einen Zielrechner kontaktiert, dessen öffentlicher Host-Schlüssel in den lokalen Schlüssellisten fehlt, zeigt die SSH mit der bei uns gewählten Standard-Option StrictHostKeyChecking ask den Fingerprint des öffentlichen Host-Schlüssels an und lässt den Benutzer entscheiden, ob dieser Schlüssel authentisch ist und daher die Verbindung aufgebaut werden soll, z.B.:

  $ ssh login.tu-chemnitz.de
  The authenticity of host 'login.tu-chemnitz.de (134.109.xxx.xxx)' can't be established.
  ED25519 key fingerprint is SHA256:tbY+wsIbU3ohVDGe2WSRSe6bC8IG9WGEyQmJQ2990Q4.
  Are you sure you want to continue connecting (yes/no)? 

Ein sicherheitsbewusster Nutzer wird erst dann mit yes antworten und damit die Übernahme des Host-Schlüssels in die eigene Schlüsselliste veranlassen, wenn er den Fingerprint sorgfältig überprüft, also mit dem auf einem sicheren Weg beschafften echten Wert verglichen hat.

Für einen SSH-Zugriff aus dem Internet steht die im obigen Beispieldialog genutzte Adresse

  login.tu-chemnitz.de

zur Verfügung, wobei dieser ab dem 13.12.2023 nur noch via VPN möglich ist.

Die MD5-, SHA1- und SHA256-Fingerprints der SSH-Host-Schlüssel lauten:

Nachdem ein verschlüsselter und authentischer SSH-Kanal zum Server etabliert wurde, authentifiziert der Klient den Benutzer gegenüber dem Server. Dafür stehen verschiedene Verfahren zur Verfügung. Sofern der Benutzer bereits über ein Kerberos-TGT verfügt, wird dieses wie oben beschrieben standardmäßig verwendet. Alternativ kann auch der Benutzer eigene Schlüsselpaare erzeugen und verwenden oder sich mit seinem Passwort gegenüber dem Server authentifizieren.

Um dieses Kerberos-TGT-basierte Single-Sign-On-Verfahren anbieten zu können, besitzt jeder Rechner des URZ eine entsprechende Kerberos-Identität. Der Kerberos5-Host-Schlüssel jeder Maschine steht bei Linux in der Datei /etc/krb5.keytab in Einträgen für den Principal host/fq.dn.tu-chemnitz.de@TU-CHEMNITZ.DE. Er wird auf dem SSH-Server benötigt, nicht auf dem Klienten. Ohne diesen Schlüssel kann der Server die Kerberos-Tickets, die ihm der Klient vorweist, nicht verarbeiten, weil diese mit dem Host-Schlüssel des SSH-Servers verschlüsselt sind.

Hinweise

• Das Verfahren zum Verifizieren der Korrektheit der Host-Schlüssel wird durch die folgende Option in den Konfigurationsdateien des SSH-Klienten (üblicherweise $HOME/.ssh/config, /etc/ssh/ssh_config) gesteuert:

   StrictHostKeyChecking   no|yes|ask

  Bei no lernt der Klient automatisch neue Keys, indem er sie in die Schlüsselliste übernimmt. Das ist sehr bequem, aber auch sehr unsicher. Mit yes verhindert man sicher das automatische Lernen von Schlüsseln. Hier muss man den Schlüssel manuell in der Schlüsselliste ergänzen. Beim Standardwert ask entscheidet der Nutzer an Hand des Fingerprints über die Authentizität des Schlüssels.
• Auf den vom URZ verwalteten Maschinen findet man in den Dateien /etc/ssh/ssh_known_hosts und /etc/ssh/ssh_known_hosts2 eine Sammlung der Public-Host-Keys zahlreicher Maschinen aus dem Campusnetz bzw. den öffentlichen Schlüssel der SSH-CA. Der Inhalt dieser Dateien wird automatisch gepflegt und regelmäßig auf alle vom URZ verwalteten Maschinen verteilt. Wenn man diese Datei in das eigene System überträgt, übernimmt man diese Public Keys und kann damit das Verifizieren des Host-Fingerprints umgehen, ohne dabei den zugrunde liegenden Sicherheitsmechanismus des SSH-Protokolls auszuschalten.