Modul 11: Sicherer Remote-Zugriff über SSH

Größe: px

Ab Seite anzeigen:

Download "Modul 11: Sicherer Remote-Zugriff über SSH"

Ulrike Pfeiffer
vor 5 Jahren
Abrufe

1 Modul 11: Sicherer Remote-Zugriff über SSH :48:03 M. Leischner Netze, CS, 2. Semester Folie 1

2 Security-Mgmt Sicherheit im Internet-Protokollstack pp SSH/TLS TCP IPSEC IP Schicht 1/2 System pp SSH/TLS TCP IPSEC IP Schicht 1/2 System Security-Mgmt Ebenen der Sicherheit Sicherheit auf pplikationsebene, z.. ecash, PGP. ("ich vertraue der pplikation") TLS: sichere Ende-zu- Ende-Verbindung ("ich vertraue dem sicheren Transport bis hin zu meiner nwendung") SSH: Sicheres Einloggen in ein Remote-System IPsec sichere IP- Verbindung zwischen Systemen ("ich vertraue der Übermittlung über das Internet") M. Leischner Netze, CS, 2. Sem. Folie 2

3 Krypto-asic 1: Symmetrische Verschlüsselung lice K ob und lice benutzen den gleichen Schlüssel K -----> Symmetrische Verschlüsselung K ob INFO encrypted INFO encrypted INFO INFO Internet M. Leischner Netze, CS, 2. Sem. Folie 3

