SSH Tutorial :)
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
Das OpenSSH Paket finden Sie unter
, 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
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*
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
anschauen. ./configure schlägt fehl, wenn OpenSSL nicht installiert ist. OpenSSL kann unter
herunterladen werden, unter hier finden Sie ein Tutorial zur Installation.Host Keys und die Man-In-The-Middle Theorie
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.
Anzeigen
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 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ändniss 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*CHA NGED!
**@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
**IT*IS*POSSIBLE*THAT*SOMEONE*IS*DOING*SOMETHING*N ASTY!
**Someone*could*be*eavesdropping*on*you*right*now* (man-in-the-middle*attack)!
**It*is*also*possible*that*the*RSA*host*key*has*ju st*been*changed.
**The*fingerprint*for*the*RSA*key*sent*by*the*remo te*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*h ave*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
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
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*k nown_host*Datei*ist.
NoHostAuthenticationForLocalhost:*Eine*nützliche*O ption*für*Port*Forwards,*die*das*Testen*des*Host*K eys*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.
