Es ist Zeit für ein neues Serverzertifikat. Im Standard sind dieses RSA Schlüssel mit einer Länge von 2048 Bit und SHA1 als Hash Algorithmus für Signaturen. Bei SHA1 bekommt man leider etwas Bauchschmerzen… 2048 Bit Keys sind nun ebenfalls nicht SO lang. Theoretisch noch „sicher“ aber wer will es schon darauf anlegen?
Nun wurde über Jahre an SSL / TLS Zertifikaten dieser Art festgehalten. Meist um kompatibel mit älteren Systemen zu sein. So können zum Beispiel die Betriebssysteme Windows XP sowie das darauf basierende Server Betriebssysteme von der Firma Microsoft, Windows Server 2003, nicht mit SHA2 umgehen.
Ich werde für die nächste Zertifikatsrunde auf 4096 Bit lange Schlüssel und SHA2 (SHA256) setzten. Selbst wenn ich damit einige Windows XP Benutzer abhängen werde!
Natürlich braucht man zusätzlich eine CA, welche mit X.509 Zertifikaten dieser Art umgehen kann. StartCOM / StartSSL kann dieses glücklicherweise. Ich erstelle die Zertifikate jeweils mit openSSL (Patch nicht vergessen!).
Möchte man bei seinem Citrix Xen Server bestimmte Kernelmodule automatisch beim Booten laden, hilft folgendes.
Einfach unter /etc/sysconfig/modules/ ein passendes Konfigurationsfile für das Module anlegen und es ausführbar machen. Ich habe hier ein Beispiel für die IPMI Module:
Hin und wieder bleibt beim Herunterfahren eine VM irgendwie hängen. Dann hat man über das XenCenter keine Möglichkeit mehr diese VM zum Leben zu erwecken. Damit man nun nicht den kompletten VM-Host dom0 neustarten muss, kann man erst folgenden Weg probieren.
Als erstes kann man einen force shutdown der vm probieren:
$ xe vm-shutdown –force vm=“VM-NAME“
Wenn es nicht hilft, kann man versuchen die “wartenden” pending Prozesse am XenServer zu killen:
$ xe task-list
Dann die Prozesse abbrechen welche den Shutdown zu verhindern scheinen:
$ xe task-cancel uuid=“TASK-UUID“
Bringt das alles nichts kann man als letztes noch folgendes probieren:
$ xe-toolstack-restart
Nun kann man noch einmal einen force shutdown probieren. Klappt es auch nicht, muss man wohl doch den VM-Host durchstarten!
Benutzer sind, wie der Name schon treffend beschreibt, Menschen welche etwas benutzen. Dieses bedeutet nicht dass sie es verstehen oder gar „montieren“ können. Sie möchten es einfach nur benutzen und dieses sollen sie auch.
Betreibt man einen Mailserver und verteilt Postfächer an seine Benutzer, kommt man extrem schnell an den Punkt dass die Benutzer ihre Postfächer nutzen wollen 😛 Sie möchten ihr neues Postfach in ihren E-Mail Client (wir sagen MUA) einbinden. Nur wie?!?
Ja klar nun kann man bebilderte Anleitungen oder besser noch Anleitungsvideos anfertigen und diese seinen Benutzer zugänglich machen. Sehr oft muss denn noch am Ende jemand das Postfach einbinden oder es wird nach einer Fehlerdiagnose festgestellt dass der Benutzer keine E-Mails versenden kann, weil er sich nicht am Postausgangsserver anmeldet. Einfacher wäre es doch, wenn sich der MUA selbst konfigurieren würde, oder? ADS Mitglieder welche von einem Exchangeserver bedient werden, kennen die Luxusversion… Kunden der großen Freemailer wie GMX, Google, Yahoo usw. kennen es ebenso. Diese geben in ihrem MUA nämlich maximal 3 Dinge an. Ihren Namen, E-Mail Adresse und das Kennwort. Also alles Dinge die ein normaler Benutzer angeben können sollte.
Wie läuft diese automatische Konfiguration nun bei Microsoft Outlook ab? Nun, da es eine ganze Latte an Möglichkeiten gibt Outlook die Konfiguration unter zu schieben, fragt Outlook diese ganz brav der Reihe nach ab. Bekommt er von einer der Stellen eine Konfiguration probiert Outlook diese aus. Klappt alles, ist die Einrichtung fertig, klappt etwas nicht, geht es in der Liste weiter. Ich fasse mal kurz zusammen:
1 – Ist der Computer Mitglied einer Domäne, wird die E-Mail Adresse vom Active Directory abgerufen.
2 – Der DNS Name des Exchangeservers wird abgerufen.
3 – SCP (Service Connection Point) Suche und Suche nach dem passenden AutoConfig Servers. Dann mit diesen Daten eine Verbindung herstellen. Fertig….
4 – Klappt dieses nicht, wird versucht im DNS einige Domainnamen aufzulösen und dort nach einer autodiscover.xml XML-Datei gesucht. Gesucht wird dabei hier: a. https://ads-domäne/autodiscover/autodiscover.xml b. https://autodiscover.example.org/autodiscover/autodiscover.xml c. http://autodiscover.ads-domäne/autodiscover.xml d. DNS SRV-RECORD: _autodiscover._tcp.ads-domäne/examle.org
5 – Klappt dieses auch nicht, wird versucht auf dem Rechner eine XML Datei zu finden.
6 – Klappt dieses wieder nicht, es aber ein Exchange Server (Punkt 2) gefunden wurde, wird der manuelle Konfigurations-Wizard für Exchangeserver aufgerufen.
7 – Wurde kein Exchange Server gefunden dann wir der einfache Konfigurations-Wizard aufgerufen.
Möchte man nun seinen Outlook Client automatisch alle nötigen Einstellungen für die Konfiguration seines Postfix / Dovecot-IMAP Servers finden lassen, klappt dieses wie folgt:
Wir haken einfach an punkt 4-b. ein. Wir sorgen also dafür dass es den Domainnamen autodiscover.example.org gibt oder halt ein passender SRV-RECORD vorhanden ist und dass dieser auf einen Webserver zeigt, welcher sich zuständig fühlt. Wenn wir nun noch dafür sorgen dass Outlook dort auch die XML-Datei autodiscover/autodiscover.xml abrufen kann sind wir schon ganz weit vorne 🙂
Zu beachten ist aber dass Outlook die Konfigurationsdatei nur dann abruft, wenn diese per https (SSL) zugänglich ist. Beim SRV-RECORD muss man wissen dass Outlook es als „Umleitung“ behandelt. Beim SRV-RECORD und bei allen anderen Umleitungen wird Outlook also ein kleines Fenster öffnen und den Benutzer fragen ob er wirklich dieser Umleitung zur Konfiguration folgen will oder nicht. Ist das SSL-Zertifikat für Outlook nicht gültig, wirft Outlook natürlich ebenfalls Meldungen raus.
Outlook wird geöffnet, der Wizard geht auf und Fragt was für ein Konto wir einrichten wollen. Dann würfelt der Benutzer seinen Namen, seine E-Mail Adresse (test@example.org) und sein Kennwort in den Wizard. Nun geht Outlook seine Testliste durch und sieht das es die Domain: autodiscover.example.org (japp hier greift Outlook immer auf den Domainteil der E-Mail Adresse zurück) gibt. Nun macht Outlook einen HTTP/HTTPS-POST an die Adresse https://autodiscover.example.org/autodiscover/autodiscover.xml in diesem Post übermittelt Outlook unter anderem die vom Benutzer eingegebene E-Mail Adresse (das wird uns später noch helfen!). Als HTTPS Antwort erwartet Outlook nun die autodiscover.xml mit der zu nutzenden Konfiguration.
Alles geil, oder? Na ja fast… Outlook wird nämlich als Anmeldename per Default den Teil der E-Mail Adresse vor dem @ nutzen. In diesem Fall also test. Müssen sich Benutzer mit der kompletten E-Mail Adresse anmelden, hat man nun ein Problem. Es gibt in der XML Beschreibung zwar die Möglichkeit einen <LoginName> zu setzten. Dieser wäre aber statisch. Sprich man kann hier nicht einfach eine Variable wie %e-mailadresse% einsetzten. Nun können wir uns denn noch den POST zunutze machen. Denn hier wird dem Webserver ja die E-Mailadresse (also der Benutzername) mitgeteilt. Ein php://input könnte also die Welt retten.
Jaaaa nun klingelt es schon bei einigen, richtig? Genau… Die Datei: autodiscover/autodiscover.xml ist in Wirklichkeit die Datei: autodiscover/autodiscover.xml.php. In der Konfiguration des VirtualHosts im Apache wird nur ein Alias gesetzt: Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php Damit unser Apache bei der Outlookfrage nach autodiscover.xml bei einem PHP-Script landet. Dieses fischt alle nötigen Informationen ab und bereitet sie entsprechend für Outlook auf.
Ich hoffe dieses kann dem einen oder anderen etwas helfen diesen AutoErmittlungsdienst zu verstehen. Bei Fragen, einfach eine E-Mail schicken 🙂
So nebenbei… Der Microsoft Lync 2013 Client sammelt über den A-RECORD autodiscover.example.org den Weg zum Exchangeserver ein. So kommt dieser auch an die Interne EWS-URL und die Externe EWS-URL.
Der Lync Client benötigt also für jede SMTP-Domäne zwei DNS RECORDS:
autodiscover IN CNAME exchangeserver.example.org.
_autodiscover._tcp IN SRV 0 0 443 exchangeserver.example.org.
Ich muss beim Thema Microsoft Lync aber die Hände heben. Ich kenne hier aber jemanden an den ich Anfragen weiterleiten könnte 🙂
Zertifikat angepasst und per SNI passen eingebunden. So alte Clients haben dann also Pech! 😀 Als kleine Tipp für die eigenen Tests, ein kleines Tool von Microsoft selbst:
https://testconnectivity.microsoft.com
Dort müsste der Exchange ActiveSync Autodiscover alle eure Wünsche erfüllen können!
Auf mehrfachen Wunsch, hier nun noch einmal die autodiscover.php als copy & paste Version:
<?
/*
Open Source Autodiscover implementation in PHP.
Version: 1.0
Tested with:
- Microsoft Exchange Remote Connectivity Analyzer (1.3)
- iOS 4.3.5
- Outlook 2010 (SP0)
- Android 2.3.3
Allows auto configuration of ActiveSync and Outlook (or any other MUA that has
autodiscover support).
Example Apache vhost configuration (SSL is required for Autodiscover):
<VirtualHost 1.2.3.4:443>
ServerName autodiscover.domain.com
ServerAdmin webmaster@domain.com
SSLEngine on
SSLCertificateFile /etc/apache/ssl/certs/apache.domain.com.crt
SSLCertificateKeyFile /etc/apache/ssl/private/apache.domain.com.key
# Force all requests to lowercase. Different MUAs, mobile devices etc
# request the Autodiscover URL in different cases.
RewriteEngine On
RewriteMap lc int:tolower
RewriteCond %{REQUEST_URI} [A-Z]
RewriteRule (.*) ${lc:$1} [R=301,L]
DocumentRoot /var/www/autodiscover/htdocs
<Directory />
Options +FollowSymLinks -Indexes
AllowOverride Options Indexes Limit FileInfo AuthConfig
</Directory>
Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php
ErrorLog /var/www/autodiscover/logs/error.log
CustomLog /var/www/autodiscover/logs/access.log combined
</VirtualHost>
------------------------------------------------------------------------------
Copyright (C) 2011 David Ramsden
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
David Ramsden david {at} 0wned {dot} it
------------------------------------------------------------------------------
*/
// For other supported protocols and more protocol settings, see:
// http://technet.microsoft.com/en-us/library/cc511507.aspx
// Get contents of request made to Autodiscover.
$request = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email_address);
/*** Begin Configuration ***/
// ActiveSync URL.
$_CONFIG['MobileSync']['Url'] = "https://www.kernel-error.de/Microsoft-Server-ActiveSync";
// IMAP configuration settings.
$_CONFIG['IMAP']['Server'] = "imap.kernel-error.de";
$_CONFIG['IMAP']['Port'] = "993";
$_CONFIG['IMAP']['SSL'] = "on";
$_CONFIG['IMAP']['SPA'] = "off";
$_CONFIG['IMAP']['AuthRequired'] = "on";
$_CONFIG['IMAP']['LoginName'] = $email_address[1];
// SMTP configuration settings.
$_CONFIG['SMTP']['Server'] = "smtp.kernel-error.de";
$_CONFIG['SMTP']['Port'] = "465";
$_CONFIG['SMTP']['SSL'] = "on";
$_CONFIG['SMTP']['SPA'] = "off";
$_CONFIG['SMTP']['AuthRequired'] = "on";
$_CONFIG['SMTP']['LoginName'] = $email_address[1];
/*** End Configuration ***/
// XML document heading.
header("Content-Type: text/xml");
echo "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
// Get the schema from the request.
preg_match("/\<AcceptableResponseSchema\>(.*?)\<\/AcceptableResponseSchema\>/", $request, $schema);
// Determine the type of device requesting Autodiscover.
if (preg_match("/\/mobilesync\//", $schema[1]))
{
// Mobile device.
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email_address);
?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="<? echo $schema[1]; ?>">
<Culture>en:en</Culture>
<User>
<DisplayName><? echo $email_address[1]; ?></DisplayName>
<EMailAddress><? echo $email_address[1]; ?></EMailAddress>
</User>
<Action>
<Settings>
<Server>
<Type>MobileSync</Type>
<Url><? echo $_CONFIG['MobileSync']['Url']; ?></Url>
<Name><? echo $_CONFIG['MobileSync']['Url']; ?></Name>
</Server>
</Settings>
</Action>
</Response>
</Autodiscover>
<?
}
else if (preg_match("/\/outlook\//", $schema[1]))
{
// MUA (mail client).
?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="<? echo $schema[1]; ?>">
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<?
// Loop through each configured protocol.
while(list($protocol, $settings) = each($_CONFIG))
{
// Skip ActiveSync protocol.
if ($protocol == "MobileSync") continue;
?>
<Protocol>
<Type><? echo $protocol; ?></Type>
<?
// Loop through each setting for this protocol.
while(list($setting, $value) = each($settings))
{
echo "\t\t\t\t\t\t\t<$setting>$value</$setting>\n";
}
?>
</Protocol>
<?
}
?>
</Account>
</Response>
</Autodiscover>
<?
}
else
{
// Unknown.
list($usec, $sec) = explode(' ', microtime());
?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response>
<Error Time="<? echo date('H:i:s', $sec) . substr($usec, 0, strlen($usec) - 2); ?>" Id="2477272013">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData />
</Error>
</Response>
</Autodiscover>
<?
}
?>
Benutzer sind, wie der Name schon treffend beschreibt, Menschen welche etwas benutzen. Dieses bedeutet nicht dass sie es verstehen oder gar „montieren“ können. Sie möchten es einfach nur benutzen und dieses sollen sie auch.
Betreibt man einen Mailserver und verteilt Postfächer an seine Benutzer, kommt man extrem schnell an den Punkt dass die Benutzer ihre Postfächer nutzen wollen 😛 Sie möchten ihr neues Postfach in ihren E-Mail Client (wir sagen MUA) einbinden. Nur wie?!?
Ja klar nun kann man bebilderte Anleitungen oder besser noch Anleitungsvideos anfertigen und diese seinen Benutzer zugänglich machen. Sehr oft muss denn noch am Ende jemand das Postfach einbinden oder es wird nach einer Fehlerdiagnose festgestellt dass der Benutzer keine E-Mails versenden kann, weil er sich nicht am Postausgangsserver anmeldet. Einfacher wäre es doch, wenn sich der MUA selbst konfigurieren würde, oder? ADS Mitglieder welche von einem Exchangeserver bedient werden, kennen die Luxusversion… Kunden der großen Freemailer wie GMX, Google, Yahoo usw. kennen es ebenso. Diese geben in ihrem MUA nämlich maximal 3 Dinge an. Ihren Namen, E-Mail Adresse und das Kennwort. Also alles Dinge die ein normaler Benutzer angeben können sollte.
Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt.
Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht.
Zusammengefasst bedeutet es:
– Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen.
– Ich kann diesen Speicher aber nicht anlegen 🙁
Damit wäre also nur das Problem des Anlegens zu lösen!
Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit.
Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen.
Festhalten, es geht los…
– gparted öffnen
– den >2TB Datenspeicher auswählen
– über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen
– unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden
– den neuen unallocated Speicher markieren
– über den Menüpunkt Partition den Unterpunkt New auswählen
– nun den File system Type auf lvm2 pv setzten und Hinzufügen
– Abschließend noch diese Änderungen anwenden über den Button Apply
Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen.
Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:
Möchte man die Windows Server Sicherung seines Microsoft Windows Server 2008 oder jünger per Nagios überwachen gibt es viele Wege…. Ich habe einen sehr einfachen gesucht und leider konnte Google mir auf Anhieb keinen nennen. Auf den zu überwachenden Systemen ist jeweils eine voll (Bare Metal) Sicherung eingerichtet. Diese startet 1 bis x mal am Tag. Ist man auf dem Server angemeldet kann man einfach in der Management Console in die Windows Server-Sicherung schauen und den Zustand der letzten Sicherungen sehen. Natürlich auch ob gerade eine Sicherung läuft, wohin gesichert wird, wie viele Kopien vorhanden sind usw. usw…
Alles Dinge die mich erst einmal nicht interessieren. Der für mich spannende Punkt ist, wann war die letzte erfolgreiche Sicherung und ist diese älter als drei Tage? Warum, weshalb, wo, wie, was… Ist mir im ersten Schritt egal. Ich möchte nur informiert sein, wenn es keine aktuelle Datensicherung gibt. Nun bin ich eher in der Unixwelt zuhause aber die Windows PowerShell sollte da doch was können, richtig? Wie ich gesehen habe gibt es ein Snapin für das Windows ServerBackup. Wenn ich dieses hinzufüge kann ich über Get-WBSummary mir eine Art Zusammenfassung anschauen. In dieser finde ich unter dem Punkt LastSuccessfulBackupTime das Datum der letzten erfolgreichen Sicherung. In meinem Fall also jeweils das Datum meiner letzten Vollsicherung. Daraus kann man doch sicher was basteln, oder? Ich habe mir also ein kleines Script zusammengeworfen welches folgendes tut: Es greift sich die Information über die letzte erfolgreiche Sicherung ab und vergleicht sie mit dem aktuellen Datum. Ist es gleich, war die letzte Sicherung heute und alles ist gut. Ist es von gestern, ist auch noch alles gut und Nagios bekommt ein OK zurück. Wenn es aber älter ist (2 – 3 Tage) gibt es eine Warnung an Nagios zurück und wenn es älter ist als 3 Tage gibt es die Meldung critical an Nagios weiter. Nagios kümmert sich dann wie gewohnt darum mich passend zu informieren. Aktuell greift das Script keinerlei Exeptions ab und es ist nicht… sagen wir mal schön 😀 Ich werde es, je nach Zeit, immer mal etwas erweitern. Seine eigentliche Aufgabe erfüllt es denn noch jetzt schon!
Damit einem nicht schon beim ersten Start des Scriptes die folgende Fehlermeldung anspringt:
Das Windows PowerShell-Snap-In „Windows.ServerBackup“ ist auf diesem Computer nicht installiert.
Muss über den Server-Manager ein weiteres Feature hinzugefügt werden. Hier sind unter Windows Server-Sicherungsfeatures noch die Befehlszeilentools zu installieren. Zusätzlich muss die Policy so geändert werden, dass dieses Script auch ausgeführt werden darf. Dazu einfach in die PowerShell folgendes eingeben:
# Set-ExecutionPolicy RemoteSigned
Ich lege das Script nun im Root des primären Filsystems in den Ordner c:\scripte\ Nun kann ich im NSClient++ die Sektion NRPE Handlers erstellen und dort ein Kommando für den Aufruf des Scriptes erstellen. Möchte man über den NSClient++ Windows PowerShell Scripte ausführen, schaut der Aufruf beim ersten hinschauen etwas seltsam aus:
Die restliche Einrichtung in Nagios sollte bekannt sein, sonst fragen 🙂
* UPDATE *
Die Version 0.2 fängt nun zusätzlich den Fehler ab, wenn die Befehlzeilentools nicht installiert sind. Ich dachte erst wäre nicht so wichtig… Aber nachdem ich es auf 10 Systeme gepackt hatte und immer nachgeschat habe 😛 Nun greift es dieses also ebenfals ab und gibt eine CRITICAL Meldung an Nagios weiter!
* UPDATE *
Die Version 0.3 fängt nun auch ab ob eine Sicherung über einen Tageswechsel hin noch läuft.
Na toll… Unsere RIPE hat gerade echte Probleme mit ihrem DNS System 😛 Da brennt wohl gerade der Busch:
RIPE schreibt folgendes an die RIPE-Members-Mailingliste:
„It seems that our DNS provisioning system has developed a major fault, with the result that it is unable to generate DNS zonelets for the other RIRs. This required a complete bootstrap of the system, and unfortunately, this may take a few hours, during which no DNS provisioning will happen. We are aware of the problems and our engineers in the DNS department are working hard to fix the issue as soon as possible. Unfortunately at the moment we are not able to provide an estimated time of the repair yet. An announcement will be sent out to all the Working Group Mailing list with a detailed explanation of the issue and a summary of what is actually being done for fixing it. Please accept our apologies for the inconvenience and the troubles that the issue may have caused to you. Regards, Jarek“
Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:
GnuPG bietet seit längerem verschiedene Möglichkeiten DNS Server nach gpg/pgp Schlüsseln zu fragen. Die aus meiner Sicht einfachste und schnellste ist PKA.
Kann der GPG Client den Schlüssel selbstständig aus dem Internet laden muss ich mich nicht mehr darum kümmern meinen aktuellen öffentlichen Schlüssel auf allen möglichen Key-Servern zu verteilen. Kommt der Schlüssel oder die Information zum Schlüssel und dessen Fingerprint noch von dem DNS Server, welcher für die Domain/Zone zuständig ist, kann man sich noch etwas sicherer sein. Ist diese Zone dann noch per DNSsec (http://www.kernel-error.de/dnssec) geschützt… Ja dann kann man noch etwas sicherer sein! 100%tige Sicherheit gibt es nicht, ich kann mich nur den 100% annähern. Um so besser mir dieses gelingt um so sicher kann ich mir sein 🙂
Wie geht es nun? Recht einfach. Ich exportiere meinen public key und sorge dafür das http clients (https ist nicht wirklich nötig, da der Schlüssel am Ende eh mit dem Fingerprint verglichen wird) diesen herunterladen können. Dann erstelle ich einen Fingerprint meines Schlüssels und veröffentliche beide Informationen zusammen mit der/den E-Mail Adressen in der DNS Zone.
OK los geht es. Zuerst besorge ich mir die Key-ID meines GPG-Keys:
$ gpg --list-keys kernel-error@kernel-error.com
Nun exportiere ich den öffentlichen Teil meines GPG-Keys, den public Key:
Klappt dieses probiere ich ob gpg auch alles findet. Da ich den Schlüssel natürlich bereits in meinem Keyring habe, sage ich gpg dass es einen neuen Keyring unter /tmp/ anlegen soll. In diesen wird dann auch der Public Key importiert, wenn alles funktioniert 🙂 Das echo „foo“ | ist nur damit gpg auch Daten hat die es anfassen soll!
Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten
Diesen Schlüssel trotzdem benutzen? (j/N) j
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
hQIMAyLQ0wrCELyPAQ//SaagWN6N57qIN1s0IksGwbXpchBTTW4FWZVotKUeHeHv
6LQ2abOL3ulRbzIHOmYINT3CUJ3Pf0DmFm44UqXP0Ay/R0PpANNqumshP8J+0aBY
YyhImPEk4s6qK8rJqD0+0F5sWrX7A2bPbmBHmp6BDQSpIUKxTXFTChJ0Hx7n/ntn
X3iLIpl3NYzvWd78Q+7lFcH9TDL+tLb655lwbZ4HcaQOT6NAkHAL76Td8CDQdbUM
Iu7UcZrpVebAaT7dL0HcifpNy+Vfo3xzq7b/MQsHxYASgafwtuOLCJr7Mi1bJqsk
eLZgxtLsflhgnkK/4Yj/zz7TosvUKb6ZemMxok6B95tmIMmBzJt9QPtBhuF6Uhgc
Vr6E6YSM3dKOy3e2N2YEYS/eXUk68S/2B+PtSBRxMuwMB9qIfLxqZPDrMgSoSOOz
7IaBqAy+HZ7JQdYDBg+6uLrf17+hjiX9g3X/sJB002lTqEJ5aIz+fe1QBXwqM97b
7hcOQCbEm1XQOFJmJWPsgROvpQhMZvd8ylLSIKtIKHqWgn0CkobABQ5Y9HJVkpO2
+DID8yT4Iy/be/YfCzU56i2AnswduZpK3bc2DLEPORVRp6PloNOmNhTXtf6IsN1X
mZfGr3sycFq7XNY9M5nha6Jco2ZdBSgebcKNZlkPF7f1GMDfnAAJgwUcX0QMSp7S
PwFvh2D0NqPcl1Rb7ManjL5tpR0NCjnxVEPNRv0j+2Ejr7LGKH/yqZVbnr+eiSRX
FPSvDQJVgT65sPIyn0k6tg==
=k7cd
-----END PGP MESSAGE-----
Tja, damit sollte wohl nun jeder meinen GPG-Key über meinen per DNSsec geschützten DNS Server besorgen können.