Keychain: Alternative zu Gnome-Keyring um SSH-Schlüssel zwischen Logins zu verwalten


An Gnome ist nicht alles schlecht. Das merkt man spätestens dann, wenn man sich näher mit der Situation von Archivmanagern wie Squeeze oder Xarchiver befasst und diese File-Roller gegenüberstellt. Ähnlich verhält es sich mit Gnome-Keyring und Seahorse. Beide Anwendungen vereinfachen das Verwalten von Passwörtern, GPG- und SSH-Schlüsseln enorm.

Die Kehrseite der Medaille ist, bei einer reinen Fenstermanager-Lösung oder bei LXDE werden viele Gnome-Bibliotheken und Ballast mitinstalliert.

Ich habe bisher noch keine perfekte leichtgewichtige Lösung gefunden, die alle meine Wünsche erfüllt. Insbesondere ist das automatische Entsperren aller Schlüssel im Schlüsselring von Gnome eine große Erleichterung, die ich in dieser Form vielleicht noch bei KDE vermute. Ein leichtgewichtiges Pendant zu Seahorse und Co., das aktiv betreut wird – Fehlanzeige.

Keychain

Ich habe mich mal wieder im Wiki von Arch Linux umgesehen und diesen Eintrag zum Thema SSH-Keys gefunden. Schließlich habe ich mich dafür entschieden mir Keychain näher anzusehen, eine in Shell-Skript geschriebene Anwendung, die meinen Anforderungen am besten gerecht wird.

Bisher sah mein Umgang mit SSH-Schlüsseln so aus. Zuerst wurden sie mit ssh-keygen erzeugt und wie im Artikel zur Absicherung des SSH-Servers beschrieben, dann entweder mit Hilfe von Gnome-Keyring in meinem Schlüsselbund dauerhaft gespeichert oder auf der Konsole mit ssh-agent und ssh-add für die Dauer einer Sitzung entsperrt.

Der Vorteil von SSH-Schlüsseln ist, sie verbessern nicht nur die Sicherheit, sondern sie sind auch bequem zu benutzen. Einmal entsperrt und man kann sich bequem ohne Passworteingabe zu einem entfernten Rechner verbinden.

Keychains Vorteil gegenüber der manuellen Methode ist, dass automatisch beim Einloggen in den Terminal ssh-agent und ssh-add ausgeführt werden. Üblicherweise muss man nach jedem Ab- und Anmelden und Wechsel der Sitzung den SSH-Schlüssel erneut entsperren. Mit Keychain startet ein dauerhafter Prozess des ssh-agent, der für jede neue Sitzung wiederverwendet wird. Das heißt, einmal entsperrt lässt sich der Schlüssel bis zum nächsten Reboot ohne weitere Passworteingabe benutzen.

keychain --quiet id_pc1_rsa id_pc2_rsa
[ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] && 
        . $HOME/.keychain/$HOSTNAME-sh
[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] && 
        . $HOME/.keychain/$HOSTNAME-sh-gpg

Dieser Code-Schnipsel wird entweder in der Datei ~/.bash_profile, oder wenn man ZSH benutzt in ~/.zshrc eingefügt. Keychain fügt automatisch die privaten SSH-Schlüssel id_pc1_rsa und id_pc2_rsa dem SSH-Agenten hinzu bzw. GnuPG-Agent, wenn dieser installiert sein sollte. Die Parameter für die laufende Sitzung werden standardmäßig in ~/.keychain/ gespeichert. Die Option –quiet sorgt noch dafür, dass nur Warnungen oder Fehlermeldungen ausgegeben werden, wenn man sich einloggt. Ansonsten würde eine ähnliche Meldung wie diese jedes Mal erscheinen.

* keychain 2.7.1 ~ http://www.funtoo.org
* Found existing ssh-agent: 2797
* Known ssh key: /home/apo/.ssh/id_pc1_rsa
* Known ssh key: /home/apo/.ssh/id_pc2_rsa

Fazit

Keychain ist eine leichtgewichtige Lösung um SSH-Schlüssel über Sitzungsgrenzen hinweg zu entsperren und bequem nutzen zu können. Auch für Cron-Jobs sicherlich eine nützliche Lösung. Das Handbuch man keychain ist empfehlenswert und informativ. Weitere Informationen gibt es wie immer in /usr/share/doc/keychain oder auf der Projektseite. Ich denke, der Gnome-Keyring und Seahorse sind weiterhin die bequemste Möglichkeit. Keychain ist für mich momentan jedoch ein sehr guter Ersatz auf einem leichtgewichtigen System.

