Tutorials - Secure SSH Tutorial Part 1: Host Key
Sprachenübersicht/Betriebssysteme/Linux/Security
Secure SSH Tutorial Part 1: Host Key
Diese Seite wurde 71092 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
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 authentifizierte und verschlüsselte Verbindung zwischen zwei Rechnern.
Diese Artikelserie beschäftigt sich mit dem Sicherheitsaspekt, und mit nützlichen Features von SSH. In den Artikeln wird eine freie Implementierung von SSH, OpenSSH benutzt.
Das OpenSSH Packet finden Sie unter www.openssh.com/, oder im Packetverzeichniss 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 Packetverwaltungssystem RPM installiert ist, müssen Sie das Packet (google: gnupg .rpm "index of") nur herunterladen, und es ausführen.
- Source Code
Wir suchen als erstes einen Mirrorserver unter www.openssh.com/portable.html aus, und kopieren den Dateinamen der neusten .tar.gz.
Ich benutze in meinem Fall openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/, und openssh-4.1p1.
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 man unter www.openssl.org/ herunterladen werden, hier ist ein Tutorial zur Installation.
SSH ist ein Protokoll, das andere, nicht-verschlüsselte Protokolle ablösen soll: Telnet, FTP, RSH, ... Diese Protokolle haben alle Daten, auch Passwörter, und andere kritische Daten unverschlüsselt versendet. Ein Cracker an einer Schlüsselposition im Netzwerk kann alle unverschlüsselten Verbindungen abfangen und die Pakete loggen und austauschen.
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 jetzt eine sichere Verbindung aufgebaut.
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 verschlüsselt der key eines vertrauenswürdiger Server mit seinem private key, mit dem public key des Zertifikat Servers (der jedem bekannt ist); kann man den key wieder entschlüsseln, nennt man das signieren.
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 richtig 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 automatisch hinzu, ohne danach zu fragen.
Meistens eine extrem schlechte Wahl.
- StrictHostKeyChecking=yes
Das ist die sicherste, aber auch unfreundlichste Option: Wenn kein host key local 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.
SSH liefert mehrere Protokoll Typen 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 and private key, die Zweite nur den public key.
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 host key testen beim localhost 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
Archiv-Version: View only!
