Tutorials - Secure SSH Tutorial Part 1: Host Key

Sprachenübersicht/Betriebssysteme/Linux/Security

Secure SSH Tutorial Part 1: Host Key

Diese Seite wurde 71087 mal aufgerufen.

Dieser Artikel wurde in einem Wikiweb System geschrieben, das heißt, Sie können die Artikel jederzeit editieren, wenn Sie einen Fehler gefunden haben, oder etwas hinzufügen wollen.

Editieren Versionen Linkpartnerschaft Bottom Printversion

Keywords: SSH, secure, OpenSSH, host key

Abbildung

Inhaltsverzeichnis



Tutorials in dieser Artikelserie Top








Einführung Top



SSH, oder Secure SHell ist ein Programm und ein Netzwerkprotokoll. Mit SSH ist es zum Beispiel möglich, sich auf einem anderen Computer einzuloggen und dort Programme auszuführen. SSH ermöglicht eine sichere Verbindung zwischen zwei Rechnern durch Authentifizierung und Verschlüsselung.

Diese Artikelserie beschäftigt sich mit den Sicherheitsaspekten und mit nützlichen Features von SSH. In den Artikeln wird eine freie Implementierung von SSH, OpenSSH benutzt.

Installation Top



Das OpenSSH Paket finden Sie unter www.openssh.com/, oder im Paketverzeichniss Ihrer Distribution.