Wie geht ihr mit dem Thema Passwörter und Schlüssel um?

SSH: Deaktivieren von StrictHostKeyChecking

Auf meinem Intel-Core-Duo-Rechner benutze ich verschiedene Betriebssysteme und betreibe ein Multiboot-System. Das hilft mir dabei Aufgaben und Software zu trennen, die ich nicht alle gemeinsam unter einem System installieren möchte.

Regelmäßig kommt es jedoch vor, dass ich mich per SSH von einem Laptop zu diesem Rechner verbinde oder Daten per scp austausche. Als vertrauenswürdiges Ziel habe ich dabei meine Debian-Testing-Installation mit Gnome 3 ausgewählt und den dortigen Host-Key zu meiner Datei ~/.ssh/known_hosts hinzugefügt.

Wechsele ich dann zu einem parallel installierten Betriebssystem, begrüßt mich diese Meldung hier.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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)!

Der SSH-Klient macht hier alles richtig und warnt mich davor, dass die Identifikation des Rechners sich nun geändert hat. Das hat mich bisher nie richtig gestört. Entweder habe ich die Datei .ssh/known_hosts gelöscht oder mich von einem anderen Laptop eingeloggt, der diese Installation als vertrauenswürdig eingestuft hat.

Man kann aber auch das sogenannte StrictHostKeyChecking deaktivieren, indem man sich eine entsprechende Konfiguration in ~/.ssh/config anlegt. Prinzipiell würde ich nie auf die Idee kommen dieses Sicherheitsfeature auszuhebeln, insbesondere dann nicht, wenn ich mich im Internet zu einem entfernten Rechner verbinde. Mein Laptop und der Core Duo stehen jedoch nur wenige Meter auseinander und werden dazu oft noch per Kabel verbunden. Von daher ist das Risiko eines Man-in-the-Middle-Angriffs überschaubar.

Meine Lösung sieht nun so aus:

Ich habe die Datei ~/.ssh/config mit folgendem Inhalt angelegt.

Host loki
         StrictHostKeyChecking no
         UserKnownHostFile /dev/null

Wenn ich nun ssh loki eingebe, wird SSH diesen speziellen Host weniger streng prüfen und ich kann mich problemlos zum selben Rechner verbinden, selbst wenn sich das Betriebssystem geändert hat.

Anstatt loki lässt sich auch 192.168.1.207 schreiben und mit der Wildcard * sogar jeder Rechner von der strengen Überprüfung ausnehmen, was ich aber nicht empfehlen kann.

Eine weitere Möglichkeit bietet der Alias-Befehl. Z.B.

alias insecssh='ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"

Mit insecssh loki könnte man sich danach auch ohne Anlegen einer config-Datei zum entfernten Rechner verbinden.

Für die eigenen vier Wände ist das erst einmal ausreichend. 😉

Changelog:
01.09.2012 Alias insecssh der GRML-Konfiguration hinzugefügt.

Debian-Server mit der unkomplizierten Firewall ufw absichern

Zwischen dem Sperren des Root-Zugangs für SSH und dem Installieren des ersten Spieleservers musste ich eine Firewall einrichten. Ich bin noch kein Firewall-Experte, weswegen ihr genau überlegen solltet, ob die folgende Anleitung euren Ansprüchen genügt. Fakt ist aber, dass ich damit momentan meinen Spieleserver mit Debian schütze und ich damit bisher zufrieden sein kann. 😉

Die Errichtung einer Barriere mit Hilfe von netfilter und iptables unterstützen heute viele Werkzeuge. Ich hatte mir ufw und arno-iptables-firewall als mögliche Kandidaten ausgesucht und mich dann für die „unkomplizierte Firewall“ entschieden.

Ursprünglich von Ubuntu entwickelt bietet ufw eine einfache Möglichkeit nur die Dienste freizugeben, die tatsächlich öffentlich verfügbar sein sollen.

Installation

aptitude install ufw

Konfiguration

ufw enable

Aktiviert die Firewall. Bestehende SSH-Verbindungen können unter Umständen getrennt werden. Standardmäßig werden eingehende Verbindungen geblockt und ausgehende Verbindungen erlaubt. Bevor man die Firewall aktiviert, kann man z.B. mit

