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
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.
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.
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=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.
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.
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
Archiv-Version: View only!