Die meisten Distributionen installieren OpenSSH standardmässig oder fragen zumindest danach.

  • Debian

    Hier reicht ein apt-get install ssh.



  • RedHat RPM

    Wenn das Paketverwaltungssystem RPM installiert ist, müssen Sie das Paket (google: \"index of\" gnupg .rpm) nur herunterladen und es ausführen.



  • Sourcecode

    Sie suchen als erstes einen Mirrorserver unter www.openssh.com/portable.html aus und laden den aktuellsten Tarball (Datei mit der Endung "tar.gz") herunter.

    Ich benutze in meinem Fall openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/, und openssh-4.1p1.tar.gz

    Als nächstes laden wir die Souces herunter und testen ob die Datei beschädigt ist:

    Code:


    workstation:~# wget http://openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/openssh-4.1p1.tar.gz
    workstation:~# tar -xzvf openssh-4.1p1.tar.gz
    workstation:~# cd openssh-4.1p1
    workstation:~# ./configure --sysconfdir=/etc
    workstation:~# make
    workstation:~# make install



    Wenn Sie ein Problem mit der Installation haben, sollten Sie sich zuerst www.openssh.com/faq.html anschauen.

    ./configure schlägt fehl, wenn OpenSSL nicht installiert ist. OpenSSL kann unter www.openssl.org/ herunterladen werden, unter hier finden Sie ein Tutorial zur Installation.



Host Keys und die Man-In-The-Middle Theorie Top



SSH ist ein Protokoll, das andere, nicht-verschlüsselte Protokolle ablösen soll: Telnet, FTP, RSH, ... Diese Protokolle versenden alle Daten, auch Passwörter und andere kritische Daten, unverschlüsselt. Ein Cracker an einer Schlüsselposition im Netzwerk kann alle unverschlüsselten Verbindungen abfangen, die Pakete loggen, austauschen und bekommt somit sämtliche sensible Daten, wie eben Passwörter und Logindaten, die besser verschlüsselt gehören.

SSH funktioniert nach den Prinzipien der Public-Key-Kryptographie, auch asymmetrische Verschlüsselung genannt. D.h. der Server sendet zuerst seinen Public Key, der Client bekommt diesen und sendet seinen Public Key verschlüsselt zurück. Die Nachrichten, die mit dem Public Key verschlüsselt wurden, können nur mit dem Private Key entschlüsselt werden und umgekehrt, deshalb ist diese Verbindung sicher.

Aber was passiert, wenn zwischen der Verbindung ein Proxy-Server steht und die Verbindung abgefangen wird? Der Proxy-Server schickt dem Client seinen Public Key und öffnet eine Verbindung zum SSH-Server. Das ist das Problem der asymmetrischen Verschlüsselung und deshalb verwendet man in anderen Protokollen, wie z.B. HTTPS (Secure HTTP), Zertifikate.

Bei einem Zertifikat wird der Public Key des Zertifikatinhabers mit dem Private Key eines vertrauenswürdigen Servers signiert. Mit dem Public Key des vertrauenswürdigen Servers kann man die Verschlüsselung überprüfen; dadurch wird gewährleistet, dass der Public Key zum Zertifikatinhabers passt. Dies gilt nur, wenn der vertrauenswürdige Server vertrauenswürdig ist.

Der Public Key der großen Zertifikate-Server ist dem Client bekannt und wird vom Browser mitgeliefert.

Die Lösung mit den Zertifikaten wird bei SSH-Servern nicht benutzt, deshalb ist es wichtig, dass wir den Key des Servers kennen, wenn wir eine Verbindung mit ihm eingehen.

Schauen wir mal, was passiert, wenn wir zum ersten Mal zu einem Server verbinden:

Code:


workstation:~# ssh my-ssh-server.com
The authenticity of host 'my-ssh-server.com (127.0.0.1)' can't be established.
RSA key fingerprint is a6:33:ff:28:d6:fb:4b:66:16:b9:d1:b3:ea:58:77:a5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'my-ssh-server.com'(RSA) to the list of known hosts.



Zuerst wird eine Verbindung zum Server aufgebaut; der schickt uns seinen Host-Key zurück. Danach zeigt SSH den Fingerprint des Keys an, und fragt uns, ob wir den Fingerprint (Signatur des Keys) akzeptieren. Wenn wir akzeptieren, speichert SSH den key in $HOME/.ssh/known_hosts und in einer globalen Datei, meistens /etc/ssh/known_hosts. Wenn sich der Public Key des Servers ändert, zeigt uns SSH beim nächsten Mal eine Warnung an, dass sich der Key geändert hat.

Die Sicherheit der Verbindung wird also nur durch diesen Fingerprint gewährleistet. Deshalb ist es wichtig, dass wir uns sicher sind, dass es der richtige Key zum Server ist.

Am besten ist es, wenn man den Fingerprint aufschreibt und immer dabei hat, wenn man sich von einem PC einloggt, der noch nie mit dem SSH-Server verbunden war oder den Key per HTTPS speichert.

SSH hat einen Parameter, mit dem man das Behandeln von falschen oder unbekannten Host Keys einstellen kann: StrictHostKeyChecking

  • StrictHostKeyChecking=no

    Diese Option bewirkt, dass SSH blindlings zum Server connected. Sie fügt den Key automatisch lokal hinzu, und wenn der Key geändert wurde, gibt SSH eine Warnung aus und fügt den Key ohne danach zu fragen hinzu.

    Meistens eine extrem schlechte Wahl.



  • StrictHostKeyChecking=ask

    Die Standard-Einstellung. Wenn kein Key gefunden wird, wird der Fingerprint angezeigt, und nach Ihrem Einverständnis gefragt. Wenn der Key geändert wurde, wird eine Warnung angezeigt:

    Code:


      workstation:~# ssh -o stricthostkeychecking=my-ssh-server.com
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
      Someone could be eavesdropping on you right now (man-in-the-middle attack)!
      It is also possible that the RSA host key has just been changed.
      The fingerprint for the RSA key sent by the remote host is
      a6:33:ff:28:d6:fb:4b:66:16:b9:d1:b3:ea:58:77:a5.
      Please contact your system administrator.
      Add correct host key in /home/simon/.ssh/known_hosts to get rid of this message.
      Offending key in /home/simon/.ssh/known_hosts:8
      RSA host key for localhost has changed and you have requested strict checking.
      Host key verification failed.



  • StrictHostKeyChecking=yes

    Das ist die sicherste, aber auch unfreundlichste Option: Wenn kein Host Key lokal gespeichert ist, wird abgebrochen.



Ein veränderter Host Key muss nicht immer heißen, dass die Verbindung unsicher ist. Der Server könnte z.B. von der unsicheren Version SSH1 auf SSH2 gewechselt haben, oder der Rechner wurde neu aufgesetzt.

Host Key Varianten Top



SSH liefert mehrere Protokolltypen mit, generell SSHv1 (RSA), und SSHv2 (RSA oder DSA); ein SSH Server kann alle drei Algorithmen benutzen.



In der sshd_config tragen wir ein, welche Schlüssel wir verwenden wollen:

sshd_config:


# Welche(s) Prokoll(e) wollen wir unterstützen (1, 2, oder 2 und 1)
Protocol 2,1
  
# Host keys für SSH1
HostKey /etc/ssh/ssh_host_key

# Host key für SSH2
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa_key



Falls die Keys noch nicht generiert sind, generieren wir sie mit ssh-keygen:

Code:


workstation:~# ssh-keygen -t rsa /etc/ssh/ssh_host_rsa_key
workstation:~# ssh-keygen -t dsa /etc/ssh/ssh_host_dsa_key
workstation:~# ssh-keygen -t rsa1 /etc/ssh/ssh_host_key



ssh-keygen erstellt zwei Dateien pro Schlüssel, die erste Datei enthält den Public- und den Private Key, die zweite Datei nur den Public Key.

Weitere Optionen Top



Es gibt noch ein paar andere Sicherheitsoptionen für den SSH Client, die in der globalen Datei /etc/ssh/ssh_config oder in der lokalen Datei $HOME/.ssh/config sind. man ssh_config gibt über die Parameter genauer Auskunft.

Options:


CheckHostIP: Testet ob die IP des Servers in der known_host Datei ist.

NoHostAuthenticationForLocalhost: Eine nützliche Option für Port Forwards, die das Testen des Host Keys auf localhost (127.0.0.1) unterbindet.



So, ich hoffe das erste Tutorial hat einen schönen Einblick in die Host Key-Verwaltung von SSH gegeben. In Part 2 wird es wahrscheinlich um die Userverwaltung gehen.

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?

Editieren Versionen Linkpartnerschaft Top Printversion

Haben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Security/Secure SSH Tutorial Part 1: Host Key