ufw allow proto tcp from any to any port 22

explizit Port 22 für den SSH-Zugang freigeben.

ufw allow 44443/tcp

In der vergangenen Erklärung konnte man sich über Port 44443 per SSH einloggen, also muss zuerst dieser Port mit allow freigeschaltet werden. Dabei lässt sich mit /udp oder /tcp die Erlaubnis auf bestimmte Protokolle eingrenzen oder ohne auf beide ausdehnen.

ufw limit 44443/tcp

Noch mehr Sicherheit bietet die Limit-Funktion von ufw, mit der die Anzahl von eingehenden Verbindungen pro IP begrenzt wird, wodurch Brute-Force-Attacken deutlich erschwert werden.

ufw default deny

Im Prinzip der wichtigste Schritt, da dadurch standardmäßig alle eingehenden Verbindungen abgewiesen werden. (Genauer, jedes eingehende Packet wird kommentarlos verworfen. DROP)

ufw status verbose

Zeigt den Status der Firewall an. Oder einfach nur ufw status.

ufw allow 27960/udp

Gibt den UDP Port 27960 für OpenArena frei.

ufw allow 40000:40009/udp

Gibt die Ports von 40000 bis 40009 für UDP frei (XPilot-ng)

ufw allow http

Eine andere Schreibweise um Standard-Port 80 für den Webserver freizugeben

ufw logging on und ufw logging medium

Der erste Befehl schaltet die Logfunktion der Firewall ein (standardmäßig auf niedrig). Weiterhin gibt es noch medium, high und full.

ufw delete allow 44443/tcp

Mit der Delete-Funktion lassen sich Regeln im laufenden Betrieb auch wieder löschen.

Ausgehende Verbindungen

Ausgehende Verbindungen werden standardmäßig erlaubt. Im meinem Fall bin ich der einzige Benutzer mit Shellzugriff auf meinem Server und es gibt bisher weder CGI noch PHP-Anwendungen, die man manipulieren könnte um diese Einstellung zu missbrauchen. An dieser Stelle scheiden sich die Geister. Tatsache ist, man kann sein System so fest zuschnüren, dass nicht einmal ausgehende Verbindungen erlaubt sind oder einen Mittelweg finden.

ufw deny out to any

Blockiert alle ausgehenden Verbindungen

ufw allow out 80,443/tcp

Erlaubt ausgehende TCP-Verbindungen für Port 80 und 443.

IPv6

UFW blockt standardmäßig alle Anfragen mit IPv6. Damit ufw mit IPv6 zusammenarbeitet muss in /etc/default/ufw die Variable IPV6 auf Yes gesetzt und die Firewall einmal mit ufw reload neu gestartet werden.

Fazit

Die unkomplizierte Firewall macht ihrem Namen alle Ehre. Das Prinzip ist immer das gleiche. Alle eingehenden Verbindungen verwerfen und nur die tatsächlichen Dienste freigeben, die man wirklich braucht. Wie restriktiv man ausgehende Verbindungen behandelt, hängt vom eigenen Benutzerszenario ab. Die Regeln lassen sich noch deutlich verfeinern. Mehr Informationen verrät man ufw oder die folgenden Links.

Links

Ubuntu ufw Documentation
Firewall Ubuntu Servers

SSH-Schlüssel, Port ändern und Anmeldung als Root verwehren

Nachdem mir meine Zugangsdaten zum vServer übergeben worden waren, war meine erste Aktion mit dem neuen SpielArbeitsgerät den SSH-Zugang abzusichern. Die folgende Anleitung zeigt in Kürze, wie man verhindert, dass Root sich per SSH anmelden darf, SSH auf einem anderen Port lauscht und eine Anmeldung nur noch mit einem gültigen SSH-Schlüssel möglich ist und das Einloggen per Passworteingabe deaktiviert wird.

Diese Prozedur ist bei jedem öffentlich zugänglichen Server sinnvoll, wie ein Vorfall letzte Woche wieder einmal gezeigt hat. In einer größeren Institution wurde ein Server kompromittiert, bei dem sich der Angreifer mit Hilfe einer Wörterbuch-Attacke direkt Rootzugriff über SSH verschaffen konnte, indem er innerhalb weniger Stunden ca. 40.000 Passwörter ausprobieren durfte. Software wie denyhosts, fail2ban oder eine Firewalleinstellung, die nur Zugriff aus „vertrauenswürdigen“ Netzen erlaubt und natürlich ein stärkeres Passwort, wäre hier eine Möglichkeit gewesen den Einbruch zu verhindern.