4 Krypto-asic 2: Prinzip Public-Key-Kryptographie Zertifikat verweist auf lice Siegel lice lice hat zwei Schlüssel einen secret key (z.. auf einer Chipkarte) einen public key (Dieser ist nicht geheim, kann und sollte in einem öffentlichen Verzeichnis gespeichert werden Um zu verschlüsseln und um zu entschlüsseln benötigt man verschiedene Schlüssel (= asymmetrisch) M. Leischner Netze, CS, 2. Sem. Folie 4

5 Krypto-asic 3: symmetrische Verschlüsselung öffentliche Schlüssel (allen bekannt / nachprüfbar) lice ob INFO INFO INFO INFO Internet M. Leischner Netze, CS, 2. Sem. Folie 5

6 Krypto-asic 4: Digitale Unterschrift (uthentifizierung) öffentliche Schlüssel (allen bekannt / nachprüfbar) lice ob INFO INFO INFO INFO Internet M. Leischner Netze, CS, 2. Sem. Folie 6

7 Krypto-asic 5: Diffie-Hellman Key Exchange lgorithm öffentliche Schlüssel (allen bekannt / nachprüfbar) lice ob Diffie-Hellman key exchange algorithm Diffie-Hellman key exchange algorithm dieser abgeleitete Schlüssel wird oft "shared secret" SK Diese Schlüssel sind gleich! SK M. Leischner Netze, CS, 2. Sem. Folie 7

8 SSH Secure Shell Haupteinsatz: Sicherer Fernzugriff auf entfernte Geräte aller rt. uthentifizierung: Nur efugte dürfen zugreifen. Vertraulichkeit: Kein Unbefugter darf Daten auf der Verbindung einsehen. SSH läuft über TCP und benutzt standardmäßig den TCP-Port 22. Den Port 22 kann man in der Firewall (zu Hause) vorsichtig öffnen. Falls dahinter nur Server mit vernünftig gesichertem SSH-Zugang stehen, entsteht kein Problem. llerdings wird der Port 22 von Hackern Tag und Nacht angegriffen. Sie hoffen, einen nicht gut gesicherten SSH-Zugang zu finden. Daher verwenden Schlaumeier für SSH statt Port 22 einen anderen Port (z ). Vorteil: höhere Sicherheit. Nachteil: Unorthodoxe Herangehensweise, die zu überraschenden bzw. lästigen Probleme führen kann ( Ich habe zwar meinen SSH-Schlüssel, habe aber leider die Portnummer vergessen ) :48:04 M. Leischner Netze, CS, 2. Semester Folie 8

9 SSH Protokollablauf vereinfacht (Client/Server-Szenario) Voraussetzung: Server besitzt asymmetrisches Schlüsselpaar Schritt 1 - Server-Client: TCP-Verbindung aufbauen Protokollversion austauschen Schritt 2 - Server: sendet öffentlichen Host-Key und Liste der unterstützte Verschlüsselungsalgorithmen Schritt 3 - Client: akzeptiert Host-Key (bereits bekannt bzw. User fragen) wählt Verschlüsselungsalgorithmus generiert symmetrischen Session-Key sendet diesen Session-Key verschlüsselt mit öffentlichem Host-Key Schritt 4 - Server: entnimmt Session-Key und schaltet auf Verschlüsselung um. Schritt 5 - Client: authentifiziert sich in geeigneter Weise (das ist der entscheidender Punkt! Es könnte ja jeder kommen.) :48:04 M. Leischner Netze, CS, 2. Semester Folie 9

10 SSH Protokollablauf vereinfacht Methoden der Clientauthentifizierung User-Passwort. uthentifizierung über öffentliche Schlüssel: User erzeugt im Vorfeld ein asymmetrisches Schlüsselpaar und hinterlegt seinen öffentlichen Schlüssel beim Server. Der öffentlicher Server-Schlüssel wird verschlüsselt mit dem geheimen Clientschlüssel an der Server geschickt und dort überprüft (Wie??) Verbesserungen bei SSH2: ufbau einer verschlüsselten Verbindung über ein ephemerales Diffie-Hellman- Verfahren. Ephemeral: Die Schlüssel gelten nur temporär und werden nach blauf der Verbindung weggeschmissen. Vorteil: Verbindungen können nachträglich nicht mehr entschlüsselt werden ( Perfect Forward Secrecy (PFS)) Nachteil: recht aufwändig. Es sind nur bessere lgorithmen zugelassen :48:04 M. Leischner Netze, CS, 2. Semester Folie 10

11 SSH praktische nwendung SSH über Passwort: 1. apt install openssh-server : SSH-Server installieren. 2. jetzt kann man sich per ssh/putty und mit Passwort in Server einwählen. efehl hierfür: ssh user@server. SSH auf öffentliche Schlüssel umstellen: 1. Man benötigt ein Schlüsselpaar (falls nicht vorhanden, dieses z.. mit sshkeygen -t rsa -b 4096 erzeugen). 2. Den öffentlichen Schlüssel per SCII (ssh-rsa...) als erste bzw. weitere Zeile in die Server-Datei ~/.ssh/authorized_keys des Homeverzeichnisses des enutzers eintragen. 3. Den geheimen Schlüssel in ssh/putty verfügbar machen. (ei ssh den geheimen Schlüssel in die Standard-Datei ~/.ssh/id_rsa kopieren. 4. Zugriff mit öffentlichem Schlüssel testen, d.h. für ssh user@server wird kein Passwort mehr benötigt (obwohl Passwort noch aktiv) :48:04 M. Leischner Netze, CS, 2. Semester Folie 11

12 SSH praktische nwendung Passwortzugriff abschalten (da Sicherheitslücke): uf dem Server die Datei /etc/ssh/sshd_config wie folgt anpassen: ChallengeResponseuthentication no Passworduthentication no UsePM yes Zugriff testen. Fertig! :48:04 M. Leischner Netze, CS, 2. Semester Folie 12

Ähnliche Dokumente

Modul 10: Sicherer Remote-Zugriff über SSH

Modul 10: Sicherer Remote-Zugriff über SSH M. Leischner Netze, BCS, 2. Semester Folie 1 Security-Mgmt Sicherheit im Internet-Protokollstack pp SSH/TLS TCP IPSEC IP Schicht 1/2 System pp SSH/TLS TCP IPSEC