|
|
| (17 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| == SSH Host Keys - nervig oder sinnvoll? ==
| | '''{{BASEPAGENAME}}''' - Beschreibung |
| Bei der allerersten Verbindung zu einem Server per SSH bekommt man eine Meldung wie diese:
| |
|
| |
|
| The authenticity of host ‚www.example.com (192.168.12.34)‘ can’t be established. | | == Beschreibung == |
| ECDSA key fingerprint is SHA256:86RDANuVFu5w3OF4RuFW04jqMfVbahR/sk4Yr/ElLI0. | | ; SSH Host Keys - nervig oder sinnvoll? |
| Are you sure you want to continue connecting (yes/no)? | | Bei der ersten Verbindung zu einem Server per SSH bekommt man eine Meldung wie diese: |
| | |
| | The authenticity of host ‚www.example.com (192.168.12.34)‘ can’t be established. |
| | ECDSA key fingerprint is SHA256:86RDANuVFu5w3OF4RuFW04jqMfVbahR/sk4Yr/ElLI0. |
| | Are you sure you want to continue connecting (yes/no)? |
|
| |
|
| Die man dann nach dem klassischen Schema Ja/Nein/Weiss nicht/Hab Angst beantworten kann. | | Die man dann nach dem klassischen Schema Ja/Nein/Weiss nicht/Hab Angst beantworten kann. |
| * Was genau ist der Sinn dieser SSH Host Keys und der oben gestellten Frage? | | * Was genau ist der Sinn dieser SSH Host Keys und der oben gestellten Frage? |
|
| |
|
| === SSH Host Keys sind dafür da um den Host auf dem der SSH Server läuft eindeutig zu identifizieren. === | | === Server identifizieren === |
| | ; SSH Host Keys sind dafür da um den Host auf dem der SSH Server läuft eindeutig zu identifizieren |
| Im Idealfall würde man beim ersten Verbindungsaufbau den Fingerprint des Host Keys überprüfen, also beispielsweise: mit dem Administrator des Servers den Fingerprint per Telefon vergleichen. | | Im Idealfall würde man beim ersten Verbindungsaufbau den Fingerprint des Host Keys überprüfen, also beispielsweise: mit dem Administrator des Servers den Fingerprint per Telefon vergleichen. |
| * Dadurch wäre dann sichergestellt dass man sich mit dem richtigen Server verbunden hat und man nicht von einem Angreifer auf eine andere Maschine umgeleitet wurde. | | * Dadurch wäre dann sichergestellt dass man sich mit dem richtigen Server verbunden hat und man nicht von einem Angreifer auf eine andere Maschine umgeleitet wurde. |
| Zeile 36: |
Zeile 40: |
| SSH Keys mögen zwar nervig erscheinen aber wenn man nicht selbst grob fahrlässig agiert können sie einen vor Angriffen auf die Verbindung bewahren. | | SSH Keys mögen zwar nervig erscheinen aber wenn man nicht selbst grob fahrlässig agiert können sie einen vor Angriffen auf die Verbindung bewahren. |
|
| |
|
| == SSH Host Key Signing - ein unterschätztes Feature == | | == Anwendung == |
| Da wir eine größere Menge an Linux Servern betreiben, ist SSH unser tägliches Brot.
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| * Sei es nun für den Login mit dem eigenen Benutzer oder für auf SSH aufsetzende Automatisierungen, wie zum Beispiel Ansible.
| | </syntaxhighlight> |
| * Was nun jeder SSH Anwender aber kennt: der ewige "Kampf" mit der ''known_hosts'' Datei, in der alle dem Clients bereits bekannten Public SSH Host Keys abgelegt werden.
| |
| * Wenn sie noch nicht dort liegen, stolpert man über eine interaktive Nachfrage (der Feind jeglicher Automatisierung) und wenn das Ziel zum Beispiel neu aufgesetzt wurde, gibt es sogar einen Konflikt, der eher umständlich aufgelöst werden muss.
| |
| * Im Falle von Ansible Playbooks oder Git Operationen kann das bedeuten, dass Befehle unerwartet abbrechen, mit Rückfragen stehen bleiben oder aber einfach in einen Timeout laufen, weil die Rückfrage gar nicht bis zum Benutzer durchkommt.
| |
| * Dann ist da auch noch die Frage, in welcher Form ein "conflicting" Public Host Key in der ''known_hosts'' hinterlegt ist: mit einer IP Adresse, einem Hostnamen oder einem Hash davon als Identifier? Für einfache Aufräumarbeiten gibt die entsprechende Fehlermeldung des ssh Clients immerhin direkt das passende, copy/paste-bare Kommando (''ssh-keygen -R […]'') mit aus.
| |
| | |
| Für das Problem gibt es verschiedene Lösungen, die sich grob in "The Good" (zum Beispiel SSH Host Key Signing), "The Bad" (''known_hosts'' Management) und "The Ugly" (Host Key Checking abschalten?!) einteilen lassen.
| |
| * Die letzte Variante ignorieren wir hier einmal, weil das für uns schlicht keine Option ist.
| |
| | |
| ==== "managed" known_hosts ====
| |
| Bevor wir SSH Host Key Signing entdeckt haben, hat Ansible uns in Teilen geholfen.
| |
| * Beim initialen Setup eines Servers haben wir über ''delegate_to'' Tasks dafür gesorgt, dass auf bestimmten, für Configuration Management/Deployment relevanten Systemen, die ''known_hosts'' Dateien einiger Benutzer um die Public Host Keys des neuen Servers erweitert wurden.
| |
| * Das funktioniert allerdings immer nur so lange automatisch, bis ein Server mal neu aufgesetzt wird und dann am Ende zwei Keys für das gleiche Ziel in der ''known_hosts'' landen - schon musste wieder händisch eingegriffen wird.
| |
| * Bevor wir die vorhandene Lösung noch komplizierter machen mussten, sind wir zum Glück über das folgende Thema gestolpert:
| |
| | |
| ==== SSH Host Key Signing ====
| |
| OpenSSH beherrscht seit ca. 2010 ein Verfahren, um SSH Host Keys mit einer CA zu signieren.
| |
| * Es handelt sich dabei aber nicht um eine x509 CA, sondern um eine eigene Implementierung - sämtliche Interaktionen erfolgen über das Tool ''ssh-keygen''.
| |
| | |
| Insgesamt sind folgende Schritte nötig, um an das Ziel zu gelangen:# SSH CA erzeugen
| |
| # Neuen Server aufsetzen, Public Host Key(s) zur CA transferieren und signieren
| |
| # Signierte Public Key(s) auf neues System legen, in SSHD Konfiguration aktivieren
| |
| # Public Key der SSH CA in allen ''known_host'' Dateien (beispielsweise systemweit) hinterlegen
| |
| | |
| Die Schritte 2. und 3. sind für jeden neuen Server zu wiederholen und lassen sich relativ leicht mit Ansible automatisieren.
| |
| | |
| ==== SSH CA erzeugen ====
| |
| Die CA kann auf einem beliebigen aktuellen Linux System erzeugt/betrieben werden - spezielle Anforderungen gibt es nicht.
| |
| * Da auf diesem System allerdings der Private Key der CA liegt, sollte es natürlich nicht gerade der öffentlich erreichbare Webserver sein, sondern schon ein dedizierter und entsprechend abgeschotteter Server.
| |
| * Seit OpenSSH 5.5 kann eine CA allerdings auch über PKCS#11 abgerufen werden - und damit zum Beispiel in einem Hardware Security Module (HSM) liegen.
| |
| * Dieser Blogpost beleuchtet aber die einfache Variante mit einer CA im Dateisystem.
| |
| | |
| Hier erzeugen wir nun unsere CA:
| |
| | |
| mkdir /etc/ssh-ca && cd /etc/ssh-ca
| |
| ssh-keygen -f server_ca
| |
| | |
| Jetzt signen wir damit zuerst mal den Public Host Key unseres CA Servers, dazu benötigen wir den Fully Qualified Domain Name des Servers in unserer ''$FQDN'' Variable und den Hostnamen (ohne Domain) in der Variable ''$HOSTNAME'':
| |
| | |
| ssh-keygen -s server_ca -I ${FQDN}-host-key -h -n ${FQDN},${HOSTNAME} -V +52w /etc/ssh/ssh_host_ecdsa_key.pub
| |
| | |
| Durch den Parameter ''-V +150w'' geben wir an, dass das Zertifikat für 52 Wochen gültig sein soll, über ''-n'' wird mitgegeben, für welche(n) Hostnamen das Zertifikat gelten soll (hier nehmen wir mal den Fully Qualified Domain Namen sowie den kurzen Hostnamen an).
| |
| | |
| Der Vorgang erzeugt ein Host Zertifikat (oder auch genannt: ein signierter Public Key) in ''/etc/ssh/ssh_host_ecdsa_key-cert.pub''.
| |
| * Dieses Zertifikat müssen wir jetzt noch dem SSHD in der ''/etc/ssh/sshd_config'' beibringen und ihn danach neustarten:
| |
| | |
| HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
| |
| | |
| Wer neben ECDSA auch noch andere Host Key Varianten aktiviert hat, muss den Vorgang für diese Keys auch wiederholen (oder sie deaktivieren).
| |
| | |
| ==== Public Keys eines neuen Servers signieren ====
| |
| Um nun die Host Keys eines neuen Servers zu signieren, greifen wir auf einige Schritte von weiter oben zurück.
| |
| * Wir kopieren den Public ECDSA Host Key (''/etc/ssh/ssh_host_ecdsa_key.pub'') auf unser SSH CA System, zum Beispiel nach ''/etc/ssh-ca/ssh_host_ecsd_key.pub''.
| |
| * Anschließend führen wir den Sign-Befehl aus (auch hier benötigen wir wieder die beiden Variablen ''$FQDN'' und'' $HOSTNAME'', nur dieses Mal bezogen auf das System, von dem der Key stammt):
| |
| | |
| ssh-keygen -s server_ca -I ${FQDN}-host-key -h -n ${FQDN},${HOSTNAME}
| |
| -V +52w /etc/ssh-ca/ssh_host_ecdsa_key.pub
| |
| | |
| Das Ergebnis wird in ''/etc/ssh-ca/ssh_host_ecdsa_key-cert.pub'' liegen und kann zum Server zurück transferiert werden.
| |
| * Dort müssen wir es noch in der ''/etc/ssh/sshd_config'' aktivieren und den Dienst neustarten:
| |
|
| |
|
| HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
| | === Host-Keys erneuern === |
| | |
| Auch hier gilt: wenn mehr als eine Art von SSH Host Key benutzt wird (beispielsweise RSA), sollte man die Schritte für alle Keys wiederholen oder sie deaktivieren.
| |
| | |
| ==== Und die Clients? ====
| |
| Jedes System, welches nun als SSH Client agieren soll, benötigt Zugriff auf die SSH-CA - dies geschieht auch über die known_hosts.
| |
| * Um das Deployment zu vereinfachen, kann man einfach eine systemweite ''known_hosts'' in ''/etc/ssh/ssh_known_hosts'' pflegen.
| |
| * Der Inhalt setzt sich aus zwei Teilen zusammen:# Dem Prefix ''@cert-authority'' und einem Matcher auf einen Hostnamen (Wildcards sind möglich, wie in der ssh_config) - ein einzelnes "*" tuts auch, um die CA für sämtliche Clients anzuwenden
| |
| # Der Public Key unserer CA, der im SSH-CA Ordner unter dem Namen ''server_ca.pub'' erzeugt wurde
| |
| | |
| Das fertige Ergebnis könnte dann so aussehen:
| |
| | |
| @cert-authority * ssh-rsa AAAADje9fnekjsld[...]
| |
| | |
| ==== Das wars schon? ====
| |
| Tatsächlich ist das schon im großen und ganzen alles, was für eine SSH CA/SSH Host Key Signing notwendig ist.
| |
| * Es gibt natürlich auch andere Wege (beispielsweise über ein zentrales LDAP System).
| |
| * Wenn man diese Komplexität allerdings scheut, kommt man über die SSH CA sicherlich schneller zum Ziel - und alles ist besser, als Host Key Checking einfach zu deaktivieren, weil es an der Automatisierung hindert.
| |
| | |
| ==== Gültigkeit von Zertifikaten ====
| |
| Wie bei allen Dingen mit einer endlichen Gültigkeit: man möchte natürlich seine SSH Zertifikate regelmäßig erneuern und/oder auf ihre Gültigkeit überwachen.
| |
| * Wenn man das nicht tut, resultiert das zwar unseren Tests nach per Default nur in einer Warnung beim Login, sauber ist das allerdings nicht.
| |
| | |
| ==== Kann ich ein Zertifikat zurückziehen? ====
| |
| Wer Keys signed bzw. Zertifikate ausstellt, möchte diese eventuell auch wieder zurückziehen.
| |
| * Die bei OpenSSH KRL genannte "Key Revocation List" muss auf der SSH-CA gepflegt (mehr Details dazu in der Manpage von ''ssh-keygen'') und auf alle Clients verteilt werden.
| |
| * Auf den Clients kann man sie über die Direktive RevokedHostKeys in der ''/etc/ssh/ssh_config'' systemweit aktivieren.
| |
| | |
| ==== Wird jetzt alles gut? ====
| |
| Insgesamt kann man mit diesem Schritt Deployments/Config Management via SSH (lies: Ansible) deutlich stabiler machen.
| |
| * Das gleicht allerdings nicht zwingend andere Schwächen aus, die Mika Prokop hier jüngst mal zusammengestellt hat.
| |
| | |
| == ssh-Host-Keys erneuern ==
| |
| ssh-Server verfügen über einen Satz von Host-Keys, mit denen sich der Server gegenüber den Clients identifizieren kann. | | ssh-Server verfügen über einen Satz von Host-Keys, mit denen sich der Server gegenüber den Clients identifizieren kann. |
| * Nach dem ersten erfolgreichen Verbindungsaufbau legt der ssh-Client den Host-Key des Servers in der Datei <tt>~/.ssh/knownhosts</tt> ab. | | * Nach dem ersten erfolgreichen Verbindungsaufbau legt der ssh-Client den Host-Key des Servers in der Datei <tt>~/.ssh/knownhosts</tt> ab. |
| Zeile 145: |
Zeile 58: |
| * Sofern der neue Server den bisherigen Server ersetzt, ist dies unproblematisch. | | * Sofern der neue Server den bisherigen Server ersetzt, ist dies unproblematisch. |
| * Sofern man einen neuen, zusätzlichen Server aufbaut, dann sollte dieser Server einen neuen Satz mit eigenen einmaligen ssh-Host-Key erhalten. | | * Sofern man einen neuen, zusätzlichen Server aufbaut, dann sollte dieser Server einen neuen Satz mit eigenen einmaligen ssh-Host-Key erhalten. |
| | |
| | ; How to change a SSH host key? |
| | # In manchen Quellen wird für das Generieren der neuen Keys der Befehl <tt>dpkg-reconfigure openssh-server</tt> verwendet, der das Software-Paket für den ''OpenSSH''-Server neu konfiguriert. |
| | #* Es sollte jedoch ein <tt>ssh-keygen -A</tt> ausreichen, der den Satz ssh-Host-Keys um die fehlenden Typen ergänzt. |
| | Die erste Variante setzt voraus, dass ein ''OpenSSH''-Server verwendet wird, während die zweite Variante allgemeingültig sein sollte. |
| | # Der ssh-Client gibt in den Warnungen die entsprechende Zeilennummer aus. |
|
| |
|
| === Keys ersetzen === | | === Keys ersetzen === |
| Zeile 175: |
Zeile 94: |
| sed -i.bak '99d' known_hosts | | sed -i.bak '99d' known_hosts |
|
| |
|
| === Quellen === | | == Konfiguration == |
| * cyberciti.biz: How To: Ubuntu / Debian Linux Regenerate OpenSSH Host Keys
| | === Dateien === |
| * serverfault: How to change a SSH host key?
| | {| class="wikitable options big" |
| | | |- |
| 1)
| | ! Datei !! Beschreibung |
| | | |- |
| In manchen Quellen wird für das Generieren der neuen Keys der Befehl <tt>dpkg-reconfigure openssh-server</tt> verwendet, der das Software-Paket für den ''OpenSSH''-Server neu konfiguriert.
| | | || |
| * Es sollte jedoch ein <tt>ssh-keygen -A</tt> ausreichen, der den Satz ssh-Host-Keys um die fehlenden Typen ergänzt.Die erste Variante setzt voraus, dass ein ''OpenSSH''-Server verwendet wird, während die zweite Variante allgemeingültig sein sollte.
| | |- |
| | | | || |
| 2)
| | |} |
| | |
| Der ssh-Client gibt in den Warnungen die entsprechende Zeilennummer aus.
| |
| | |
| = TMP = | |
| == Secure SSH Tutorial Part 1: Host Key == | |
| === Einführung === | |
| 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 ===
| | <noinclude> |
| 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.
| | == Anhang == |
| | === Siehe auch === |
| | <div style="column-count:2"> |
| | <categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree> |
| | </div> |
| | ---- |
| | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
|
| |
|
| * RedHat RPM Wenn das Paketverwaltungssystem RPM installiert ist, müssen Sie das Paket (google: \"index of\" gnupg .rpm) nur herunterladen und es ausführen.
| | === Dokumentation === |
| | ; Man-Page |
| | # [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)] |
|
| |
|
| * 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: <br/>Code:workstation:~# wget https://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 <br/>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.
| | ; Info-Pages |
| * 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 beispielsweise 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: <br/>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 beispielsweise
| |
| * 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:<nowiki># Welche(s) Prokoll(e) wollen wir unterstützen (1, 2, oder 2 und 1) </nowiki>Protocol 2,1 <nowiki># Host keys für SSH1 </nowiki>HostKey /etc/ssh/ssh_host_key <nowiki># Host key für SSH2 </nowiki>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 PrintversionHaben 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
| |
| | |
| == Secure SSH Tutorial Part 2: Identity/Pubkey Authentifizierung ==
| |
| Sprachenübersicht/Betriebssysteme/Linux/SecuritySecure SSH Tutorial Part 2: Identity/Pubkey AuthentifizierungDiese Seite wurde 28209 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, Identity/Pubkey Authentifizierung, identity, pubkey, authentication
| |
| | |
| === Vorwort Top ===
| |
| Im ersten Teil dieser Tutorialserie ging es um die sichere Verwaltung des Host-Schlüssels, dieser Teil beschäftigt sich mit Identity/Pubkey Authentifizierung unter SSH.
| |
| | |
| === Einführung Top ===
| |
| OpenSSH - wenn ich in diesem Tutorial den Begriff SSH verwende, meine ich eigentlich immer OpenSSH - unterstützt einige nützliche Dinge zur Authentifizierung der Benutzer.
| |
| * Wir schauen uns jetzt die "Identity/Pubkey Authentifizierung" an.
| |
| * Bei dieser Methode ersetzen wir die normale Vorgehensweise, statische Passwörter zu benutzen, die mit einem Keylogger abgehört werden können.
| |
| * Alles, was wir brauchen, ist ein Schlüsselpaar auf der Festplatte, mit dem wir uns authentifizieren.
| |
| * Der SSH-Server hat die Identities/Pubkeys, welchen er vertraut, in einer Liste.
| |
| * Vorteile: - Ein Keylogger reicht nicht mehr, da der private Key und die Passphrase benötigt werden - Bruteforce- und Directoryhacks funktionieren nicht mehr
| |
| | |
| === Identity/Pubkey erstellen Top ===
| |
| Wie schon im ersten Teil erwähnt, gibt es drei Typen von Protokollen, die wir verwenden können:
| |
| | |
| Code: - RSA1 Parameter: -t rsa1 Standarddateiname: identity Protokoll: SSH 1 - RSA Parameter: -t rsa Standarddateiname: id_rsa Protokoll: SSH 2 - DSA Parameter: -t dsa Standarddateiname: id_dsa Protokoll: SSH 2
| |
| | |
| Wir erstellen das Schlüsselpaar wie gewohnt mit ssh-keygen:
| |
| | |
| Code: workstation:/home/simon# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/simon/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/simon/.ssh/id_rsa. Your public key has been saved in /home/simon/.ssh/id_rsa.pub. The key fingerprint is: 01:4a:69:4a:81:16:f2:b9:aa:41:da:55:af:dd:34:ce simon@workstation workstation: workstation:/home/simon# cd $HOME/.ssh/ workstation:~/.ssh# ls id_rsa id_rsa.pub
| |
| | |
| Jetzt sehen wir die zwei Dateien, die ssh-keygen erstellt hat: id_rsa, und id_rsa.pub.
| |
| * Die erste Datei ist der Private Key und ist mit der Passphrase geschützt, die zweite Datei (.pub) ist der Public Key.
| |
| | |
| === Identity/Pubkey zum Server hochladen Top ===
| |
| Jetzt schicken wir den Public Key dem Server, dazu verwenden wir scp, ein Tool von SSH, welches für Filetransfer gedacht ist:
| |
| | |
| Code: workstation:/# cd $HOME/.ssh/ workstation:/home/simon/.ssh# scp id_rsa.pub simon@ssh-server:id_rsa_workstation.pub Password: workstation:/home/simon/.ssh# ssh ssh-server -L simon Password: ssh-server:/ cd $HOME ssh-server:/home/simon# mkdir .ssh && chmod 700 .ssh && cd .ssh <nowiki>#Jetzt fügen wir die Datei hinzu, die wir hochgeladen haben </nowiki>ssh-server:/home/simon/.ssh# cat ../id_rsa_workstation.pub >> authorized_keys ssh-server:/home/simon/.ssh# chmod 600 authorized_keys ssh-server:/home/simon/.ssh# rm ../id_rsa_workstation.pub && exit
| |
| | |
| === Identity/Pubkey Authentifizierung auf dem Server einstellen Top ===
| |
| Jetzt wollen wir auf dem SSH-Server einstellen, dass der Server Identity/Pubkey erlaubt.
| |
| * Dazu editieren wir die sshd_config
| |
| | |
| sshd_config:<nowiki>#SSH version 1 Identity Authentifizierung </nowiki>RSAAuthentication yes <nowiki>#SSH version 2 Pubkey Authentifizierung </nowiki>PubkeyAuthentication yes <nowiki>#Der Aufbewahrungsort der Schlüssel, ohne führenden Slash liegen sie relativ zum Home-Verzeichnis. </nowiki>AuthorizedKeysFile .ssh/authorized_keys
| |
| | |
| Nach einem Neustart des Servers sollte der SSH-Server Identity/Pubkey Authentifizierung erlauben.
| |
| * Jetzt können wir noch die normale Passwort-Authentifizierung abschalten:
| |
| | |
| sshd_config: PasswordAuthentication no UsePAM no
| |
| | |
| Nachdem wir jetzt alles vorbereitet haben, können wir den Unterschied ausprobieren:
| |
| | |
| Code: workstation:/# ssh ssh-server Enter passphrase for key '/home/simon/.ssh/id_rsa':
| |
| | |
| Mit dem Parameter -v können wir übrigens sehen, was passiert, wenn wir uns mit einem SSH-Server verbinden.
| |
| | |
| === Schlüsselpaar auswählen Top ===
| |
| Mit dem Parameter -I <keyfile> können wir den Schlüssel auswählen, der für die Identity/Pubkey Authentifizierung verwendet wird:
| |
| | |
| Code: workstation:/# ssh -i ~/.ssh/ssh_key ssh-server Enter passphrase for key '/home/simon/.ssh/ssh_key':
| |
| | |
| Standardmäßig lässt sich das in der Datei ~/.ssh/config eintragen:
| |
| | |
| Code: Host ssh-server IdentityFile ~/.ssh/special_ssh_key
| |
| | |
| === Ratschläge Top ===
| |
| Der angelegte Schlüssel sollte eine Passphrase benutzen, damit der Schlüssel geschützt ist, die Passphrase wird zum Entschlüsseln des Schlüssels benutzt, ohne diese Passphrase hat jeder, der an den Private Key kommt, vollständigen Zugriff auf den SSH-Server.
| |
| * Wie man sich bei einem SSH-Server mit einer Passphrase einloggen kann, ohne ein Passwort eintippen zu müssen, wird wahrscheinlich im nächsten oder übernächsten Artikel gezeigt.
| |
| * Bei älteren Versionen von ssh kann es vorkommen, dass authorized_keys für SSHv1 und authorized_keys2 für SSHv2 benutzt wird, ein Hardlink, der mit ln authorized_keys authorized_keys2 erzeugt wird, löst dieses Problem.
| |
| | |
| Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?Editieren Versionen Linkpartnerschaft Top PrintversionHaben 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 2: Identity/Pubkey Authentifizierung
| |
| | |
| == Secure SSH Tutorial Part 3: Usage ==
| |
| === Vorwort Top ===
| |
| Im ersten Teil dieser Tutorialserie ging es um die sichere Verwaltung des Host-Schlüssels, der zweite Teil beschäftigt sich mit Identity/Pubkey Authentifizierung unter SSH.
| |
| * Dieser Teil soll den Umgang mit den Tools, die SSH zur Verfügung stellt lehren, und basiert auf den ersten zwei Tutorials.
| |
| | |
| === ssh - remote login program Top ===
| |
| ssh ist ein Programm, mit dem man sich mit einem anderen Computer verbindet, und ihn fernsteuert.
| |
| * ssh wurde entwickelt um Programme wie z.B rlogin, oder rsh mit einem verschlüsselten Protokoll zu ersetzen.
| |
| * ssh unterstüzt auch X11 forwarding, damit kann man die grafische Ausgabe von Linux übertragen.
| |
| * Hier ist eine Auflistung der für uns relevanten Parameter: ssh [-p Port] [-l login_name] [user@]hostname [command] Falls command angegeben wird, wird dieser Befehl anstelle der login shell gestartet. -p <Port> gibt den Port an, auf dem der SSH-Server läuft, -l <login_name>, und [user@] den Benutzername, mit dem man sich auf dem System anmeldet, und hostname die IP-Adresse, oder den hostname des Systems.
| |
| * Als Beispiel:
| |
| | |
| Code:workstation:/home/simon# ssh -l simon -p 443 localhost Password: Linux vsn-server 2.6.11 #3 SMP Thu Mar 3 22:27:04 CET 2005 i686 unknown Most of the programs included with the Debian GNU/Linux system are freely redistributable; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
| |
| * Last login: Wed Aug 17 16:01:26 2005 from 192.168.0.2 simon@vsn-server:~$
| |
| | |
| Wie man ein Identity/Pubkey auswählt, wird hier im Teil 2 beschrieben.
| |
| * Die Behandlung von Schlüsseln wird in den ersten Tutorial ausreichend beschrieben.
| |
| | |
| === scp - remote file copy program Top ===
| |
| scp kopiert Dateien zwischen dem ssh server, und dem localhost verschlüsselt über ein Netzwerk.
| |
| * Wichtige Parameter: <nowiki>scp [-l limit] [-r] [-P port] [-S program] [[user@]host1:]file1 [...] [[user@]host2:]file2 </nowiki>-l <limit> setzt die Bandbreite auf <limit> Kbit/s. -P <Port> gibt den Port des ssh-servers an. -r kopiert die Dateien rekursiv (d. h. mit allen Unterverzeichnissen).
| |
| * Beispiel:
| |
| | |
| Code:workstation:/home/simon# scp datei.txt simon@vsn-server:/home/simon/files/
| |
| | |
| kopiert die Datei datei.txt aus dem aktuellen Ordner auf den ssh-server (vsn-server) in das Verzeichnis /home/simon/files.
| |
| * Natürlich lassen sich so Dateien auch auf den Server kopieren, etwas was wir im zweiten Tutorial gemacht haben:
| |
| | |
| Code:workstation:/home/simon# scp -r simon@vsn-server:/home/simon/files/ /home/simon/incoming
| |
| | |
| kopiert die Dateien aus /home/simon/files vom ssh-server rekursiv in das lokale Verzeichnis /home/simon/incoming.
| |
| | |
| === ssh - forwarding Top ===
| |
| Ein weiteres Feature von SSH ist Port Forwarding, damit kann man beispielsweise auf einen unverschlüsselten Dienst auf dem Server verschlüsselt zugreifen, oder eine verschlüsselte Verbindung zum Server aufbauen, und den Server dann als Proxy benutzen.
| |
| * Es gibt 2 Arten von forwarding in SSH: * Local-Forward Nehmen wir an wir haben in Australien einen Mail-Server.
| |
| * Wenn wir eine normale Verbindung über 110 mit ihm aufbauen, dann werden die Daten unverschlüsselt zum Server übertragen.
| |
| * Deshalb bauen wir mit dem SSH-Server eine Verbindung auf, und öffnen eine Verbindung vom lokalen Port 123 über den SSH Tunnel zum Port 110 auf dem Mailserver. [workstation:123] -> verschlüsseln -> [ssh-server] -> unverschlüsselt [mailserver:110] Der Mailserver kann natürlich (im besten Fall) auch der SSH-Server sein Dafür machen wir folgendes: <br/>Code:workstation:/home/simon# ssh -l simon -L 123:mailserver:110 ssh-server simon@ssh-server's password: ssh-server:/home/simon# <br/>Solange diese Verbindung offen ist, hält SSH den lokalen Port 123 offen, deshalb lassen wir das Fenster jetzt offen, und öffnen ein neues: <br/>Code:workstation:/home/simon# telnet 127.0.0.1 123 +OK Hello there.
| |
| * USER blablab@babala.com +OK Password required.
| |
| * PASS hallo +OK logged in. <br/>Jetzt wird unsere Verbindung bis zum ssh-server, der bestenfalls unser mailserver ist, verschlüsselt.
| |
| * Mit -g, oder GatewayPorts yes in der Datei ~/.ssh/config oder /etc/ssh/ssh_config wird der Port 123 übrigens nicht nur lokal, sondern global an localhost gebunden.
| |
| | |
| * Remote-Forward Remote-Forwarding ist genau der umgekehrte Weg.
| |
| * Nehmen wir an, wir haben bei der Arbeit eine Windows Kiste, und wir wollen zuhause weiter Arbeiten.
| |
| * Leider lässt die Firewall Verbindungen nach innen nicht zu.
| |
| * Jetzt kommt SSH ins Spiel: Wir bauen eine Verbindung nach Hause (Linux Box) auf, und leiten den Port 445 vom Büro nach Hause auf 123 um: Zuerst müssen wir in der .ssh/config Datei auf der Arbeit den Port-Forward freigeben: <br/>~/.ssh/config:Host samba-tunnel-home Hostname ip-at-home RemoteForward 123:localhost:445 User simon <br/>Jetzt können wir uns von der Arbeit zuhause einloggen, und alle paar Sekunden etwas nach Hause schicken, damit die Verbindung nicht von einer Firewall oder etwas ähnlichem unterbrochen wird: <br/>Code:work:/home/simon# ssh samba-tunnel-home simon@ip-at-home's password: simon@vsn-server:/home/simon# ping -i 8 127.0.0.1 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.3 ms <br/>Jetzt lassen wir das Fenster offen, und später können wir uns daheim an den Linux Computer setzen: <br/>Code:workstation:/home/simon# last -1 simon pts/18 work.nat.ip Tue Aug 18 19:24 still logged in <br/>Passt, die Verbindung steht noch, also weiter: <br/>Code:workstation:/home/simon# mkdir work/ workstation:/home/simon# smbmount \\127.0.0.1\blubbfishordner work/ port=123 <br/>Tada, im Ordner /home/simon/work ist jetzt der Ordner blubbfishordner von der Arbeit gemounted.
| |
| * Hier können wir den Port ebenfalls global machen, indem wir GatewayPorts yes in der Datei /etc/sshd_config eintragen.
| |
| | |
| === ssh - sshfs Top ===
| |
| * FUSE Hier wird FUSE, und sshfs benötigt.
| |
| * Eine Anleitung wie man die Pakete installiert.
| |
| * Mit dem Befehl: <br/>Code:sshfs -p <port> <user>@<host>:<directory> <mountpoint> <br/>wird das Verzeichnis eingebunden, wobei -p (Standard: 22), und <directory> (standard: Homeverzeichnis) optional sind.
| |
| * Damit wird das Verzeichnis wieder ausgebunden: <br/>Code:fusermount -u <mountpoint><br/>Wenn dieser Fehler auftaucht: <br/>Code:fusermount: unknown option -- Try `fusermount -h' for more information <br/>dann haben Sie noch eine andere Version in einem anderen Verzeichnis installiert.
| |
| * whereis fusermount zeigt ihnen wo sich das Programm befindet, löschen Sie das ältere.
| |
| | |
| * Lufs Für sshfs brauchen sie Lufs.
| |
| * Laden sie es herunter und installieren Sie es. (/usr/local/lib in /etc/ld.so.conf eintragen, und ldconfig benutzen nicht vergessen) Ausserdem brauchen Sie ein Kernel modul: File systems -> Filesystem in Userspace support das ab dem Kernel 2.6.14 implementiert ist.
| |
| * Mit dem Befehl: <br/>Code:mount -t lufs none mountingpoing -o nosuid,fs=sshfs,host=<host>,username=<username>,port=22,fmode=444,dmode=555 <br/>wird das Verzeichnis eingebunden.
| |
| * Mit umount <mountingpoint> können Sie es wieder ausbinden.
| |
| | |
| === ssh - X11 forwarding Top ===
| |
| Mit SSH, ist eine einfache, und verschlüsselte Bildschirmübertragung möglich, das funktioniert ganz einfach: wir verbinden uns über den SSH-Client und dem Parameter -X, der SSH-Server startet einen virtuellen X-Server, und setzt DISPLAY entsprechend:
| |
| | |
| Code:simon@workstation:/home/simon# xhost access control enabled, only authorized clients can connect work@workstation:/home/simon# ssh -X -l simon ssh-server Password: simon@vsn-server:/home/simon# nedit simon@vsn-server:/home/simon# echo $DISPLAY localhost:10.0 simon@vsn-server:/home/simon# xauth Using authority file /home/simon/.Xauthority xauth> exit
| |
| | |
| Ich hoffe dieser Part hat einen guten Überblick über die Funktionen und features von SSH geschaffen Der nächste Part wird wahrscheinlich die Themen "ssh-agent", und "ssh-server security allgemein" behandeln.
| |
| | |
| Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?Editieren Versionen Linkpartnerschaft Top PrintversionHaben 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 3: Usage
| |
| | |
| == Secure SSH Tutorial Part 4: Security & ssh-agent ==
| |
| Sprachenübersicht/Betriebssysteme/Linux/SecuritySecure SSH Tutorial Part 4: Security & ssh-agentDiese Seite wurde 34216 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: Security, SSH, Tutorial, ssh-agent, agent, iptables
| |
| | |
| === Vorwort Top ===
| |
| Im ersten Teil dieser Tutorialserie ging es um die sichere Verwaltung des Host-Schlüssels, der zweite Teil beschäftigt sich mit Identity/Pubkey Authentifizierung unter SSH.
| |
| * Der dritte Teil hat sich mit dem Ungang mit den SSH-Tools beschäftigt.
| |
| * In diesem Teil werden wir uns mit einigen Sicherheitszusätzen beschäftigen, und den ssh-agent kennen lernen.
| |
| | |
| === Kapitel 1: Der ssh-agent Top ===
| |
| Im zweiten Teil haben wir die gewöhnliche plaintext-Passwort-Authentifizierung gegen eine Identity/Pubkey Authentifizierung ausgetauscht.
| |
| * Dort habe ich versprochen einen Artikel zu bringen, in dem erklärt wird, wie wir einrichten, dass wir keine passphrase mehr eingeben müssen.
| |
| * Das machen wir jetzt mithilfe von ssh-agent.
| |
| | |
| === ssh-agent Enviroment-Variablen setzen Top ===
| |
| Als erstes starten wir den ssh-agent ohne Parameter:
| |
| | |
| Code:workstation:/home# ssh-agent SSH_AUTH_SOCK=/tmp/ssh-OqdW7921/agent.7921; export SSH_AUTH_SOCK; SSH_AGENT_PID=7922; export SSH_AGENT_PID; echo Agent pid 7922;
| |
| | |
| Der ssh-agent gibt Informationen aus, die wir nutzen können um die enviroment-variables der shell zu setzen.
| |
| * Sollten Sie in einer anderen shell, beispielsweise einer C-shell, ala /bin/csh oder /bin/tcsh arbeiten, können diese Variablen anders sein, in diesem Fall sollten Sie die Parameter -c oder -s benutzen, um den C-Shell, bzw.
| |
| * Bourne shell Syntax ausgeben zu lassen.
| |
| * Wir müssen die SSH Enviroment-Variable SSH_AUTH_SOCK setzen, damit ssh weiß, wie mit dem ssh-agent kommunizieren kann, jedesmal wenn der ssh-agent gestartet wird, sollten wir diese Variable setzen.
| |
| | |
| Code:<nowiki>#Wir testen ob Variablen gesetzt sind </nowiki>workstation:/home# set | grep SSH_ <nowiki>#Variablen mit eval setzen </nowiki>workstation:/home# eval `ssh-agent` Agent pid 7943 <nowiki>#Jetzt sind wir bereit, nur noch testen: </nowiki>workstation:/home# set | grep SSH_ SSH_AUTH_SOCK=/tmp/ssh-xoGi7942/agent.7942 SSH_AGENT_PID=7943
| |
| | |
| Jetzt haben wir die SSH_AGENT_PID Variable gesetzt.
| |
| * Wenn wir den ssh-agent nicht mehr als Daemon laufen lassen wollen können wir ihn mit ssh-agent -k killen.
| |
| | |
| === ssh-agent Schlüssel hinzufügen Top ===
| |
| Als nächstes müssen wir Schlüssel mit dem Programm ssh-add hinzufügen.
| |
| * Wenn wir ssh-add ohne Parameter starten wird es automatisch die Schlüssel von $HOME/.ssh/identity, $HOME/.ssh/id_rsa, und $HOME/.ssh/id_dsa zum laufenden ssh-agent hinzufügen.
| |
| * Da unsere Schlüssel immer(!) mit passphrases geschützt sind, wird uns das Programm automatisch nach der passphrase fragen.
| |
| | |
| Code:<nowiki>#Wir testen ob der ssh-agent läuft </nowiki>workstation:/home# ps -fp $SSH_AGENT_PID UID PID PPID C STIME TTY TIME CMD lainee 7943 1 0 15:52 ? 00:00:00 ssh-agent <nowiki>#Welche keys sind bereits im ssh-agent -l = list </nowiki>workstation:/home# ssh-add -l The agent has no identities. <nowiki>#Keys importieren </nowiki>workstation:/home# ssh-add Enter passphrase for /home/simon/.ssh/id_rsa: Identity added: /home/simon/.ssh/id_rsa (/home/simon/.ssh/id_rsa) Identity added: /home/simon/.ssh/identity (simon@workstation) <nowiki>#Keys aus einer anderen Datei imporiteren </nowiki>workstation:/home# ssh-add ssh-keys/id* Enter passphrase for id_rsa.simon: Identity added: id_dsa.simon (id_dsa.simon)
| |
| | |
| Das Beispiel sollte selbst-erklärend sein.
| |
| | |
| === ssh-agent Schlüssel löschen Top ===
| |
| Wenn wir zu viele Schlüssel im ssh-agent haben, einen Schlüssel nicht länger, oder nur für eine kurze Zeit brauchen, dann wollen wir den Schlüssel aus dem Schlüsselbund entfernen, mit ssh-add -d kann ein Schlüssel von ssh-agent entfernt werden:
| |
| | |
| Code:workstation:/home# ssh-add -d ~/.ssh/id_dsa Identity removed: id_dsa (id_dsa.pub) workstation:/home# ssh-add -l The agent has no identities.
| |
| | |
| ssh-add -D löscht alle Schlüssel.
| |
| | |
| === ssh-agent Zu viele Schlüssel Top ===
| |
| Der SSH-Server erlaubt uns nur eine bestimmte Anzahl von Versuchen für eine bestimmte Zeit, jeder falsche Login-Versuch zieht uns erlaubte Versuche ab.
| |
| * Wenn wir viele Schlüssel in ssh-agent haben, kickt uns der Server vielleicht bevor wir uns einloggen können.
| |
| * Wenn dieser Fall eintrifft gibt es ein paar Möglichkeiten die wir nutzen können: * Wenn wir einen Schlüssel haben den wir nicht mehr brauchen, beispielsweise einen alten RSA1 Schlüssel, können wir ihn mit ssh-agent -d Dateiname löschen, siehe letztes Kapitel
| |
| | |
| * Wir könnten auf Passwort-Authentifizierung umsteigen, dazu können wir temporär SSH_AUTH_SOCK abschalten: <br/>Code:workstation:/home# SSH_AUTH_SOCK='' ssh simon@vsn-server<br/>Oder wir machen es per Konfigurations-Datei, ~/ssh/options für einen bestimmen host: <br/>Code:workstation:/home# nano ~/.ssh/config Host vsn-server <nowiki>#Authentifizierung abschalten </nowiki>RSAAuthentication no PubkeyAuthentication no <br/>Die dritte Möglichkeit wäre: <br/>Code:ssh -o 'PubkeyAuthentication=no' -o'RSAAuthentication=no' simon@vsn-server
| |
| | |
| === ssh-agent Unix Domain Socket Top ===
| |
| Wenn der ssh-agent gestartet wird, erstellt er einen unix domain socket, der auf Verbindungen von /usr/bin/ssh wartet, er erstellt ein neues Verzeichnis in /tmp/, mit 0700, und einen socket mit 0600, dadurch werden die Schlüssel für die root Benutzer lesbar.
| |
| * Mit ls -la /tmp/ssh-*/* lassen sich die sockets auslesen, und mit SSH_AUTH_SOCK=/tmp/ssh-x && export SSH_AUTH_SOCK setzen.
| |
| | |
| Das Problem lässt sich zwar mit der -c Option beim importieren lösen, danach wird bei der Benutzung eine Bestätigung verlangt, indem ssh-agent das Programm ssh-askpass startet.
| |
| * Dieses Programm läuft aber auf dem X11 server, der wiederum vom root komplett kontrolliert werden kann.
| |
| | |
| === ssh-agent Lebensdauer der Schlüssel Top ===
| |
| Mit ssh-add -t seconds filename, oder ssh-agent -t seconds können wir die Lebensdauer eines bestimmen Schlüssels, oder von allen Schlüsseln im ssh-agent bestimmen.
| |
| | |
| === ssh-agent Sperren Top ===
| |
| Mit der Option -x kann man den ssh-agent bis zur nächsten Eingabe von ssh-add -x sperren.
| |
| * Wärend dieser Zeit ist ssh-agent unbenutzbar, eine gute Möglichkeit wenn man für eine bestimmte Zeit weg ist.
| |
| | |
| === ssh-agent agent forwarding Top ===
| |
| Ein weiteres feature ist agent forwarding, dabei "folgt" uns SSH von Rechner zu Rechner, bei jeder weiteren Verbindung erstellt der Server einen ssh-tunnel zurück mit einer Verbindung zum agent.
| |
| * Wichtig dabei ist das ssh-agent natürlich von jedem root auf dem Rechner ausgelesen werden kann, wenn agent forwarding aktiviert ist.
| |
| * Wir benutzen agent forwarding so:
| |
| | |
| Code:workstation:/home# ssh -A user@ssh-server [code] In der globalen ssh_config Datei, die sich normalerweise in /etc/ oder /etc/ssh/ befindet können wir agent forwarding global ausstellen: [code] Host * ForwardAgent no
| |
| | |
| Wenn wir agent forwarding für einen bestimmten Server einschalten wollen, können wir das mit ForwardAgent yes machen:
| |
| | |
| Code:Host ssh-server-ip ForwardAgent yes
| |
| | |
| === Kapitel 2: Sicherheitstipps Top ===
| |
| In diesem Kapitel werden noch zusätzlich zu den vorherigen Tutorials Sicherheitstipps besprochen, wobei es sinnlos sein kann, wenn man einige kombiniert, es wird für dasselbe mehrere Möglichkeiten angeboten.
| |
| * Die Möglichkeit mit den begrenzten logins ist mit einem Pubkey oder mit einer Identity übrigens sinnlos.
| |
| | |
| === Root login abschalten Top ===
| |
| Wenn es zum Konzept passt, kann man in der Datei ssh_config, die sich normalerweise in /etc/ oder /etc/ssh befindet, den login vom Benutzer root abschalten:
| |
| | |
| Code:PermitRootLogin no
| |
| | |
| Falls nötig kann man immer noch mit su oder sudo arbeiten.
| |
| | |
| === Nur bestimmte User zulassen Top ===
| |
| Mit der Option AllowUser in der Datei ssh_config kann man nur bestimme User einloggen lassen:
| |
| | |
| Code:AllowUsers simon blubbfish
| |
| | |
| === Nur ein bestimmtes Land zulassen Top ===
| |
| (Das setzt voraus, dass ssh mit "--with-tcp-wrappers" konfiguriert wurde und die entsprechende Bibliothek vorhanden ist.) Wenn man für das einloggen nur ein bestimmtes Land zulassen will, kann man das in der Datei /etc/hosts.allow machen:
| |
| | |
| Code:sshd : .at : allow sshd : ALL : deny
| |
| | |
| === Maximale Login Versuche setzen Top ===
| |
| Wenn man nur ein paar login Versuche von einem Host zulassen will, kann man das mit MaxAuthTries in sshd_config machen:
| |
| | |
| Code:MaxAuthTries 1
| |
| | |
| === Bruteforce Attacks mit iptables stoppen Top ===
| |
| Ich bin hier auf eine Lösung gestossen SSH mit iptables gegen Bruteforce zu schützen:
| |
| | |
| <nowiki>#!/bin/sh </nowiki> IPTABLES="/sbin/iptables" TRUSTED_HOST="192.168.0.2" $IPTABLES -F $IPTABLES -X $IPTABLES -N SSH_WHITELIST $IPTABLES -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
| |
| | |
| Wenn man innerhalb einer Minute mehr als 3 neue eingehende Verbindungen hat, werden die Verbindungen gedroppt.
| |
| | |
| Benötigte Module: ipt_ULOG, ipt_state, ip_conntrack, ipt_REJECT, ipt_LOG, ipt_recent, iptable_filter, ip_tables
| |
| | |
| Alternativ dazu ist das tool fail2ban zu nennen.
| |
|
| |
|
| === Links === | | === Links === |
| # https://www.online-tutorials.net/security/secure-ssh-tutorial-part-4-security-ssh-agent/tutorials-t-69-206.html | | ==== Projekt ==== |
| | ==== Weblinks ==== |
| | # cyberciti.biz: How To: Ubuntu / Debian Linux Regenerate OpenSSH Host Keys |
|
| |
|
| [[Kategorie:SSH]] | | [[Kategorie:SSH]] |
| [[Kategorie:Kryptologie]] | | [[Kategorie:Kryptologie]] |
| | |
| | </noinclude> |