Mein kleines Projekt bietet mir die einfache Möglichkeit auf noch mehr Sicherheit, da außer mir selbst niemand Shellzugriff benötigt und nichts dagegen spricht den berechenbaren Namen des Root-Zugangs zu deaktivieren und nur noch die Authentifizierung per SSH-Public-Key-Verfahren zu erlauben. Bevor das geschieht, muss man natürlich einen weiteren, unprivilegierten Benutzer mit adduser hinzufügen.

Schlüsselerzeugung

ssh-keygen

Ohne weitere Argumente erstellt dieser Befehl einen privaten und öffentlichen RSA-Schlüssel für die SSH-Protokollversion 2 auf dem lokalen Rechner. Bejaht man alle folgenden Fragen, wird das Schlüsselpaar in ~/.ssh/ gespeichert. Ebenso wird man nach einem Passwort gefragt, um den privaten Schlüssel später entsperren zu können. Ich empfehle eines zu setzen, auch wenn man dadurch einmal pro Sitzung das Passwort eingeben muss.

Öffentlichen Schlüssel auf den Server transferieren

ssh-copy-id user@euervps123.de

Der öffentliche RSA-Schlüssel befindet sich danach auf eurem Server in ~/.ssh.

Einloggen

Funktioniert wie bisher,

ssh user@euervps123.de

nur dass ihr jetzt das Passwort zum Entsperren des privaten Schlüssels auf eurem Rechner eingeben müsst. Die Rechte der privaten Schlüsseldatei id_rsa müssen restriktiv sein.

chmod 600 ~/.ssh/id_rsa

Schlüssel ohne Eingabe des Passworts benutzen

Unter Gnome 3 genügte bei mir

ssh-add

auszuführen, um den privaten Schlüssel dem Authentifizierungsagenten, ssh-agent, hinzuzufügen, der hier durch die Anwendung gnome-keyring bereitgestellt wird. Nach einmaliger Eingabe des Passwortschutzes für den privaten Schlüssel ist dieser die gesamte Sitzung ohne weitere Passwortabfrage benutzbar.

Arbeitet ihr ohne X auf der Konsole müsst ihr zuerst den

ssh-agent zsh

mit eurer bevorzugten Shell aufrufen und könnt danach den privaten Schlüssel wieder wie oben beschrieben mit ssh-add für die Sitzung dauerhaft entsperren.

Root-Zugang deaktivieren, Port verändern und Passwort-Authentifizierung abschalten

Hierzu muss die Datei /etc/ssh/sshd_config auf dem Server angepasst werden.

Wichtig! Bevor ihr die Veränderung vornehmt, solltet ihr absolut sicher sein, dass ihr euch mit dem neu generierten Schlüssel anmelden könnt. Ebenso müsst ihr unbedingt die Einstellungen der Firewall so anpassen, dass ein Anmelden über den neuen SSH-Port erlaubt ist. (siehe nächster Beitrag).

Folgende Optionen werden geändert:

Port 44443

PermitRootLogin no

RSAAuthentication yes
PubkeyAuthentication yes

PasswordAuthentication no

X11Forwarding no

Fazit

Der Port kann im Prinzip beliebig gewählt werden. Die Liste der standardisierten Ports hilft bei der Entscheidung. Der Wechsel von Port 22 auf z.B. Port 44443 lässt die Mehrzahl automatischer Programme ins Leere laufen, die nur überprüfen, ob auf dem Standardport ein SSH-Dienst angeboten wird. Anmelden kann man sich ab sofort mit

ssh -p 44443 user@euervps123.de

Das Abschalten der Passwort-Authentifizierung macht Wörterbuch-Attacken aussichtslos. Das Deaktivieren des Root-Logins erzwingt die Anmeldung mit einem unprivilegierten Benutzer, so dass ein Angreifer nicht nur die Hürde des SSH-Schlüssels überwinden, sondern noch ein weiteres Passwort in Erfahrung bringen muss.

Sicherheit ist ein Prozess, heißt es so schön. Für mein spezielles Benutzerszenario funktioniert dieser Weg. Fehlerhaft konfigurierte Dienste und Sicherheitslücken kann aber auch diese Anleitung nicht verhindern.

Links

