SSH/Hostkey
SSH Host Keys - nervig oder sinnvoll?
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. 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. 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.
Im Idealfall würde man beim ersten Verbindungsaufbau den Fingerprint des Host Keys überprüfen, also z.B.: 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. Hat man den Key verglichen oder ist man sich zumindest sehr sicher dass man sich mit dem richtigen Server verbunden hat kann man oben stehende Frage mit "yes” beantworten. Der Key wird dann vom Client gespeichert und bei weiteren Verbindungen nur noch verglichen und nicht mehr gefragt.
Sollte im laufenden Betrieb dann doch mal eine Meldung wie die folgende kommen, gibt es Handlungsbedarf.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 a host key has just been changed.
Variante 1
Der Server wurde neu aufgesetzt (oder zumindest der SSH-Key neu generiert), in diesem Fall den Key aus der Datei ~/.ssh/known_hosts entfernen und wie bei einem erstmaligen Verbindungsaufbau verfahren.
Variante 2
Man hat sich auf einen Namen oder eine IP verbunden die nicht eindeutig einem Server zuzuordnen ist, und durch Cluster-Failover, Load Balancing oder ähnliches landet man jetzt auf einem anderen Server. Hier in Zukunft wenn möglich auf eindeutige Namen bzw. IPs verbinden.
Variante 3
Man ist gerade Opfer einer Man-in-the-middle Attacke geworden und ein Angreifer versucht den SSH-Verkehr auf einen anderen Server umzuleiten.
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
Da wir eine größere Menge an Linux Servern betreiben, ist SSH unser tägliches Brot. Sei es nun für den Login mit dem eigenen Benutzer oder für auf SSH aufsetzende Automatisierungen, wie zum Beispiel Ansible. 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 (z.B. 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
Auch hier gilt: wenn mehr als eine Art von SSH Host Key benutzt wird (z.B. 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 (z.B. ü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. Nach dem ersten erfolgreichen Verbindungsaufbau legt der ssh-Client den Host-Key des Servers in der Datei ~/.ssh/knownhosts ab. Bei einem erneuten Verbindungsaufbau vergleicht der ssh-Client den vom ssh-Server aktuell übermittelten ssh-Host-Key mit dem zugehörigen gespeicherten ssh-Host-Key und gibt bei einem abweichenden Key – je nach Konfiguration des ssh-Clients – eine Warnung aus oder bricht sogar den Verbindungsaufbau ab. Durch diese Prüfung können Man-in-the-Middle-Angriffe verbindet werden.
Damit dieser Mechanismus zuverlässig funktionieren kann, benötigt jeder ssh-Server einen eigenen Satz mit einmaligen ssh-Host-Keys.
Bei der Installation des Softwarepaketes mit dem ssh-Server wird üblicherweise ein neuer Satz mit einmaligen ssh-Host-Keys generiert.
Klont man hingegen einen bestehenden Server (z.B. Aufsetzen eines neuen Servers aus einem Backup oder Disk-Images eines bestehenden Servers, Kopieren einer virtuellen Maschine), dann „erbt“ der neue Server den Satz an ssh-Host-Keys. 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.
Keys ersetzen
Zum Erneuern der ssh-Host-Keys löscht man auf dem Server zunächst die bestehenden Host-Keys und generiert einen Satz neue Keys1):
cd /etc/ssh sudo rm ssh_host_* sudo ssh-keygen -A
Änderungen auf die Clients
Sofern für den ssh-Server bereits der alte ssh-Host-Key auf einem Client gespeichert ist, kann die ~/.ssh/knownhosts mit dem folgenden Befehl bereinigt werden:
ssh-keygen -R remote-server-name
Alternativ kann in der ~/.ssh/knownhosts der Eintrag auch mit einem Texteditor entfernt werden2).
Beim ssh-Client Blink (iOS) funktionieren die obigen beiden Lösungen nicht. Hier ist der folgende Workaround notwendig:
In das Verzeichnis .ssh wechseln:
cd ~/.ssh
Inhalt der Datei known_hosts mit Zeilennummern anzeigen:
cat -n known_hosts
Entsprechende Zeile merken und mit sed löschen (im Beispiel Zeile 99):
sed -i.bak '99d' known_hosts
Quellen
- cyberciti.biz: How To: Ubuntu / Debian Linux Regenerate OpenSSH Host Keys
- serverfault: How to change a SSH host key?
1)
In manchen Quellen wird für das Generieren der neuen Keys der Befehl dpkg-reconfigure openssh-server verwendet, der das Software-Paket für den OpenSSH-Server neu konfiguriert. Es sollte jedoch ein ssh-keygen -A 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.
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
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 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 #Jetzt fügen wir die Datei hinzu, die wir hochgeladen haben 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:#SSH version 1 Identity Authentifizierung RSAAuthentication yes #SSH version 2 Pubkey Authentifizierung PubkeyAuthentication yes #Der Aufbewahrungsort der Schlüssel, ohne führenden Slash liegen sie relativ zum Home-Verzeichnis. 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: scp [-l limit] [-r] [-P port] [-S program] [[user@]host1:]file1 [...] [[user@]host2:]file2 -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 z.B. 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:
Code:workstation:/home/simon# ssh -l simon -L 123:mailserver:110 ssh-server simon@ssh-server's password: ssh-server:/home/simon#
Solange diese Verbindung offen ist, hält SSH den lokalen Port 123 offen, deshalb lassen wir das Fenster jetzt offen, und öffnen ein neues:
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.
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:
~/.ssh/config:Host samba-tunnel-home Hostname ip-at-home RemoteForward 123:localhost:445 User simon
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:
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
Jetzt lassen wir das Fenster offen, und später können wir uns daheim an den Linux Computer setzen:
Code:workstation:/home/simon# last -1 simon pts/18 work.nat.ip Tue Aug 18 19:24 still logged in
Passt, die Verbindung steht noch, also weiter:
Code:workstation:/home/simon# mkdir work/ workstation:/home/simon# smbmount \\127.0.0.1\blubbfishordner work/ port=123
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:
Code:sshfs -p <port> <user>@<host>:<directory> <mountpoint>
wird das Verzeichnis eingebunden, wobei -p (Standard: 22), und <directory> (standard: Homeverzeichnis) optional sind. Damit wird das Verzeichnis wieder ausgebunden:
Code:fusermount -u <mountpoint>
Wenn dieser Fehler auftaucht:
Code:fusermount: unknown option -- Try `fusermount -h' for more information
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:
Code:mount -t lufs none mountingpoing -o nosuid,fs=sshfs,host=<host>,username=<username>,port=22,fmode=444,dmode=555
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, z.B. 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:#Wir testen ob Variablen gesetzt sind workstation:/home# set | grep SSH_ #Variablen mit eval setzen workstation:/home# eval `ssh-agent` Agent pid 7943 #Jetzt sind wir bereit, nur noch testen: 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:#Wir testen ob der ssh-agent läuft 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 #Welche keys sind bereits im ssh-agent -l = list workstation:/home# ssh-add -l The agent has no identities. #Keys importieren 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) #Keys aus einer anderen Datei imporiteren 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, z.B. 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:
Code:workstation:/home# SSH_AUTH_SOCK= ssh simon@vsn-server
Oder wir machen es per Konfigurations-Datei, ~/ssh/options für einen bestimmen host:
Code:workstation:/home# nano ~/.ssh/config Host vsn-server #Authentifizierung abschalten RSAAuthentication no PubkeyAuthentication no
Die dritte Möglichkeit wäre:
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:
#!/bin/sh 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.