https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
http://bodhizazen.net/Tutorials/SSH_keys
Sicherer Datentausch: Ein sftp-Server mit chroot

Arch Linux: Paketsignaturen mit GnuPG und Pacman 4

Vor drei Tagen wurde auf archlinux.org die gute Nachricht verkündet, dass Archs neuer Paketmanager Pacman 4 nun in den „Core“-Paketquellen verfügbar ist. Ich hatte im letzten September noch laut über die Sicherheitsarchitektur der Paketverwaltung nachgedacht und damals die Diskussion zu dem Thema näher verfolgt, die schon vor Jahren angestoßen wurde aber erst durch einen kritischen lwn.net Artikel an Fahrt gewann.

Währenddessen war man nicht untätig und 893 commits von 24 Helfern später, ist es nun gelungen eine Reihe von neuen Feature zu implementieren, darunter eben auch das Signieren von Paketen mit GnuPG.

Zuerst fiel mir auf, dass ich yaourt und dessen Abhängigkeit package-query vor einem Systemupgrade entfernen musste, da package-query auf Pacman in einer Version < 3.6 angewiesen war. Danach wurde zuerst Pacman aktualisiert, bevor ich mir das neue Sicherheitskonzept näher anschauen konnte.

Als erstes sollte man den neuen GnuPG Schlüsselbund mit pacman-key --init anlegen. Zum Thema Package Signing und Pacman-Key gibt es schon einen hilfreichen Eintrag im Wiki. Ausführlich wird der gesamte Prozess auch auf Allan McRaes Homepage erläutert.

Nachdem mit pacman-key sowohl Schlüsselbund und ein Grundgerüst an Konfigurationsdateien angelegt worden ist, kann man in /etc/pacman.conf seine persönlichen Vorstellungen von Sicherheit einstellen. Zur Zeit ist das Überprüfen der Paketsignaturen nämlich noch mit der Variablen SigLevel = Never abgeschaltet.

Mit SigLevel = Optional TrustedOnly werden Pakete auf ihre Signaturen hin überpüft, jedoch muss man jedem unbekannten Schlüssel noch einzeln vertrauen. Eine typische Fehlermeldung sieht dann am Anfang so aus:

pacman -S transmission-gtk
resolving dependencies…
looking for inter-conflicts…

Targets (1): transmission-gtk-2.42-2

Total Download Size: 0.61 MiB
Total Installed Size: 2.57 MiB

Proceed with installation? [Y/n]
:: Retrieving packages from extra…
transmission-gtk-2.42-2-i686 625.7 KiB 410K/s 00:02 [########################################] 100%
(1/1) checking package integrity [########################################] 100%
error: transmission-gtk: key „E8F18BA1615137BC“ is unknown
:: Import PGP key 615137BC, „Ionut Biru „, created 2011-04-19? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Deswegen sollte man zuerst die sogenannten MasterKeys importieren. Diese fünf Hauptschlüssel werden dazu benutzt um die Schlüssel anderer ArchLinux-Entwickler zu unterschreiben. Gemäß dem Web of Trust ist das marginale Vertrauen in drei dieser Schlüssel ausreichend, um einen anderen mit ihnen unterschriebenen Schlüssel als gültig anzusehen. Selbst im schlimmsten Fall, wenn zwei der MasterKeys widerrufen werden müssten, wäre also das Sicherheitskonzept weiter in Takt.

Problematisch ist momentan die Verteilung dieser Schlüssel. Es gibt z.B. noch kein pacman-keyring Paket, mit welchem alle GnuPG-Schlüssel automatisch und benutzerfreundlich eingerichtet werden können. Außerdem haben noch nicht alle ArchLinux-Entwickler ihre GnuPG-Schlüssel unterschreiben lassen, weswegen es zu Warnmeldungen kommt. Dies ist auch der ausschlaggebende Grund, warum Arch Linux mit Pacman 4 standardmäßig noch auf die Validierung verzichtet.

Eine einfache Möglichkeit die fünf MasterKeys zu importieren, ist diese For-Schleife zu benutzen.

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/ 
--no-permission-warning --command-fd 0 --edit-key $key
done

Halten wir mal fest, dass Arch Linux einen großen Schritt in Sachen Paketsicherheit nach vorne gemacht hat. Es braucht aber noch den letzten Feinschliff in den kommenden Wochen, um das Vertrauen in das neue System auch tatsächlich herzustellen.